[gmpi] Re: 3.9 Time Formats
- From: "Michael Stauffer" <michael@xxxxxxxxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Tue, 17 Feb 2004 13:30:16 -0500
Andy wrote:
>Until this example from Michael, I too found it difficult to see why a
>plugin would want to change the tempo map of the host. However
>I can now se
>the merit of Michaels case.
>
>However like Paul, I'm not sure host developers would want a
>plugin messing
>with their tempo maps. I think we would also need to consider
>what would
>happen if two instances of the plugin tried to change the tempo
>map at the
>same time, at the same place, but to different values. Which would have
>precedence ? If we say there can only be one tempo changing plugin at a
>time, who is going to enforce that and how , more work for the host.
>Is there a host developer who would care to comment on this ?
>
>On balance I think I'm against a plugin changing a host tempo map.
Andy, Paul, I understand what you mean, and hope not to come off as pushy
about this. I'm trying to flesh out the issues and make my case as best I
can, so I can best know if this is viable as I investigate how to
integrate our technology with other software. Sometimes it takes a bit
for folks to catch on to what it is I'm really trying to do here, since
it's so unusual. I certainly don't want to try and coerce the group into
adopting this if it's unreasonable.
What I'm thinking now is this: *if* GMPI ends up supporting a plug
*reading* the host's static (ie, offline, bounce-down) tempo map (which
is a capability I have no need of myself, in and of itself), then there
will have to be a method to pass the tempo and associated data to the
plug from the host. Now if this method and its associated data format are
in place, would it be too complicated to provide for a method to pass the
same data format in the opposite direction, from plug to host? Host
support could be optional. Would it take more than 2 or three additional
class member funcs? 1) query the host if it supports static tempo map
mainuplation. 2) send a tempo data event. The methods for verifying that
the event was correctly incorporated would already be in place from the
reading methods.
If support for this host-side tempo-map manipulation were made an
*optional* feature, the host could easily ignore it and avoid the
possible complications. But for hosts that support GMPI, support for this
feature could be added at a later date if the necessity arises. Issues of
plug precedence like Andy mentioned above could be ignored, leaving it up
to the user to be aware of the possible complications of using multiple
host-side-tempo-map-modifying plugs. Since it'd be a part of
offline/bounce-down processing, the user has the time to see what's
happening and undo.
What I'm imagining for myself is that it will be much easier to get a
host developer to add support for static tempo map manipulation if they
already support GMPI (and GMPI supports it), as opposed to getting them
to license my technology and directly incorporate it.
In any case, I hope not to be a pain about this. Thanks for all who have
spent the time discussing this.
Cheers,
Michael
>> -----Original Message-----
>> From: Paul Davis [mailto:paul@xxxxxxxxxxxxxxxxxxxxx]
>> Sent: 17 February 2004 13:48
>> To: gmpi@xxxxxxxxxxxxx
>> Subject: [gmpi] Re: 3.9 Time Formats
>>
>> >The user records a live pianist without a click, because the pianist
>>
>> [ ... example elided ... ]
>>
>> >I realize this is a specialized plug-in capability that
>would very much
>> >help my needs in particular, and perhaps very few others' at
>this point,
>>
>> With the greatest respect for and understanding of your example, I
>> would say that the feature you are describing is just about the only
>> one in which a plugin requires write access to the host's tempo map.
>> However, its a feature that many people would tend to expect to be
>> handled by the host itself (given the host's traditional control of
>> the tempo map). Its no accident that BeatDetective and other similar
>> tools are not plugins.
>>
>> The fact that most hosts today can't do this can be seen either
>> variously as supporting (1) offering this capability to plugins or an
>> open source development model. Either way, it requires a great deal of
>> change/support on the host side, all to be able to provide
>> functionality that the host could (and probably will) provide itself
>> at some point.
>>
>> In short, you're asking for a major chunk of support in GMPI to enable
>> a corner case that will probably vanish in a few years. I don't think
>> that rules it out (and my assessment may be wrong anyway), but its not
>> an easy sell from my perspective anyway.
>
>----------------------------------------------------------------------
>Generalized Music Plugin Interface (GMPI) public discussion list
>Participation in this list is contingent upon your abiding by the
>following rules: Please stay on topic. You are responsible
>for your own
>words. Please respect your fellow subscribers. Please do not
>redistribute anyone else's words without their permission.
>
>Archive: //www.freelists.org/archives/gmpi
>Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
>
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
