14 Jan
2004
14 Jan
'04
2:49 p.m.
On Wed, 2004-01-14 at 12:15, Alfons Adriaensen wrote:
On Wed, Jan 14, 2004 at 03:14:59PM +0000, Mike Rawes
wrote:
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 ;).
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.
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?