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? 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. 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 - 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) - the way to communicate current bpm from host to the plugin (bpm-synced delays, flangers etc were a standard in 2000 or so :) ) - 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 - 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 ;) - 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) - 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 - 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 - optimization of parameter handling by telling the plugin which parameters have changed (using a bitmask) - which is a must for a 200-parameter synthesizer :) - 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 - 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) - dynamic parameters (Nedko is already working on these) - 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 hope everything is clear, as it refers to things existing in digital audio world for ages. And those are extensions I dream of :), not something that should go into core specs (maybe bpm could be retrofitted into the core, but that's a political decision with potentially negative results at this stage). And as for coding for fun - unfortunately doing really good things (comparable to, say, Native Instruments software) involves not just fun stuff, but also some tedious crap - so some external motivation seems to be beneficial. Krzysztof _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
