We agree! Love that.
-- Chris
> >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 --
That pre-supposed the continuance of MIDI as a first-class citizen. Not if I have my way. :)
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.
I'm not sure what the question here was..?
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.
Absolutely! In XAP we called them hints. For example, stereo plugins would have two audio inputs. One is hinted LEFT and one is hinted RIGHT. The host can make an assumption about the connection of a LEFT to a LEFT and a RIGHT to a RIGHT. It could also give the user the option to flip that.
Makes things like 7.1 sound pretty easy.
>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
Exactly the point - it is not OUR job to decide how many queues make sense. If we decide on one per plug, it makes life hard for some developers. If we decide one per control, it makes life hard for other developers. Let's agree to not decide, and let the plugin tell us.
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.
IFF the plugin finds that the best way to deal with it. By a simple abstraction at startup time (no extra cost) we give the plugins that much more control.
-- 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
---------------------------------------------------------------------- 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
