Subject: Re: [linux-audio-dev] Mustajuuri -> LADSPA plugins.
From: Stefan Kersten (steve_AT_k-hornz.de)
Date: Thu Mar 29 2001 - 23:35:16 EEST
Paul Davis wrote:
>
> >Hey, OpenSoundControl may just be the right candidate for the
> >communication part; no messing around with shared memory, but
> >instead using Unix/UDP[/TCP] sockets. The plugin GUI could even
> >run on a different machine or you could (given the host's OSC
> >address space is standardized somehow) control a plugin's
> >parameters algorithmically or whatever outside your favorite
> >sequencing/programming environment. Just an idea ...
>
> i want to thank stefan for mentioning OSC. i think this is by far the
> best idea. we just have to figure out the namespace for ladspa plugins
> within the host. everybody should be using OSC :) so, i suggest that
> we dump the LADPSA_Parameter_Change struct, and instead plan to use
> OSC. the host needs to provide "its" name and some identifier for the
> plugin. these would get passed to the GUI, and then the GUI would be
> sending stuff like:
>
> "/host's name/plugin id/control/port/port id/value"
I think a basic scheme of operation could be:
A given host would, upon plugin instantiation, dynamically extend
its OSC address space as suggested above by Paul, maybe including
the case of 1..N plugin instances (?) (which could be controlled
by a single GUI or by several ones):
/plugins/<host-ID>/<plugin-ID>/<plugin-instance-ID>/control/port/<port-ID>/value
The messages represent the communication 'nodes' that actually
take the parameter values and send them to the plugin (via normal
float writes in a callback). Additionally the plugin GUI process
would have to provide an address space known to the host in order
to be able to update its interface whenever the host changes a
parameter (I guess that's possible in LDSPA?):
/plugins/<host-ID>/<plugin-ID>/<plugin-instance-ID>/control/port/<port-ID>/value
The setup would thus looks like:
HOST -----------> PLUGIN
| ^
v |
[NETWORK (Unix/UDP/TCP)]
| ^
v |
CONTROL
So, in the GUI case, the plugin would start a new process on
instantiation which then connects to the host while providing a
return address to the host (such that the host can communicate
parameter changes back to the controlling process).
IMO the benefits are:
- Having a (more or less) standardized protocol that proved to be
reliable in a number of applications
- Being able to pass messages from the GUI to the plugin and vice
versa that do not have to be seen by the host and thus can have an
arbitrary (OSC) format
- Being able to control a plugin instance by other means than a
dedicated (GUI) process very easily
- Not being limited to processes on one machhine
Sidenote: as soon as the OSC library implementation is complete,
the address space spanned by a host could be queried from outside,
including argument types (well, floats, in our case), value ranges
and documentation strings (OSC is at
http://cnmat.cnmat.berkeley.edu/OpenSoundControl/).
<sk>
This archive was generated by hypermail 2b28 : Sat Apr 07 2001 - 15:57:38 EEST