22 Apr
2006
22 Apr
'06
3:47 p.m.
On Sat, 2006-04-22 at 18:25 +0100, Steve Harris wrote:
On Sat, Apr 22, 2006 at 01:06:26PM -0400, Dave
Robillard wrote:
It's not useful from the perspective of writing a LADSPA host in C, but
I think the above two (actual real world) examples of where port ID's
are user exposed are justification enough.
On Sat, 2006-04-22 at 17:30 +0100, Steve Harris
wrote:
OK, that's an argument I could buy. i'm still not completly convinced, but
it does make some sense. On Sat, Apr 22, 2006 at 02:26:57PM +0200,
Thorsten Wilms wrote:
I'm not going to suggest ID numbers go away, but I do think ports should
have a uniquely identifying string label. Primary reason being OSC
control, and using plugins in language bindings (ie python) - both
things that are getting much more prevalent now than when LADSPA first
arrived. Referencing:
There needs to be a safe way to reference plugins and their ports.
Portnames make for human readable patch files, but this doesn't
work with i18n, when Attack becomes Einschwingzeit ;)
Plugins have URIs! And ports have uniqe identifying numbers within the
plugin. We could assign URIs to ports too, but I think thats going too
far. I guess you mean unique in plugin scope? It would also
have to have some
restriction on what values it could take, eg. [a-zA-Z][a-zA-Z0-9_]+ some
kind of lowest common denominator between symbols for various languages
would make sense.
Yeah, just unique to the plugin. (Though I guess that would imply the
port could have a URI like pluginuri/porturi but whatever).
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?
As a side effect of this, what is now "label" should become
"description" and implicitly be Nice Human Readable Text, not
ugly_c_looking_identifiers (and units definitely need to be seperated).
"Description" is metadata though, so I guess it doesn't belong in the C
file.
-DR-