[gmpi] Re: my first ideas

  • From: David Olofson <david@xxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Tue, 11 Feb 2003 15:29:26 +0100

On Tuesday 11 February 2003 15.06, Urs Heckmann wrote:
[...]
> 1.) Seperation of Process and GUI

=2E..which is basically *required* to run plugins in-process on some=20
platforms. You simply cannot have GUI code in a plugin that's loaded=20
as a DLL/shared lib into a host, unless the plugin uses only GUI=20
features provided by the host.


> If user interface and process are different things/applications
> from the beginning, it is easier to customize access to the process
> for certain needs. A PlugIn could offer more than one view
> (newbie/expert) or a collection of plugs could be controlled by the
> same view (a generic user interface with company-typic layout). A
> PlugIn could also be easier controlled in uncommon environments
> like games, video editing software if it doesn't feel naked without
> its gui.

Those are other good reasons to do it this way.


> This implicitly requires a flexible parameter handling and
> notification scheme.

Yep.

IMHO, this communication should be performed using the same basic=20
interface as is used for control/automation. I don't like the idea of=20
plugins having "private" interfaces for their GUIs, as that=20
unavoidibly forces non-portable code into both parts of plugins.=20
(Portable GUIs is a serious problem as it is.)

I think using the same basic API for GUIs as for DSP plugins would be=20
a nice and clean solution, and I intend to try this with XAP.=20
(http://olofson.net/xap)

The idea is that plugins can suggest another plugin (by unique ID) if=20
the host wants to fire up a GUI. When the host looks for that plugin,=20
it will generally find that it's an executable that's meant to be=20
started as a separate process. The host will start the GUI plugin,=20
setting up a "gateway node" in the local audio plugin net. The=20
gateway node will appear as a normal plugin, ready for connections.=20
The host will take care of the issues of communication between the=20
hard RT domain and the outside (soft RT) world, and pipe incoming and=20
outgoing events from/to the external GUI "plugin" process.

I will report back when I know how it turns out.


Note that this approach also works for plugins with very high=20
bandwidth interaction between the DSP plugin and the GUI. Just have=20
the DSP GUI refer to a "local proxy" plugin, which is to run=20
in-process along with the DSP plugin. (For shared memory to directly=20
operate on samples and whatnot.) The "local proxy" would in turn,=20
request another GUI plugin, which is the usual out-of-process GUI.

That way, you can move the split point for IPC to some suitable point,=20
and still have a clean DSP plugin (ie no special editing features=20
built into it) as well as the GUI stuff in an external or even remote=20
process.


> 2.) Timestamp for any kind of host-plugin notification
>
> Automation data, parameter setting, Midi events should all be
> timestamped. Sample accuracy will do.

I totally agree, FWIW.


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---

----------------------------------------------------------------------
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: