[gmpi] Re: 3.11 topic: Multi-timbrality and parameters

It was asked if there should be a way to identify parameters as per-patch
vs.  per-instance.  The example was a multi-timbral synth.  It might have a
number of active channels (each with a different set of parameters), as well
as a master set of parameters.  The example suggested was a GM synth.  We
pretty much have to support this notion.

The modular-structure model was proposed as a potential solution to this
problem.

Q: What does the reuirements document need to say about this?


Though obvious, thought I should mention that GMPI should be able to support GM pretty easily since "a GM synth" is defined by the GM spec's MIDI implementation, which only needs one MIDI cable and uses MIDI channels to address notes and other commands to the 16 channels... so as long as GMPI supports a music protocol with the concept of multiple channels over a single virtual connection, we should be able to do GM support.

Of course it's a separate question whether there's political desire to expose the GM controllers in a GMPI graph as GMPI plug parameters. If there's not, end of problem....

But if there is, I have an idea. How are we handling e.g. EQ parameters for a mixer plug-in, where you have many parallel channels of identical structure but the same parameter function? I know, this is related to the 'Dynamic plug-in structure' discussion, which I guess we haven't decided yet, but the problem seems to me to call out for channel-based arrays. E.g. the three GMPI parameters LpfFreq[ 2 ], LpfGain[ 2 ], and LpfQ[ 2 ] could characterize the bass EQ band for the mixer plug-in's channel 2. (Somebody suggested using ".2" as part of the parameter name, but I'm not so sure that's the best, seems you'd have to do unnecessary string conversions, memory-burning catenations, etc.)

If (and only if) we did it that way, then the GM controllers could be handled in a similar way: the GM plug would have one GMPI event input supporting 16 channels, and all we'd need to do is agree on (and publish) a predefined, official set of the corresponding parameter names to use (i.e. 'Modulation, Volume, Pan, Expression, Sustain, Reset All Controllers, All Notes Off, Pitch Bend Sensitivity, Fine Tuning, Coarse Tuning'; also 'Program' though that's not a controller).

So, GMPI parameter events could include an integer channel number field in addition to the parameter name string; if your plug doesn't have multiple channels, you can ignore the channel field... something like:

        typedef struct {
                gmpiEventTimestamp  eventTimestamp;
                gmpiParamName        paramName;
                gmpiChannelNumber  channelNumber;
                gmpiParamValue        paramValue;
        } gmpiParamEvt;

Of course this doesn't address other kinds of internal plug structures, but parallel-channel structures seems a pretty common use case to be accommodated, is friendly to a runtime-varying number of channels, and I think channels + param name would still allow different channels to have different parameter name sets.

Hm.

Maybe the idea's not 'channels' exactly, but more like 'slots'. For simple plugs (mixers, GM synths, etc.) all slots might have the same set of parameter names, since they all have the same function, but for more adventuresome plugs different plugs might have different parameter name sets, reflecting the different thing that's been loaded into each slot.

-- Chris G.

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