[gmpi] Re: 3.11 mini-wrap: Dynamic params/multi-timbral
- From: "Koen Tanghe" <koen@xxxxxxxxxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Fri, 30 Apr 2004 00:58:26 +0200
On Thursday, April 29, 2004 9:05 AM [GMT+1=CET],
Tim Hockin <xxxthockin@xxxxxxxxxxxxx> wrote:
Thanks Tim, very helpful!
> -------------
> * GMPI must support dynamic parameter lists. When the parameter list
> changes, the host must be notified by the plugin. Hosts must be able to
> deny a parameter list change.
OK.
I would rather see hosts always except parameter list changes, but if there
are good reasons why hosts cannot always do that, that's OK. Or maybe it
would be possible to specify in which cases changes must be accepted and in
which cases they might be rejected? But we probably don't know this yet?
> More on this requirement:
>
> During discussion with the GMPI working group, dynamic plugin structures
> was determined to be an elegant solution to a number of specific use
> cases. Thise use cases are included here.
All good use cases, yes.
> <SNIP>
> -------------
> * There must be a way for GMPI plugins to save and restore their
> parameter-list structure with a patch.
OK.
> -------------
> * GMPI must support grouping of associated parameters. Grouping may be
> arbitrarily deeply nested.
> -------------
OK.
This is an arbitrary tree structure, right?
> -------------
> * GMPI must support multi-channel plugins. Each channel may have any
> number of parameters and/or IOs. There may be an arbitrary number of
> channels per plugin. It must be possible for a host to save a just a
> single channel's patch as well as the entire state of a plugin.
OK. I understand the need for this from the GM use case.
Is something like the following implied by the above:
"It must be possible for the host to distinguish channel groupings (which
have a specific meaning known by the host) from arbitrary groupings (which
only have a meaning to the plugin)".
Regarding the OSC-style addressing: I like that best.
It's true though that we would probably only borrow the addressing scheme
from OSC.
I also agree with the fact that a typo in a string is going to be more
annoying for a programmer than a typo in a variable/enum name (compiler sees
this). But I think I'd type the strings directly only once (in a constant
string declaration), and then use the constant's names anywhere else.
I guess another option would be to explicitely define a parameter tree
structure, and then add your groups and parameters as nodes resp. leaves
with addNode/addLeaf functions, where each node/leaf is an object that can
have extra properties.
Don't know... Might be too complex, and implementation stuff anyway.
Koen
----------------------------------------------------------------------
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:
