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

Dave Robillard drobilla at connect.carleton.ca
Wed Jan 14 13:46:52 EST 2004

On Wed, 2004-01-14 at 12:15, Alfons Adriaensen 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 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.

Quick digression about LADSPA in ams:  is there a reason exported
control ports on LADSPA plugins don't work (at least for me anyway)?  I
realize control ports run at a different rate than the audio, but since
the ports are exported I figured this would be taken care of.

I should probably take this to the ams list, but here's a test case:

MCV Frequency -> Converter (V/Oct to Hz) -> LADSPA Analog Oscillator
Frequency -> Output

(Analog oscillator is I believe from plugin.org.uk, you almost certainly
have it.)  Anyway..

Wouldn't number of voices and finding out if a port is connected be
internal to the app?  These things can (actually have to) be stored.  As
far as storing, this kind of information would go in the patch file
(.ams), not the plugin.  Am I missing something here?  Besides, since
you've got LADSPA plugins working... well, it must be possible ;).

> 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.

After posting my intial message I thought a bit more about AMS.. it's
true, it's so close to what I need modifying it is probably wisest..
despite that most wretched of widget sets QT and that brown color I
can't erase from my mind (I kid! :) ).

Seriously though, since you're obviously familiar with the code, what
would be the relative difficulty of:

- Runtime-configurable polyphony
- LADCCA support
- Fixing above problem with LADSPA control ports, assuming it's not just
my wacky installation
- Configurable whether ports are in the GUI or exported as ports (I
think this one is really important and would increase flexibility a
Whole Lot(TM))  (see my previous message)
- There's a problem with simultaneous MIDI input (ie playing chords)..
some of the notes get left out.  Fixing this

But more importantly, if these things get done will they carry on
through the new ams, or is all the work in vain?

More information about the linux-audio-dev mailing list