[linux-audio-dev] LADSPA 2

[Dave Robillard]

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-