--- Alfons Adriaensen <fons.adriaensen(a)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