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

[Dave Robillard]

On Wed, 2004-01-14 at 15:35, Fons Adriaensen wrote:
> > 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.

Why does the plugin care?  Granted, some resources could be saved having
a mechanism for the plugins to know they're polyphonic; but I don't
think it's that critical.  That seems like an optimization detail to me;
I can't think of a reason polyphony couldn't be properly handled by the
host (like I said before, AMS /already does this/)!

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

Agreed, would be nice.  But still just an optimization detail.  Unless
everyone is willing to start drafting LADSPA v2, it's not really worth
talking about.  And somehow I doubt LADSPA is gonna be changed anytime
soon (although these problems/improvements would benefit everyone, not
just a modular synth.... think post processing effects, lots of multiple
plugins running there).

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

Agreed, this would be a nice thing to have.  Not critical (like the
above), but nice.

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

I don't think this is necessary, and just adds uneeded complexity
(especially to plugins, which is a Bad Thing(TM)).  I'm not familiar
with the internals of ams all that well yet, but is this really the only
way to accomplish these things?  If a plugin is polyphonic, there's one
for each voice.  It can just go along munging it's audio all day, it
just has one input.  I don't see why the plugin has to care in the
slighest what the engine is doing around in as far as polyphony goes.
(Excepting the above optimizations of course)

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

I know.  I have. :D  One of these days I might make it use configurable
and send in a patch, but since AMS doesn't even have a config file that
I know of....

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

Ditto.

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

Once you start doing anything remotely complicated, LADCCA just becomes
necessary.  With this track I've been fiddling with lately it literally
takes 5-10 minutes just to get the environment properly set up. 
Obviously this is a pretty big problem.  It's getting better though.

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

I mean ports on the plugins.. take the LFO plugin for a simple example..
right now, the frequency is a control in the GUI (right click, open the
GUI, and you'll get a slider).  It would be nice to have the option of
making it a port, so some other part of the synth could plug into it and
control the frequency of the LFO.  So you could, say, make higher notes
have a faster vibrato or whatever.  (Okay, not the best example, but you
get what I mean).

I don't remember what I was trying to do that made this really annoying,
but trust me, it'd be nice. :)

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

No, it was connected.  The synth works fine in all aspect, except when
notes are _dead on_ simultaneous.  I assumed this was because the
developers don't have a real MIDI controller and never ran into this
problem. (vkeybd probably has sufficient delay between "simultaneous"
notes to avoid the problem)

I'll put something together with a .mid file to show it.

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

Well.... it appears to me like the "new ams" isn't going to materialize
any time soon; my point was: if these improvements are made to the
current AMS, will they all be thrown away for a totally new codebase, or
is alot of the code going to remain?

For me, priority speaking, the LADSPA control port problem, and
simultaneous MIDI notes (which I assume is trivial) are the most
aggravating problems.