22 Apr
2006
22 Apr
'06
6:48 p.m.
On Sat, 2006-04-22 at 21:10 +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.
Not having it in the code makes a device like this impossible (think
Nord Modular or Plugzilla). That'd be a shame ;)
-DR-
On Sat, Apr 22, 2006 at 02:47:33PM -0400, Dave
Robillard wrote:
I'm missing the need for heirachicalness. : is probably not safe in OSC
either.
voice_1_osc_1_volume
voice_2_osc_3_volume
Or metaplugins (which ability to load libraries will surely spawn).
subplug_1_param1
subplug_2_param4
... ugh
voice_1.osc_1.volume
... 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)
You could
do pluginUri#portShortName, it's a fairly common convention (eg.
in HTML). But youre only allowed a small set of characters after the #.
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 think the regexp you mentioned there is fine,
though I think we should
add one separator character other than underscore for various reasons.
":" maybe?
I'd rather not, I'm not sure its legal in Pd (they get bitten by the port
name thing too), and its not in C. Pure selfinterest, but My LADSPA code
is about 50% generated from XML, and I use short names internally for C
symbols. 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.