[gmpi] Re: 3.11 topic: Inter-parameter linkages
- From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Mon, 12 Apr 2004 18:11:18 -0400
> 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
Other related posts:
