Re: [linux-audio-dev] LADSPA 2

On Sat, Apr 22, 2006 at 04:48:28 -0400, Dave Robillard wrote:
> > > Well, at least one kind of separator character is required (for big
> > > plugins). If it can't be ":", then I don't know what, but there needs
> > > to be something. Maybe "."? If you want to keep it as a valid C
> > > identifier I guess we're pretty much screwed, aside from defining __ to
> > > be interpreted as a sort of heirarchialish separator.
> >
> > I'm missing the need for heirachicalness. : is probably not safe in OSC
> > either.
>
> voice_1_osc_1_volume
> voice_2_osc_3_volume

That looks fine to me...
 
> Or metaplugins (which ability to load libraries will surely spawn).
>
> subplug_1_param1
> subplug_2_param4
>
> ... ugh
>
> voice_1.osc_1.volume

Hum, that looks suspiciously like its expressing some semantics that don't
exist to me, and could potentially conflict with the port name (UI)
semantics "Osc 1/Frequency" etc.
 
> ... oh so much nicer. There already exists a few DSSI plugins with
> ports like this. Surely there's got to be /one/ more sensible character
> we can add? (It needs to be valid as a jack port name as well)

But you're not talking about anything hard, its just a symbol name, used
to refer to the port, sometimes... I'm starting to go off this idea, noone
else has spoken in defense of it, and it raises some issues.
 
> > > I'm fully in support of putting any and all metadata outside the C file,
> > > but the unique identifier isn't metadata, it should be in the code. A
> > > trivial OSC controlled plugin host (which would make a good bundled
> > > example client for the SDK) would need it.
> >
> > It's only /a/ unique identifier. We can't loose the index number as thats
> > the efficent way you access the LADSPA_Data pointers. Only one can be
> > canonical.
>
> I think the above case of a trivial C host requiring it is justification
> enough to have it in the code. Think about an engine/client split
> system (where the engine might be something that doesn't have the
> resources to load metadata and parse RDF etc, eg a DSP). The metadata
> would be client-side, but the plugin engine-side, so the engine needs
> access to the label in order to provide the nicer (eg) OSC namespace.

It would use the index numbers. DSP chips and trivial C hosts are not going
to strcmp() to match ports up. You can't run a LADSPA2 plugin without some
part of the system being able to parse some data anyway, because you dont
know what the ports are for. It's OK, the host CPU can do it, and pass the
information to the DSP chip.

- Steve
Received on Sun Apr 23 12:15:11 2006