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

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Project: modular synth editor
From: Alfons Adriaensen (fons.adriaensen_AT_alcatel.be)
Date: Wed Jan 14 2004 - 19:15:24 EET


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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Jan 14 2004 - 19:18:03 EET