[gmpi] Re: Topic 6: Time representation

  • From: Tim Hockin <thockin@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Fri, 2 May 2003 12:33:49 -0700 (PDT)

> That's exactly how I saw it working. Event-processing plugins that don't
> mess around with tempo or time will just pass events on to downstream
> plugs.

I don't like the idea of passing things downstream.  A plugin should not see
events that are not meant for it.

> The only complication is in developing merger filters, they will have to
> allow (the user?) to select which inbound port's time context to honor.

Or you let the merger subscribe to a time context itself by receiving tempo
information.  If it is the same as one or more of the feeders, great!  If
not, cope!

> note and other musical events. However, if they are to flow downstream in
> the same way, each plug must have a unique target-ID, such that it can
> identify parameter messages intended for it. In the above case, the MIDI
> processing plug needs to be able to ignore parameter events for the audio
> plug sitting downstream.

What we did with XAP was this:  At init time, the plugin is asked for one
event-target for each control.  The event-target is a tuple of {list-head,
cookie}.  The Plugin provides the cookie which is meaningful within itself.
When events get delivered, they include the cookie for their destination.
Thus a plugin always knows which target was intended, even if it has only
one list-head.  Further, it allows the plugin to decide how many actual
queues to sort events into, and how to arrange them.


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