[linux-audio-dev] Project: modular synth editor

Alfons Adriaensen fons.adriaensen at alcatel.be
Wed Jan 14 17:15:24 UTC 2004


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







More information about the Linux-audio-dev mailing list