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

[Fons Adriaensen]

On Wed, Jan 14, 2004 at 01:46:52PM -0500, Dave Robillard 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.

This is one of the areas I never explored (having only recently joined AMS
as a developer). Probably Matthias will be reading this and comment on it.
What I can confirm is that there presently is no 'control' data type in AMS,
all connections use the audio rate buffers. 

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

You can of coourse use plugings in a polyphonic mode, and AMS even implements
a special protocol that enables LADSPA plugins to discover that they are used in
this way (I have some unpublished plugins that actually use this). But this is
not part of the current LADSPA standard. I proposed it some time ago, but when
I mentioned that one use of this would be to let a poly plugin create only one
GUI for all voices, the thread quickly changed into a discussion on plugins GUIs
and how to make them, and the original proposal was lost in the hassle. 

There are other reasons why you may want to know that a number of plugin 
instances belong in fact to one polyphonic module. There may be for example
lookup tables or control voltage calculations that can be shared between all
voices.

Knowing that ports are unconnected can be important if this changes the way
the plugin operates, or just to avoid useless calculations on endless arrays
of zeros,

Some of the functionality I want for the new AMS also requires 'metadata' along
with the audio signals, e.g. to indicate which voices in a poly patch are active
or have terminated. In the current AMS for example, there is a 'hidden' data path
from the envelope generators back to the voice controller, to signal that a
voice has terminated and can be reallocated. This is why you can't have an
envelope generator in a plugin, as this data path is hard-wired into the engine.

> > 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! :) ).

You can change that color, see main.h. As to the widgets, that will comletely
change in the second generation. In fact the GUI will be separate application
that can be replaced without touching the audio code.

> Seriously though, since you're obviously familiar with the code, what
> would be the relative difficulty of:
> 
> - Runtime-configurable polyphony

Maybe this could be done, but no promises. It's one the 'features' that I myself
(as a user) would like to have ASAP. 

> - LADCCA support

I never looked into LADCCA. This may change after the next LAD conference
(there's a talk on LADCCA scheduled).

> - Fixing above problem with LADSPA control ports, assuming it's not just
> my wacky installation

Matthias !?

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

What sort of 'ports' would that be (except for MIDI, but this is already
possible) ? But maybe I don't understand exactly what you mean.

> - There's a problem with simultaneous MIDI input (ie playing chords)..
> some of the notes get left out.  Fixing this

There could be a problem if you do not connect the 'gate' ouput of the
MCV. If you have an example that shows the problem (with 'gate' connected),
I'd appreciate if you could send me the .ams file.

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

Certainly not in vain, as you request nothing that is not already in the
basic requirements for the new AMS (except LADCCA).But it means twice the
work... :-)

-- 
Fons