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-
