[gmpi] Re: 3.11 topic: Dynamic plugin structure
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 30 Apr 2004 11:42:11 +0200
On Wednesday 28 April 2004 21.37, Tim Hockin wrote:
> On Wed, Apr 28, 2004 at 12:57:58PM -0600, Mike Berry wrote:
> > - Plugin has 3 parameters. The user creates some automation for
> > them. - The user switch the parameter list, so that now there are
> > 4 parameters, where the first 2 have the same characteristics as
> > before the change, and the second 2 are completely new.
> >
> > The user may well expect for the automation from the first two
> > parameters be preserved. But this can get rather nasty from the
> > host point of view. We have no concept of "orphan" automation
> > tracks, as Sonar apparently does, and adding it would be a major
> > feature. And I can see some reattachment issue there too.
>
> I'd say that you can dump 'orphaned' info, but keep the params that
> stayed the same. But I see your point...
>
> > So my real goal is to design it in such a way that the user
> > assumes that this is a NEW plugin after this change, and they
> > should not expect anything to be preserved (though individual
> > hosts may choose to preserve as a feature). So I am worried if
> > this is initiated in the plugin, because then the host can't make
> > sure that the user gets the right impression. I.e. I would prefer
> > that the user make a switch in the host as opposed to pressing a
> > button in the plugin.
>
> But how can that work? Need to think more on it..
How about something like this:
host:
#define GMPI_STRUCT_ADD 0x...
#define GMPI_STRUCT_REMOVE 0x...
/*
* Ask the host if it's ok to make the structure
* change described by 'paramid' and 'flags'.
* Returns 1 if the change is allowed, otherwise 0.
*/
int (structure_check*)(GMPI_host *h, GMPI_plugin *p,
int paramid, int flags);
plugin:
#define GMPI_PROP_STRUCTURE 0x...
/*
* Try to set property 'propid' to 'v'.
* Returns a negative value if the change failed,
* otherwise 0.
*/
int (set_property*)(GMPI_plugin *p,
int propid, double v, int flags);
When the host wants plugins to ask before changing their structure, it
just adds GMPI_PROP_STRUCTURE to the 'flags' argument. Then, if the
property change results in any parameters being added or removed, the
plugin will ask host->structure_check() if each change is ok. If any
change is refused, the plugin refuses the property change and
plugin->set_property() returns an error code.
I don't quite like the "the plugin refuses the property change" part,
though... To do that, plugins must separate the "figure out what will
change" part from actually performing the structure change, or have
some way of backing the change out if there's a failure somewhere in
the middle.
//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: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
