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.
