On Tue, 2007-11-13 at 13:08 +0000, Krzysztof Foltman wrote: > Lars Luthman wrote: > > > That may be a good idea for the future, but for now it's more important > > that the core spec is released. After that anyone can define extension > > sets or compatibility levels. The core spec has taken too long already, > > if it has to wait for more extensions and other additonal structure it > > will never ever be finished. > > It doesn't have to wait for compatibility levels. It's something you may > keep in mind for the future, but doing compatibility levels exactly at > this moment is pointless, because the extension APIs aren't stable yet. > It's a sort of potential long-term goal. > > What is the current intended set of "hard" requirements for the core > spec? What are the roadblocks?
Not sure if there are any. I think it's mostly about getting everything together and writing some docs. > I've read the specification, and it looks very reasonable, some things > may be missing (I would suggest "logarithmic", "enum" and "userRendered" > PortProperties), but it's a definite improvement from LADSPA. I don't > know how you're dealing with backwards compatibility between different > versions of the same plugin - is there any mechanism in place. Not really. If a new version of a plugin is completely compatible with the old one (e.g. just bugfixes or a nicer GUI) it should have the same URI, and the hosts will treat it as an identical plugin. If not, it should have a different URI and the hosts will treat it as a completely different plugin. There is no way to specify that a plugin is backwards compatible with another one and maybe can use presets for it or be used as a drop-in replacement with suitable port mappings. Maybe an extension could be defined for that if a pressing need arises. > However, in order for it to be successful, a good set of extensions > should follow, some ideas (not mine, and I have probably mentioned them > before): > > - a stable GTK+ GUI API is a must! (we could dream of the ability to use > it in outside process for non-GTK+ hosts, but simple goals are better > for start); least of all, the ability for the host to use GLADE XML > provided by a plugin + call some callbacks on value changes There is a GTK+ GUI extension, although not stable. The GUIs are loaded from shared modules listed in the RDF files, just as plugins, so it can be up to the host whether they are loaded in the same process as the plugins or in another IPC/RPC-controlled one. There is no generic loader for them though, that might be useful. > - so is the ability to deliver MIDI or MIDI-like events with sample > accuracy. But that may be added later (I'm looking at your MIDI Port > extension, it looks perfect except for double values for timestamp - I > think int32 and sample accuracy would be simpler/faster and equally useful) Well, IEEE754 doubles have 52 fraction bits so they can be at least as sample accurate as 32 bit integers. I agree that most hosts and plugins will not use sub-sample precision, but one cast per event isn't that expensive. > - the way to communicate current bpm from host to the plugin (bpm-synced > delays, flangers etc were a standard in 2000 or so :) ) Agreed. This would be a trivial extension, you could just define a port hint that said that a certain control input port should be fed the current BPM value. A complete transport sync mechanism would be more complex but also more useful - think loopers, record/playback plugins, automatic arpeggiators. > - the ability to flag parameters as non-automatable (because they > involve heavy calculations or audio clicks on each change) - I think VST > has this feature, and it had its practical uses There are a couple of different extensions in development for sending non-RT-safe commands to plugins. Don't know if there's anything stable yet. > - plugin icon (BEAST/BSE has that, so does Buzz), for modular synths, > effect icons in mixers and the like... it could bring some life to > boring GTK+ interfaces ;) There's nothing published anywhere, but I've been bundling SVG 1.0 icons with some plugins and pointing to them with a triple in the RDF data files. The SVN version of Ingen shows them in the plugin menu and on the canvas modules. > - the ability to paint on plugin icon in realtime (so that we may make > oscilloscope plugins or display current frequency response plots in > filter plugins) Wouldn't full-blown GUIs be more suitable for this? I've been using them for things like meters and fancy controls: http://ll-plugins.sourceforge.net/ogg/bling.ogg (the blue thing is a GUI for an LV2 port of Gordon Pearce's Nekobee) > - the ability for the plugin to provide its own text or graphical > representation for parameter values (so that it can use weird parameter > scaling and not depend on host) - both VST and Buzz use that; the > possible extension is to allow custom string-to-value conversion so that > values can be entered by hand There is a Units extension that can be used to define units for ports (linked from the spec page, I think) and the core spec has scalePoints, which allows plugins to define labeled port values (e.g. "0 dB" for the multiplier value 1.0 on a simple gain plugin). > - the ability to have GUI .so for a plugin separate from audio .so (but > with its name exposed by audio .so), so that a plugin can work with or > without GTK+ available See above. > - optimization of parameter handling by telling the plugin which > parameters have changed (using a bitmask) - which is a must for a > 200-parameter synthesizer :) I don't think there's anything for this yet, but it shouldn't be hard to do in an extension - there are well-defined mechanisms for adding host and plugin callbacks using "Features". Or maybe it could be done as an input port class. It isn't strictly necessary though, e.g. WhySynth works OK as a DSSI without it and it has lots and lots of control ports. But yeah, it might be nice. > - the ability for the plugin to store "memory dumps" inside songs > (basically, the loaded sf2's for fluidsynth) - so that songs contain all > the data they should - VST and Buzz have that, LADSPA doesn't Yes, session management will be crucial, especially when we allow arbitrary extensions that may change the plugin state in all sorts of weird ways. I don't think there's anything that does this in a generic way at the moment. LADSPA doesn't really need it since its only I/O method is the ports. Sure, a plugin can theoretically change it's internal state during a session to something that is completely different from what you get if you re-initialise it with the same control input values, but I don't think there are (m)any LADSPA plugins like that at the moment. > - ability for the plugin to expose things like note names, control > changes (your MIDI map extension is a good "version 1.0", but it might > be later expanded with ability to define CC dynamically and with the > ability to provide names/drum counterparts for the individual notes, for > drum synths and the like) I want dynamic note names too, so if no one else does that extension I might (at some unspecified time in the far future). Not sure if the plugin needs to be aware of dynamic CC mappings though, that can be handled completely by the host - the plugin just needs to provide defaults. > - dynamic parameters (Nedko is already working on these) Haven't looked much at this yet. > - dynamic ports, so that a mixer plugin can have new inputs/auxes added > on the fly (very low priority in my opinion, and nobody seems to be > working on it) I agree that there probably isn't a pressing need for it, but it would be nice to have. It could also be used for dynamic polyphony in synth plugins, with host access to the individual voices. --ll
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
