On Sun, Sep 25, 2011 at 06:20:22PM -0400, David Robillard wrote: > > In particular, synth plugins (VCOs, VCFs, etc.) are fundamentally > > different from general audio processing ones (EQ, dynamics, etc.). > > This doesn't exclude the possibility that some may be useful in > > both contexts. > > Yes, but many, if not most, are usable in both contexts. Filters of any > variety are the best examples.
I'd contest the 'most'. Can you give any more examples ? For filters, only 'static' ones (only GUI controls, same processing on all channels or voices) could be used in both contexts. Once any parameter becomes per voice and 'voltage controlled' the similarity ends. And even the purely static ones you'd want to schedule differently. On a mixer you typically have a lot of channel strips, each of them in most cases a linear chain of processing units. It makes sense to keep the elements of such chains together and schedule them on the same worker thread. In a polyphonic setting voices are independent, typical patches are not linear, and it makes much more sense to schedule per voice. A universal plugin standard should support these different modes, which means separating common and per voice/channel parts. Even if it does I would not expect any particular plugin to support both modes. You can probably get a better plugin by designing it for a specific application. > A tricky one no one has yet tackled (anywhere) AFAIK. Because if you start to analyse these things (and there are many more aspects to it) it becomes clear that current plugin standards completely ignore all of this, they get in the way rather than provide the necessary hooks, and you better start from zero. Just consider the following list: - 'Voltage control' - MIDI control - OSC control - Save/restore settings - Automation Traditionally a host will try to do any of them using only the set of 'control ports' exposed by a plugin, or by hooking into the GUI <-> DSP communication if the plugin has its own GUI. But the requirements for each of these are quite different and usually in conflict. There is much more to it than some metadata. > I think there is more overlap between these cases than this implies, or > at least can be. A polyphonic synth *could* have a very large portion > of the processing time be common shared data. As long as voices are independent there isn't much to share except e.g. big lookup tables as used in some oscillators. Even if the host replicates the plugin for each voice (which it could do) you'd want the instances to share such data. Which again requires some support from the plugin standard. There is another thing missing in current synthesis hosts (AMS, and AFAIK also Ingen): an explicit definition of the point where a polyphonic patch mixes its voices into a single audio signal. Some processing should be done after this point, e.g. reverb and some other effects. So if you do this in a plugin, it becomes 'polyphonic' at one side, and 'multichannel' at the other. Some more metadata required... Ciao, -- FA _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
