[gmpi] Re: 3.11 topic: Multi-timbrality and parameters
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 28 Apr 2004 01:43:37 -0700
Glad to have you back, Chris. I was just thinking of you today :)
On Wed, Apr 28, 2004 at 01:11:25AM -0700, Chris Grigg wrote:
> >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.
> 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
I agree, we need to support it.
> 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.)
There are two reasonable and not-mutually-exclusive ways to do it. I just
wrote an email (without reading yours :) that suggested arbitrary channels
(where each channel is identical in structure). What a GMPI host would
see is a list of per-channel params and a nulber of channels. Or in other
words, a list of arrays, and the dimension of the arrays :)
For situations where all the channels are not identical, this does not
work. We *could* codify another level of indirection, but we're
approaching the complexity of the original modular approach, now.
I think adding a dimension of N identical channels makes us MIDI
compatible, support GM, and solve the vast majority of cases. Other
cases, such as a mixer which had different types of strips, could just use
string names to simulate this.
Example 1: a mixer of all the same channels with 6 channels.
param_list[] = {
"master/gain", //flagged as global
"strip/gain", //flagged as per-channel
"strip/pan" //flagged as per-channel,
"strip/low_eq" //flagged as per-channel,
"strip/mid_eq" //flagged as per-channel,
"strip/hi_eq" //flagged as per-channel,
};
num_channels = 6;
Example 2: a mixer of different channels.
param_list[] = {
"master/gain", //flagged as global
"mono1/gain", //flagged as global
"mono1/pan", //flagged as global
"mono1/low_eq", //flagged as global
"mono1/mid_eq", //flagged as global
"mono1/hi_eq", //flagged as global
"mono2/gain", //flagged as global
"mono2/pan", //flagged as global
"mono2/low_eq", //flagged as global
"mono2/mid_eq", //flagged as global
"mono2/hi_eq", //flagged as global
"stereo1/gain", //flagged as global
"stereo1/pan", //flagged as global
"stereo1/low_eq", //flagged as global
"stereo1/mid_eq", //flagged as global
"stereo1/hi_eq", //flagged as global
"stereo2/gain", //flagged as global
"stereo2/pan", //flagged as global
"stereo2/low_eq", //flagged as global
"stereo2/mid_eq", //flagged as global
"stereo2/hi_eq", //flagged as global
};
num_channels = 0;
> 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
or we could just say that the host is responsible for setting up arrays of
parameters as if they were defined independantly. Either way works.
> 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.
If you have slots that can have different slots, then you end up with
something like this:
a list of slot-types
a counter for each slot type
so the mixer example above would become
slot_types[] = {
"master: gain",
"monno: gain, pan, low_eq, mid_eq, hi_eq",
"stereo:n, pan, low_eq, mid_eq, hi_eq",
};
num_channels[] = {
1, // 1 master
2, // 2 mono slots
2, // 2 stereo slots
};
And this is exactly what I described as a fully modular system :) It was
pointed out, and I have to agree, that this is more complex and probably
unneeded. It's not MUCH more complex, and it is very flexible, but I
think that multiple identical channels is probably good enough for the
majority of cases, and OSC-like names is good enough for the rest.
----------------------------------------------------------------------
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:
