Subject: Re: [linux-audio-dev] Project: modular synth editor
From: Dave Robillard (drobilla_AT_connect.carleton.ca)
Date: Thu Jan 15 2004 - 01:13:29 EET
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.
This archive was generated by hypermail 2b28 : Thu Jan 15 2004 - 01:15:54 EET