On Wed, Jan 14, 2004 at 06:13:29PM -0500, Dave Robillard 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/)!
> 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.... 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. > 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). OK, that maps to the requirement that almost everything that has a slider must also be 'voltage-controlled'. > 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
