[gmpi] Bookmark: Event Queues & Routing (not Topic 6: Time rep.)

  • From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Fri, 2 May 2003 13:13:01 -0700

> >correct! Everything is acontrol. ;)

Love that. How do pins and controls relate in your view? All controls on one big pin? Controls grouped into particular pins per each plug's particular design? Inquiring minds etc,...

I assume by pin you mean some sort of signal path?

Control event input ports. Consider a plug-in with four MIDI ins, because it supports something ridiculous like 64 MIDI channels -- four 16-channel pins with identical control sets. Or as was discussed in another thread, a MIDI synth that can respond to three different MUSTIME contexts -- two music event in pins with identical control sets. Allows for certain useful kinds of internal structuring in the plug, and eases accommodation for some legacy concerns.


Analogize to a ring modulator, with two identically typed (audio) inputs with distinct functions. So pins would have to be labelled to distinguish them for the end-user or host making connection decisions.

In XAP:  All events are delivered on an event-queue (or list-head).
At startup, the host asks the plugin for an event-target for each control
(and a master, and possibly others).  The event-target is a tuple of an
event-queue and a cookie (uint32).  The cookie is opaque to the host, and
only meaningful to the plugin.

When the host wants to send an event to control X, it sticks the proper
cookie in the event and delivers it to the event-queue.

This lets a plugin have 1 event-queue for all events, and cookies to sort.
This lets a plugin have 1 event-queue for each control.
This lets a plugin decide what it wants to do, and how it wants to receive.
And the host doesn't need to change it's behavior.

Sounds like that would work fine no matter how many queues per plug you have. (Of course you'd only do that if it was worth the effort of having one event-sucker per pin.)


One way to implement pins would be to use your singgle-queue approach, but also ngive events a 'Pin' field, so they all appear in ABSTIME-stamped order. Then we just leave it to the pin to dispatch events from the one queue to the different internal per-pin event handling units.

-- Chris

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