23 Apr
2006
23 Apr
'06
1:17 p.m.
On Sun, 2006-04-23 at 07:53 +0100, Steve Harris wrote:
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-
On Sat, Apr 22, 2006 at 04:48:28 -0400, Dave Robillard
wrote:
voice_1_osc_1_volume
voice_2_osc_3_volume
That looks fine to me...
*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.
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. 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.