[gmpi] Re: 3.11 topic: Dynamic plugin structure

On Thursday 29 April 2004 06.44, Tim Hockin wrote:
> On Wed, Apr 28, 2004 at 11:03:13PM +0200, David Olofson wrote:
> > Yes, that's a good point. I'm beginning to really rather like the
> > "hardwired" 1D indexing variant, assuming it really does meet the
> > requirements.
>
> Ehh, which variant is that?  :)

Uhm, I think that was the original idea, where a plugin presents one 
set of master parameters, and an array of channel parameters, where 
all channels must have the same set of parameters.

Beyond that, it starts to look too hairy, considering that it still 
can't *totally* eliminate string parsing in reasonably advanced hosts 
- which is why I'm back on the array of strings side. :-)


> > > I would suggest it's a mistake to see channel-based internal
> > > organization primarily as a MIDI thing.  Yes, MIDI has a
> > > channel-oriented message structure, but mixers have the same
> > > structure.
> >
> > I was rather thinking the other way around; *more* dimensions,
> > not fewer. How about module/group/subgroup/channel/unit? ;-)
>
> nonono. You want groups?  Arbitrary grouping.  We provide channels
> for plugins that find that to make sense for them.  GM synths will
> use them. Maybe big-boys will use them.  Some other plugs, like a
> mixer, might use them.  Most plugs won't.  Groups, however, are
> nice for all sorts of plugins.

Yes, but that's not what I was thinking about. I meant that *any* node 
could be 1D indexed - maybe even parameters; not just one node in a 
path. Consider this:

        "bus[0]/master
        "bus[0]/send[0]
        "bus[0]/send[1]
        "bus[1]/master
        "bus[1]/send[0]
        "bus[1]/send[1]
        "channel[0]/fader"
        "channel[0]/bus[0]"
        "channel[0]/bus[1]"
        "channel[0]/insert[0]/threshold
        "channel[0]/insert[0]/attack
        "channel[0]/insert[0]/release
        "channel[0]/insert[1]/f0
        "channel[0]/insert[1]/Q
        "channel[0]/insert[1]/gain
        "channel[1]/fader"
        "channel[1]/bus[0]"
        "channel[1]/bus[1]"
        "channel[1]/insert[0]/delay
        "channel[1]/insert[0]/feedback


> > > All that /-fu for channel indexing and slot type specification
> > > is unnecessary and just needs to get unpacked later.
> >
> > Yeah, it's quite pointless as long as only one level of 1D
> > indexing is needed anyway...
>
> Just because we export a 1-dimensional array of strings, doesn't
> mean there is not deep structure.

Right - but how do you deal with more than one dimension (above) with 
that kind of interface? With plain strings, it seems a lot more 
straightforward.


> > > Minor point: There's more room for transcription errors in the
> > > one big literal string table you suggest, whereas this approach
> > > actually enforces the plug structure in the param names table.
> >
> > Yeah, another good point.
>
> red herring.  You store internally an array of params for each
> 'module'. When you want to load a new module you insert copies of
> those strings.  I think the right answer may be a hybrid of the
> two.
>
> /* internal */
> static char *master_params[] = {
>       "gain", "pan", NULL
> };
> static char *channel_params[] = {
>       "osc/shape", "osc/octave", "filter/cutoff", "filter/resonance",
>       NULL
> };
>
> /* exposed somehow */
> char **all_params[] {
>       master_params,
>       channel_params,
>       channel_params,
>       channel_params,
> };
>
> This results in a synth with 4 channels (well, master + 3 channels,
> assuming master is always 0).  It doesn't need to have 3 or 4
> paralell interlinked arrays.
>
> Really though, a channel might have more info than just parameters.
>  How about IOs?  Any meta data?  Better perhaps to just call it an
> array of channels?  We can then define a channel as some structure
> encapsulating it all.

Well, every leaf node corresponds to *some* kind of actual, physical 
interface in the plugin...

Earlier, I've proposed a plugin call connect() that takes a string 
("full path") to a parameter (leaf node), and returns a 
{ GMPI_evqueue *q; int id; } struct that tells senders where to send 
events (q), and what destination address to stamp them with (id).

Now, if we split the connect() call into lookup and connection, we can 
have a call GMPI_node *lookup(GMPI_plugin *p, const char *name), 
where GMPI_node is something like this:

        struct GMPI_node
        {
                GMPI_nodetype   type;
                uint32_t        id;
        };

'type' would be one of GMPI_GROUP, GMPI_PROPERTY, GMPI_PARAMETER, 
GMPI_AUDIOIN, GMPI_AUDIOOUT etc, and 'id' is an opaque address field. 
Then we can just pass this to the plugin calls for making connections 
and stuff. Node types can be added for other objects, or we can add 
plugin calls to get more detailed information on nodes. (I think I 
prefer the latter.)


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

Other related posts: