On Wed, Jan 14, 2004 at 03:14:59PM +0000, Mike Rawes wrote: > The key here would be to develop an API (I suppose more accurately an ACI - > application Control interface) to cover all intended functionality, which would > include: > > * Querying installed LADSPA plugins > Including RDF categorisation > http://plugin.org.uk/lrdf > * Instantiating (adding) plugins and removing them > * Connecting / disconnecting ports > including 'translation' between different port types, e.g. > Control rate <->Audio rate > Range hint scaling (e.g. mapping a +/- 1.0 audio > signal to a logarithmic 5 octave frequency > range) - AlsaModularSynth has a wise approach > of standardising the scales - 1 'Volt' per > octave for frequency etc. much like the old > hardware modulars. > * Managing inputs/outputs > JACK for audio (be it actual audio, or control > values at audio rate) > OSC 'ports' for control-rate connections > MIDI connections > OSS / ALSA audio I/O ? > LADCCA, iirc, is designed for controlling > LADSPA plugins remotely - worth checking out anyway > http://pkl.net/~node/ladcca.html > * Creation and management of subpatches > A nice feature would be any subpatches automatically > become available as plugins as they are created, > presented alongside vanilla LADSPA ones. > Maybe have a 'publish subpatch' function that lets > you slot in a subpatch into the RDF heirarchy as well. > * Setting up polyphony > Either for the whole graph or just portions of > it - think multiple synths and an effects unit > in a single graph. > * Querying state (e.g. for presentation in a GUI) > Pretty much everything: > Connection state > Names of plugins / ports / subpatches > Inputs and Outputs > Subpatches
This corresponds quite closely to the long term aims for a second generation AMS (see my message of a few weeks ago). As for using LADSPA as the native module format, my first idea when I started analysing the requirements for a new AMS was exactly that. But there's a lot of functionality that's hard to implement using the defined LADSPA interfaces. Some of this could could maybe be added in a backwards compatible way, but the end result wouldn't be very clean, so I've now all but abandoned this idea. The problem is not with the lack of a GUI - that would be separate process anyway, but quite basic things such a checking the number of voices (I proposed a backwards compatible solution some time ago, but that thread went of into another direction :-), or just finding out if a port is connected or not. So any new design will either have only 'static' built-in modules, or define its own plugin format. I'll probably go for the second option, and will take the resulting flames with it. LAPSPA support will remain, of course. -- FA
