[gmpi] Re: 3.11 topic: Inter-parameter linkages
- From: "Koen Tanghe" <koen@xxxxxxxxxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Fri, 9 Apr 2004 00:10:45 +0200
On Thursday, April 08, 2004 11:40 PM [GMT+1=CET],
Jeff McClintock <xxxjeffmcc@xxxxxxxxxxxxx> wrote:
> May I suggest the plugin need know nothing about morphing.
>
> The host has access to all parameters and programs. The host should morph
> between programs. Importantly, it is also in a position to update the GUI
> and motorised faders. Also, because the host is performing the morph, it
> can store the entire morph as a single 'undo' event.
>
> The host is the center-point. The hub of a music system, it's where all
> various controllers (hardware, GUI, MIDI) come together. The host has the
> overview required to make the morph work correctly.
>
> This approach requires some re-thinking about the 'traditional' roles of
> host and plugin. But why re-write complicated morphing code for every
> plugin?, just write it once, put it in the host.
>
> All plugins then become simple to write (expose your parameters, respond
> to parameter changes from host, that's it.) yet all plugins get cool
> morphing features for 'free'.
>
> Whe've got to stop thinking of plugins as sofware versions of hardware
> boxes. Some functions make much more sense implemented in the host.
I'm with you! I would also like it very much if every host would have
morphing capabilities.
But the problem is that if you want to let the host handle this, it will
need to be a requirement for *all* hosts. The reason why people are building
the morphing into plugins themselves is because some hosts don't allow that,
and then there you are: you have a cool plugin that just screams for
morphing, and your users start complaining that they can't do it in their
host. So what do you do: you build it into your plugin...
I don't necessarily want to bother host makers with providing morphing
functionality: if they think it's not useful, so be it. But the least it
could do is offer a way to let a plugin tell it that a parameter was changed
so that updates can propagate to what needs to be updated.
I fully agree that the host plays a central role in functionality like this.
In my head, it's like you can do it two ways (just sketching the extremes
here): either you (1) require all hosts to support specified functionality
towards the plugins so that the whole plugin/host system can become simpler,
but also quite tight (not always good), or (2) you make sure that the
absolutely basic necessary functionality (usually simple) is there so that
plugins can make use of that to support the functionality they need.
Letting the host do the morphing would be like a (1) thing. Making
provisions for bidirectional host/plugin communication would be more like a
(2) thing.
In this case I tend to go for the (2) direction, because it seems like
easier for a plugin maker to make extensions in the future *if* the basic
blocks are there...
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:
