Re: [linux-audio-dev] Mustajuuri -> LADSPA plugins.

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Mustajuuri -> LADSPA plugins.
From: Stefan Kersten (steve_AT_k-hornz.de)
Date: Sat Mar 31 2001 - 12:49:31 EEST


Hmm, seems like my original message didn't make it to the list;
maybe this time ...

Paul Davis wrote:
>
> >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>/val
> >ue
>
> my conception was that the host, which will have to look up the plugin
> instance in order to "execute" the message, would provide the
> plugin-ID to the plugin (and thus in turn the GUI). this would "fold"
> the "plugin-ID" and the "plugin-instance-ID" into a single
> name. problems ?

No, I guess not.

> also, why the /plugins prefix ? my understanding is that OSC is tree
> structured - you want the top level address to refer to the intended
> recipient of the message, which is presumable <host-ID>.

Well, as we all should use OSC, why not use it for other things
than plugin
communication :)

OSC containers (anything below leave nodes) simply contain other
containers or messages, without any other semantics whatsoever
(the prefix really should be something like 'LADSPA', though).

> >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?):
>
> this is a good point. however, the OSC id you gave doesn't suggest to
> me how to do that ...
>
> >/plugins/<host-ID>/<plugin-ID>/<plugin-instance-ID>/control/port/<port-ID>/val
> >ue

What I thought of was:

1. The host instantiates a plugin and passes (hostname, port) and
plugin-ID
2. The plugin (optionally) starts a control process and passes
plugin-ID and (hostname, port)
3. The control process registers with the host and in return gets
host-ID, while the host has to associate plugin-ID with the client
address.

Now the host knows how to construct an OSC message like the above
and can send one with the appropriate floating point argument any
time a plugin parameter is changed internally.

Too simple? Too complex?

<sk>


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sat Apr 07 2001 - 15:57:54 EEST