[gmpi] Re: 3.11 topic: Dynamic plugin structure

> 2) Can the host change the parameter list?

I think only the plugin should, as it 'knows' what combinations are allowed.

> 3) Does the host need to give an OK for a plugin to change its own IO
config?

It kinda has to really, some hosts only allow certain classes of plugins,
e.g. a master effect must be stereo (not mono).

> This brings up a few more thoughts.  Firstly, we need to provide a
> state-header or something, which gets saved and restored before the
> parameter values.  Plugins with dynamic structures can put something in
> there to define the structure.  Simple plugins can ignore it.

Yes, I was thinking the properties could hold that info.  The host first
restores the properties, then queries the plugin config.
  The plugin can expose as many or few properties as needed.  This lets the
plugin control what information it needs (mayby only one property, e.g.
mono/stereo, or it may need several)..

Best Regards,
Jeff

----- Original Message ----- 
From: "Tim Hockin" <thockin@xxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Tuesday, April 27, 2004 10:45 AM
Subject: [gmpi] Re: 3.11 topic: Dynamic plugin structure


> Sorry to be so quiet lately - been digesting and dealing with life.
>
> On Mon, Apr 26, 2004 at 01:15:41PM +1200, Jeff McClintock wrote:
> > AU does it in a very generic way,  the plugin has "Properties", unlike
> > parameters, properties are not automatable.  They're stuff that dosn't
> > change much (plugin name, parameter list etc).
>
> OK, I can deal with this, I think.
>
> A few more questions before final reqs on this, maybe.
>
> 1) Does the host need to give an OK for a plugin to change its own
parameter
> list?
>
> 2) Can the host change the parameter list?
>
> 3) Does the host need to give an OK for a plugin to change its own IO
config?
>
> 4) Can the host change the IO config?
>
>
> (I know the IO configuration doesn't belong in this section, but they seem
> to be isomorphic, so maybe we can solve them together?)
>
> This brings up a few more thoughts.  Firstly, we need to provide a
> state-header or something, which gets saved and restored before the
> parameter values.  Plugins with dynamic structures can put something in
> there to define the structure.  Simple plugins can ignore it.
>
> Secondly, we probably need a way to group parameters together.  Is one
> level of parameter grouping enough?  Does it need to be arbitrarily
> nested?
>
> Thirdly, we will still have to solve multi-channel plugins - how do you
> save a single patch vs an entire snapshot of all the channels?  And do we
> codify MIDI-like channels?



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