14 Jan
2004
14 Jan
'04
12:18 p.m.
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