14 Jan
2004
14 Jan
'04
7:16 p.m.
On Wed, 2004-01-14 at 15:35, Fons Adriaensen wrote:
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/)!
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....
Ditto.
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.
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. :)
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.
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.
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.
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! :) ). 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... :-)