Subject: Re: [linux-audio-dev] Project: modular synth editor
From: Mike Rawes (mike_rawes_AT_yahoo.co.uk)
Date: Wed Jan 14 2004 - 20:42:58 EET
--- Alfons Adriaensen <fons.adriaensen_AT_alcatel.be> 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
This archive was generated by hypermail 2b28 : Wed Jan 14 2004 - 20:44:08 EET