On Sat, Apr 22, 2006 at 02:26:57PM +0200, Thorsten Wilms wrote: > I'm not competent to comment on header files or implementation details. > But via Om, I'm a LADSPA power user and would like to bring up > some issues ;)
*gulp* ;) > Distribution / finding plugins: > I would like to have an app, where I can put checkmarks to all plugins > and they will be fetched and installed (buidling from source / binaries > as option). > But just a way to get from the host not finding a plugin to the name > of the collection it's in would be nice already (so an app like Om can > not only say plugin-x not found, but also point to the package). So... that is one thing that using RDF/web tech /can/ give you. eg. the URI for the example plugin is http://plugin.org.uk/swh-plugins/amp/ if you dereference that (ie. click on it ;) you will see some docs, but if you use HTTP content negotiation and ask for it in Trutle you will get the RDF description back, which /could/ have a machine readable bit telling you where to get the package. In combination with bundles that gives you the possibility to install individual plugins. It's a little bit sci-fi, but hopeful you can see that it's not too far off. > Stability: > There are some plugins that will die if fed with values out of their > range (and this happens easily in a modular system). Maybe some mechanism > to protect against this could be build into the framework? It would be 100% opposed to that. Plugins that crash when given odd values are buggy (spec says they mustn't), and should be fixed. Use demolition, report bugs. > Control/audio rate: > Having several variations of the same plugin to allow varying audio/ > control rate port setups makes for unnecessary long plugin lists and > requires the user to delete and insert a different one, should he find > out some port should be audio, not control rate. Just look at the > sine oscillator(s) ... > The rate of a port should be switchable (at leat in all cases where > we have both versions now). I might consider that for the future, but not for 2.0. I think its important to get a more capable platform, before adding features. > Port grouping: > Hosts should be able to see, wether 2 ports are independent, or happen > to be a stereo pair (or any multi-channel setup). > Also a way to specify that things like frequency and amount ports of > an EQ form pairs might be nice. Should be helpful for generative plugin > GUIs. This has been propsed using labels, eg "OSC 1/frequency" and "OSC 1/amplitude", that's an informal part of the spec IIRC. You could encode it in RDF if you wanted to: [ # port defintion ladspa:index 1 ; ladspa:label "frequency" ; ladspa:inGroup <groupO1> ] , [ ladspa:index 1 ; ladspa:label "frequency" ; ladspa:inGroup <groupO1> ] . <groupO1> ladspa:label "OSC 1" . But I dint think it offers much more. > Port Roles: > Ports could have roles assigned to them, like signal_input, sidechain, > latency or bpm (the last for transport awareness and to make it possible > hosts assign values to it automaticaly). Ugh. Maybe sometime in the future. That sounds hard to use. c.f. 2.0 plans. > 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. > Hints: > Maybe I just didn't see it, but shouldn't there be a hint for lists? > Like for plugins that have modes/presets? Yes, there is, but I didnt show it in that example as the simple amp doesnt need it. It looks like: # ... inside port defn ladspa:scalePoint [ ladspa:label "sine" ; ladspa:value 0.0 . ], [ ladspa:label "square" ; ladspa:value 1.0 . ], [ ladspa:label "saw" ; ladspa:value 2.0 . ] > Presets: > Cross-host preset loading/saving. Right, there are some obvious ways to do it. Later. > Help / Discription: > A way to bring up a short discription of a plugin and what the > ports are about. Just dereference the plugin URI as text/html or text/plain. > MIDI/OSC > Don't know if the new LADSPAs should be able to handle MIDI/OSC, > but there should be plugins that do it ;) DSSI. If this gets momentum retorfitting LADSPA 2 to DSSI will be easy. It was designed with that in mind. > GUI lib: > There could be 1 or 2 (GTK, QT) libs for generative plugin GUIs, > for hosts not having to reinvent the wheel and for consistency. Nope. Too hard, use the DSSI protocol. - Steve