[gmpi] Re: 3.11 topic: Inter-parameter linkages
- From: Steve Harris <S.W.Harris@xxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Sun, 11 Apr 2004 00:01:57 +0100
On Sat, Apr 10, 2004 at 03:54:13 -0700, Tim Hockin wrote:
> Of course - every plugin API out there today does not allow the conceptual
> split between a GUI and a DSP plugin. How does it not provide your feature,
> or rather, what exactly are you meaning when you say "morph" ? :)
I mean a control that crossfades between two sets of control values.
> OK, So you duplicate all your parameters. You set up A's patch and B's
> patch. Then you start the morph. Assume I have an motorized fader attached
> to a parameter of this plugin or an auto-generated GUI for it. What gets
> reported to the GUI as the morph happens? Nothing?
Whatever you like. A motorised control surface is drived by a GMPI UI (of
some kind, may be host native), so it can do whatever it thinks is
approriate.
> > > Example, min + width. Changing a parameter which clips must be reflected
> > > in
> > > all UIs.
> >
> > Surely that would be changing a parameter changes the range of another?
> > Noones discussed that AFAIK.
>
> We have discussed this very example many times. It's something that at
> least one plugin does right now with VST. It's not exactly a VST-supported
> operation, but it works.
OK, but its still no relevant here; it doesn't require DSP plugins to
change thier inputs.
> > > 2) There needs to be a clean way to do a plugin-centric morph (as opposed
> > > to
> > > host-based) which is undoable, and which updates all UIs (motorized
> > > faders,
> > > automatic GUIs, custom GUIs).
> >
> > I think I've outlined one, please tell me why it doesnt work - I think
>
> Well, unless I'm STILL missing something, tehre is no UI feedback as to the
> current state of morph. There is no way to record the automation that
> occurs during a morph.
The automation is recorded (its represented in the state of the
parameters, hence its recorded). The current state can be displayed
however is appropriate.
> > I've pointed out why having the DSP code do parameter updates is
> > problematic.
>
> And I've solved the problems in a simple way. Mike has proposed something
> very similar.
Some of the problems - theres still some outstanding issus with RT
feedback + the things Ron raised.
> > > Bonus points for making plugin-centric morphs/randomizations be optionall
> > > recordable or not as automation.
> >
> > "Not automatable" just happens as the use can elect not to automate that
> > parameter. I think the method I've suggested habdles the automatable
> > requirement.
>
> I didn't say automatable, I sadi recordable. Record the actual morph of all
> the parameters as N automation segments.
In this case I think sutomatable and recordable are synonymous - there is
only a distinction when you let plugins write to thier inputs.
- Steve
----------------------------------------------------------------------
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:
