--- Alfons Adriaensen <[EMAIL PROTECTED]> wrote: > 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 see higher level 'instrument' type stuff as being a wrapper outside the plugin - or more likely, a small graph of plugins - such as a pair of ADSRs, a DCO and a DCA. I've 'manually' got polyphony in SSM with a distributor which routes a signal to successive destinations when triggered, and multiple sets of the same graph (there's also an example patch with SSM that does this). AMS 1.x does this per plugin I think, though I haven't studied the code. > (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. My plans had all ports connected by default (so they take on the value given from the hints) - just attach a dummy buffer to the unconnected ports. > 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. With the exception of samples or other 'blob' data (e.g. IR impulses), I'm fairly confident that a good modular could be constructed with LADSPA as it is. I'm prepared to be proved wrong though! - Myk ________________________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html
