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

Thanks for clarifying your thinking on connection mechanics, David. But that seems orthogonal to how parameter IDs work, and would work just as well if there were slots. I still think all this string-fu is messier than it needs to be, so actually I guess I think it could work better. So can you provide a pointer to the OSC parameter string format spec, for a closer look?

Note, it's also an issue at plug re-config time, not just connection time, as the whole params names array contents need to be re-built whenever internal structure of the plug changes.

So far I like the 1D indexed 'modular' approach Tim and I separately arrived at. My gut tells me 80% of plugs will be 1-slot, so only use index 0, and 80% of the rest will use n-channel designs so the 1D system with identical param lists will work OK for them, and the 80% of the rest will be expressible as n-slot designs with different param lists. Seems it's only a couple extra lines of host code to do it that way. At reconfig time most plugs (with static param lists per slot type) would have a lot less work to do, i.e. just say how many slots and which param list index each slot is using now. (Of course truly dynamic param lists don't get any easier.)

Also I don't understand this part at all, can you restate please?: 
"Such a feature would
be of use only to host authors who want to send MIDI to synth plugins
without doing their homework - and it would only work with synths
that actually care to implement it. Other synths wouldn't work at all
with such hosts, even if the user is willing to connect CCs to
parameters manually."

What's 'homework'? Why 'not work at all'?

      TIA,
        -- Chris G.

David wrote: 
On Wednesday 28 April 2004 10.11, Chris Grigg wrote:
[...]

 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.)


Though it's probably a bad idea to build anything that's inherently
very resource intensive into the API, I don't think this is an issue,
unless we actually use an string as the address field of every single
event.

If we use these strings only when making connections, we can implement
grouping, indexing, hints and whatnot on that level. Plugins could
have an interface looking something like this:

GMPI_target *connect(GMPI_plugin *p, const char *name);

where 'name' is this OSC style parameter name, and the result is an
"event target", looking something like this:

        typedef struct
        {
                GMPI_queue      *queue;
                uint32_t        id;
        } GMPI_target;

So, the plugin gets to pick an event queue and an ID for each control.
The plugin can have separate queues for separate internal loops to
avoid internal event dispatching, and to reduce the need for
sort/merge operations when sending events from other plugins. The
'id' can be a plain index, a few bitfields for multidimensional
indexing, or whatever fits the internal design best. No need to
explicitly define a number of indexing dimensions - anything that can
be described with the OSC style addressing scheme will work just
fine.


As to specifically dealing with GM, beyond just hinting what
corresponds to a MIDI channel, and which parameters correspond to
what MIDI CCs, that seems like a bad idea to me. Such a feature would
be of use only to host authors who want to send MIDI to synth plugins
without doing their homework - and it would only work with synths
that actually care to implement it. Other synths wouldn't work at all
with such hosts, even if the user is willing to connect CCs to
parameters manually.

Or maybe I'm just not getting it...?


//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---


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



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