[gmpi] Re: 3.11 topic: Inter-parameter linkages
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 6 Apr 2004 01:06:58 -0700
On Tue, Apr 06, 2004 at 08:45:38AM +0100, Steve Harris wrote:
> On Mon, Apr 05, 2004 at 06:13:13 -0700, Tim Hockin wrote:
> > It's not illegal, it's a conflict. The plugin is a controller of itself.
> > It should be clear to the end user that changing A changes B. Automating B
> > and A at the same time *IS* a conflict. Two controllers are trying to
> > change the same item. I don't see this as wrong, just a documentum.
>
> Redefining it as a conflict doesnt make it any easier to implement :)
But it does relieve us of the burden of eliminating it ;)
> > First, there is a req (currently #52) that all params are automatable.
>
> It wouldn't be a parameter if it only existed in the UI, he says
> hypocritically.
Maybe it's too late for me to get your UK humour. ??
> > Secondly, I see two potential ways of making this work, neither perfect:
> >
> > 1) The internal change is merely a callback to listeners, not an event. It
> > is not seen as an undoable event. Modifying the child parameter (from GUI,
> > MIDI, or automation) while the parent is also being modified will result in
> > a conflict. This is correct behavior. Undoing a change to the parent would
> > not undo the child (unless we do more than simple callback).
>
> Ugh. How will the host deistinguish that from an undoable event - what
> happens if theres a subsequent or simultaneous change on that parameter -
> what will hte host record in its automation lists?
The host records the automation initiated by the user. That is the CORRECT
automation to record. Internally-initiated changes (such as the parameter
dependencies) should NOT be recorded as automation.
If you record user-initiated events for a parameter that also receives
internally initiated events, it is a conflict. Don't do that. There's
nothing to FIX there.
Where this falls down (I'm still working on it :) is two places:
- You change A from GUI and it internally changes B. Then you undo the
change to A. How does the host know to undo B?
- You autote A and B. Changing A may change B. When it does, you have a
conflict. However, the host can't resolve the conflict because it is not
seeing events from the plugin to itself.
> The conflict issue is clearer I think - if param A gets set to log(B)
> when B is changed, you cant automate A and B.
Correct. Now, one might argue that if B always changes based on A, perhaps
it is not a separate parameter at all. But we absolutely need to handle
patch morphing.
User hits a button in the plugin. The plugin morphs all it's parameters
into new values. While that morph is going, what happens if you automate a
parameter? A conflict.
> With the UI performing the morph for the morph testcase its not that its
> unautomatable, its just that whats recorded is the real parameter changes -
So I can't trigger the morph except through the GUI? Faceless plugins can't
do morphing? If we mandate custom GUIs for advanced things like this, then
you're right, maybe. To start a morph you'd send an event to a parameter of
the GUI, not of the DSP.
But is that ok that this requires a GUI?
> If morph control is more fundamental (eg. in a vector synth) then you can
> represent morph extreme X as one set of parameters and morph extreme Y as
> another set, with a morph parameter to cross between them. This allows
> full automation without conflicts. The UI can still calculate and display
> the 'live' parameter values the synth is using (or receive control outputs
> form the DSP code).
This seems to be a workaround for a design shortcoming, to me. Are we
thinking up workarounds already? :)
I'm going to go to bed and think about this some more.
----------------------------------------------------------------------
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:
