[gmpi] Re: 3.11 topic: Inter-parameter linkages
- From: "Jeff McClintock" <jeffmcc@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Tue, 13 Apr 2004 12:20:42 +1200
> this all seems quite wrong to me.
>
> the DSP part of a plugin is the only object in a position to accept or
> reject parameter changes. if you want to do this in an MVC style (and
> we should), it has to happen like this:
>
> a) a request to change parameters can never be assumed to
> succeed
> b) parameters are never believed to have changed until
> the DSP notifies someone of a change.
Hi Paul,
What is you are proposing is a legitimate option. However it's a worse
option.
Imagine connecting a GUI knob to two plugins...
1) User moves knob (from 8 to 10), parameter-change event is qued for both
plugin.
2) Plugin A executes it's timeslice, it's output now reflects the parameter
change.
3) Plugin B executes it's timeslice, It's rejects the parameter change,
sends a message back to the GUI "I don't accept that, set knob back to 8")
What does the host do?, re-execute Plugin A's timeslice? (after somehow
re-setting it's entire state). What if 10 plugins are involved?, It gets
real complicated, real fast. In fact this is the definition of
"non-deterministic", and is the reason VST has 'issues'.
Secondly, you end up with a situation when the user can move the GUI slider,
but the plugin can "jump" it back. I stupidly tried this approach once.
You get GUI elements that visibly "jitter" as they come up against the DSP's
parameter-clipping point , very amateur looking.
There is only one model that works cleanly.
The host controls the parameter. If the value is "out of range", the DSP
silently clips the value for it's own use.
This is still the MVC (Model-View-Controller) system, except the host is
the model (not the DSP).
The host, plugin custom GUI, is the place for enforcing parameter rules
(linkage, randomisation, clipping, morphing etc).
Anyway, Mike explained it better than me.
Best Regards,
Jeff
----- Original Message -----
From: "Paul Davis" <paul@xxxxxxxxxxxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Tuesday, April 13, 2004 10:11 AM
Subject: [gmpi] Re: 3.11 topic: Inter-parameter linkages
> > The whole point is that contained plugins (the DSP part) cannot change
> >parameters, ever. The contained plugin is only a parameter sink.
> >
> > So taking the nested plugin example, with the actor design, where you
> >have the host, plugin A in the host, and plugin B in plugin A:
> >
> >- Host receives a parameter change from the UI. This could be the UI of
> >plugin B, which notifies the UI handler in plugin A, which notifies the
> >UI handler in the host. Note that because the host does not know about
> >plugin B, the parameter change to the host has to be a parameter on A.
> >Note that this happened on the UI thread.
> >
> >- Host calls the param actor for plugin A. This can happen on the UI
> >thread or the process thread, depending on the host's design.
> >
> >- Plugin A calls the param actor for plugin B, which returns one or more
> >events after its translation.
> >
> >- Plugin A translates these events into its own parameters and returns
> >them to the host.
>
> this was starting to look good (very Model-View-Controller-ish), but
> now its getting terribly muddy :)
>
> 1) parameter changes can be initiated in any thread, with the possible
> exclusion of the process thread. they could arrive from a GUI,
> a hardware control surface connected via MIDI or ethernet, from
> other programs via sockets or pipes or other IPC mechanisms,
> and so on and so forth.
>
> 2) there is a much better pattern in the gofai book for undo, its
> called "Memento". i suggest that we all read it - i think most
> people have access to it.
>
> >- The host now has all of the parameter events that are associated with
> >the single parameter change received from plugin A. If it is recording
> >an undoable action, it can close the action. This has all happened
> >synchronously and at a time of the host's choosing. If the host is not
> >currently processing, it is done, after storing the new events in its
> >own parameter storage. Also at this time, it broadcasts an async message
> >to all of the listeners of all of the affected parameters (not the DSP
> >now, as it is not an async listener).
> >
> >- When the host is processing, then it pushes down the relevant
> >parameter events to the DSP of plugin A, which then forwards them to
> >plugin B. Neither DSP can take any action on these events, other than
> >accepting them or ignoring them if they are for some reason erroneous.
> >This, obviously, happens on the process thread.
>
> this all seems quite wrong to me.
>
> the DSP part of a plugin is the only object in a position to accept or
> reject parameter changes. if you want to do this in an MVC style (and
> we should), it has to happen like this:
>
> a) a request to change parameters can never be assumed to
> succeed
> b) parameters are never believed to have changed until
> the DSP notifies someone of a change.
>
> that doesn't mean that some other object can't act as a proxy between
> the host and the plugin (or other participants), but no parameter
> change can be considered complete without someone actually telling the
> DSP about and getting a notification.
>
> if you want to undo, you need to to do it "anonymously" in the sense
> that the information you get as a Memento should not be assumed to be
> understandable within the host. its something to give *back* to the
> plugin (or actor, or whatever) when you want to revert the change. its
> contents are opaque.
>
> --p
>
>
> ----------------------------------------------------------------------
> 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
>
>
>
----------------------------------------------------------------------
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:
