Re: [linux-audio-dev] LADSPA 2

On Sun, 2006-04-23 at 07:53 +0100, Steve Harris wrote:
> 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.

*shrug* All I want is one character that would be useful for organizing
port names in a much nicer looking fashion. I can live without if it's
really a big deal and there's no safe character, it'd just make for much
nicer looking port names on complicated plugins is all. Dropped.

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

It wouldn't use the index numbers if it wants to provide the sensible
OSC namespace (as for strcmp you can do the symbol thing w/ (perfect)
hashing to make it fast). Ditto for a language providing a sensible
API. The label is not metadata, it is a unique identifier.

But anyway, why can't it go in the code? I want to keep the C part
minimal as well, but this is a unique identifier, the sole thing that
actually does belong in the code. I need this to create an app/device
like the above. What's the better reason it's a bad idea? Plugins have
a unique string ID, and I need ports to as well.

If any LADSPA devs are opposed (or not) to giving each port a unique
label in the code, feel free weigh in...

-DR-
Received on Sun Apr 23 20:15:06 2006