[gmpi] Re: R: Re: Topic 4: Host Interface


> to go. So for automation, I can imagine having both a parameter interface
> that describes parameters, converts from values to text, etc., and having
> the automation data sent to the plug via an asynchronous pin.

As soon as I see two ways of doing the same FUNDAMENTAL thing, I think there
is something wrong with the design.

Just to make sure you understand what I'm describing in my automation example above, the functions provided by the interface would not overlap the functions provided by the event stream. Basically, the (unidirectional) event stream would just be used to send the control data, while the bidirectional interface would provide functions that need an immediate response.

I do agree that this division of functionality is potentially messy, and I'm raising it as an item of discussion because I think it's going to be a big issue. I really like the idea of using asynchronous event streams for things like automation data. At the same time, I really don't like the idea of using bidirectional event streams for interfaces because of their asynchronous nature. The solution may be to segregate functionality into unidirectional streams versus interfaces and try really hard not to duplicate anything.

Bill

At 09:26 AM 3/28/03 -0800, you wrote: 
> I have a question about what functionality should be provided via event
> streams versus interfaces. For example, automation data could be events

I think that simpler is better.  Providing two ways of doing things makes
twice the work.  As I see it, ALL control changes are event driven.  This
includes time info, tempo, knobs, filenames, etc.  There isn't any reason
(that I can see) not to have it as such, and it prevents another set of
interfaces from making more work for everyone.

> could be done via an interface. One important issue is buffering, events
> can sit in buffers whereas interfaces are immediate. Another is the duplex

In thinking about this, I envisioned a simple state diagram.  As soon as we
(the plugin) are active, we only receive events (timestamped, can be
anywhere in future linear time, specifically during the next time slice) or
we have our methods called at time-slice boundaries.  This immediately
suggests that things such as control data (which should be anywhere in time,
by nature) should NOT be passed via methods, but events.

Methods to manipulate the plugin state, controls to manipulate the plugin.
Or something like that.

> issue, if you want an immediate response an interface seems to be the way

This is true, but what control event needs a response?  It's important to
get the seperation between sending the plugin a message such as "become
active" and sending the 'thing that a plugin models' (such as a synth) a
message such as "set knob X to value Y".

> to go. So for automation, I can imagine having both a parameter interface
> that describes parameters, converts from values to text, etc., and having
> the automation data sent to the plug via an asynchronous pin.

As soon as I see two ways of doing the same FUNDAMENTAL thing, I think there
is something wrong with the design.

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


----------------------
Bill Gardner
Wave Arts, Inc.
99 Mass. Ave., Arlington, MA 02474
Tel: 781-646-3794   Fax: 781-646-7190
billg@xxxxxxxxxxxx


----------------------------------------------------------------------
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: