[gmpi] Re: 3.11 Parameters

  • From: Tim Hockin <thockin@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 31 Mar 2004 09:31:19 -0800

On Wed, Mar 31, 2004 at 09:46:22AM -0700, Mike Berry wrote:
>       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 

I can answer that based on my theoretical "modules" model.  It doesn't
change in realtime.  Adding/removing modules is a permanent change, not a
parameter-like change.  So Your UI shows all the params of all the modules
of a plugin.  You can't add or remove a module without the host, so there is
no sync issue.  If you delet a module for which you have automation, maybe
warn about it, but if the user says YES, then the automation should be gone
(host can save it or trash it or whatever).

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

Yeech.  Way too dynamic for me.  I think something like a modular structure
gives flexibility to the user with making it relatively simple for the host.

>       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 

yes - I have been saying "modules", you just said it a different way.
Whether it is part of a parametr-like API or a separate module API, it is
NOT AUTOMATABLE.

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

Yeah, I can see that.  If we do dynamic-ish I/O things like that may have to
change slightly.  Conversely, Your host could disallow module changes, and
have "preset" of the mono module n the mono list, and a "preset" of the
stereo module in the stereo list.

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

heh, that's what I just said before I read this.  Exactly.

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

Me too!  Cleaner and more "correct"

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