15 Jan
2004
15 Jan
'04
8:35 a.m.
On Wed, Jan 14, 2004 at 06:13:29PM -0500, Dave Robillard wrote:
I introduced main.h in 1.7.x as a point where all that sort of things will
be collected. Turning that into a run-time configuration will be the second
step.
OK, that maps to the requirement that almost everything that has a slider
must also be 'voltage-controlled'.
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/)!
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).
Well, let me make one thing very clear. For me, optimization is *not* a
detail nor something that should be ignored during analysis and taken
care of later. By then it's probably too late. When I design or analyse
anything that's not trivial, efficient implementation is as much a point
to be considered as are functionality and abstraction. I've seen too many
good applications being crippled during their entire lifetime by early
design decisions that ignored this.
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?
The metadata I'll use is transparent for the user, it's related only
to implementation.
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.... 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'll keep that in mind. One remark though: I will be happy to support any
session management system as long as it is general and uses only standard
interfaces. If it requires a particular window manager, desktop or toolset
for example, it will not be supported.
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). 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.
Strange. I'm using AMS in poly mode with a real MIDI controller almost
daily. I'm sure J.S. Bach would complain if some of his notes fall out :-).
Anyway there's no such thing as "dead on simultaneous' as MIDI is a serial
protocol. And even if you play a MIDI file, chords will be serialised at
the ALSA port. Waiting for your example.
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?
Almost all the engine code will be new. Too many things need to change.
--
FA