On Sat, 2006-04-22 at 21:10 +0100, Steve Harris wrote: > On Sat, Apr 22, 2006 at 02:47:33PM -0400, Dave Robillard wrote: > > > 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 #. > > > > > > > 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. > > > > 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 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) > > 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. Not having it in the code makes a device like this impossible (think Nord Modular or Plugzilla). That'd be a shame ;) -DR-
