[gmpi] Re: 3.11 Parameters
- From: Mike Berry <mberry@xxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 31 Mar 2004 09:46:22 -0700
Paul Davis wrote:
On Wed, Mar 31, 2004 at 09:41:27AM -0500, Ron Kuper wrote:
As much as I want to say "no", I think we have to say "yes." There are
some analog modeling synths out there that expose many hundreds of
parameters, most of them exposed only because the user might enable a
particular oscillator in the synth. This forces the user to see all
kinds of irrelevant parameters when creating automation data in the
host.
I would say that that kind of plugin is not useful without a custom UI,
and in which case the show/hide behaviour of parameters can be controlled
by the UI. They dont have to be hidden form the host, jsut the user.
not so. any host that allows graphical creation of user data will
need to offer the user a list of parameters that can potentially be
edited.
think of automation tracks/lines in any DAW.
--p
This is the case I am particularly woried about. Premiere presents all
of the parameters of an effect as rubberbands in the timeline view. I am
extremely worried about having the host view of the parameter list that
can change dynamically. What is our UI supposed to do when the parameter
that we are displaying disappears at time X? The answer isn't simply not
show it for the range of time that it is gone. How do we find out that
range? Test the plugin at all possible times? We can't ask the plugin
because it doesn't access to all parameter values at all times.
Dynamic alteration of inputs and outputs is even worse for us. In fact,
I can't really conceive of how it works for any host. Lets say the
plugin at time X has 2 inputs. Then at time Y it has no inputs. Then at
time Z it has 2 inputs again. Does it expect that the connections from
time X are in force at time Z? What if the inputs are completely
different at time Z? How can the graph change during play?
There is a more limited subset of this, which is that only
non-automatable parameters can cause structural changes, so you would
never get the graph changing during playback. This is also a problem for
us, though less of one. Which list a plugin is available in is dependent
upon its input/output configuration. So if, after instantiation, a user
can change the plugin from mono to stereo output, this would kill our
classification system.
The alternative to this that we need is for the plugin to declare
configurations. So, for instance, a channel volume filter might declare
3 configurations:
Inputs Outputs Parameters
Mono 1 1 1
Stereo 2 2 2
5.1 6 6 6
We could then load the first configuration in the list of mono track
plugins, the second on stereo tracks, etc... The plugin would then be
instantiated in a single configuration and that instantiation could not
be changed.
Of course, this could be done by separate plugins, as you would have to
do now with VST, but I think it is much cleaner to have it all in one
plugin.
--
Mike Berry
Adobe Systems
----------------------------------------------------------------------
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: