Re: [LAD] Plugin buffer size restrictions

On Wed, 2012-05-30 at 15:03 +1200, Jeff McClintock wrote:
> > From: Fons Adriaensen <fons@email-addr-hidden>
> > Subject: Re: [LAD] Plugin buffer size restrictions
>
> > On Mon, May 28, 2012 at 06:05:20PM +0300, Stefano D'Angelo wrote:
> >
> > > IMO it's easily said: if control rate < audio rate it's plugin's
> > > responsibility, otherwise the host feeds upsampled/filtered control
> > > signals at audio rate to the plugin and all problems evaporate...
> >
> > The don't evaporate, they explode.
> >
> > Take a filter plugin. Calculating the actual filter coefficients from
> > the 'user' parameters (frequency, gain, etc..) can easily be
> > 10..1000 times more complex than actually using those coefficients to
> > process one sample. So you really don't want to do that at the audio
> > sample rate.
>
> True, But with synths at least, recalculating the filter at audio rate is
> routine these days. Admittedly we are pre-calculating the full range of
> coefficients in advance.
> You do get *very* nice filter sweeps and blips at full audio-rate
> modulation.

I'm a modular head, I remain convinced that control ports are nothing
but a pain in the ass and CV for everything would be a wonderful fantasy
land :)

As it happens, I am currently porting the blop plugins to LV2, and
making a new extension in order to drop the many plugin variants (which
are a nightmare from the user POV). This simple extension lets you
switch a port from its default type (e.g. Control) to another type (e.g.
CV). The pattern looks something like this:

/* plugin->frequency_is_cv is 1 if a CV buffer, 0 if a single float */
for (uint32_t i = 0; i < sample_count; ++i) {
    const float freq = frequency[s * plugin->frequency_is_cv];
    if (freq != plugin->last_frequency) {
        recalculate_something(freq);
        plugin->last_frequency = freq;
    }

    /* Do stuff */
}

To get the parameter value, all you pay for the switchability is one
multiplication per sample, which is fine.

Doing those comparisons to see if the value actually changed since the
last sample in order to recalculate is not so great (branching) but it's
not the end of the world either (probably beats recalculating every
sample at least). This is why being told only when the parameter
changes would be better for parameters like this.

The port type switchability means I can move to a fancy new control
ports that work better here without breaking backwards compatibility, so
personally my interest in a solution here is very real. More people
care about normal high level parameters and being able to interpolate
than low-level modular synth CV stuff, but to me it's telling that (it
seems...) one solution can solve both problems nicely.

-dr

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed May 30 08:15:02 2012