[LAD] AMS to Ingen: VC to PCM

Fons Adriaensen fons at linuxaudio.org
Mon Sep 26 09:08:17 UTC 2011

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...



More information about the Linux-audio-dev mailing list