[gmpi] Re: Topic 6: Time representation

> I see.  But unless being able to set each plug's tempo & position 
> independently is a design requirement -- something I hadn't thought 
> of -- why make tempo & position 'controls' of the plug?  I've been 
> thinking of tempo as a sort of global parameter, a property of 
> managed by the host, that you go to the host to get, and that looks 
> the same to all plugs in the graph.
> 
> Though maybe tempo-as-parameter isn't so well-liked.

It is not inconceivable to have multiple tempos for multiple sections of a
graph.

in XAP we adopted this notion of 'Everything is a Control'.  Realistically,
some controls are NOT for the user, but they are hinted so that the host can
connect things together properly.

Making tempo a control is a way of making it an optional item.  If a plugin
cares about tempo, it defines a control with the TEMPO hint.  The host can
see that and do the right thing.

It's not much different than having a per host (or per sub-host) callback,
except it avoid two nasties:  1) the callback list gets large fast 2)
eliminates a function call.  Also, having a simple and consistent model
seems very nice, to me.

Tim

----------------------------------------------------------------------
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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: