Subject: Re: [linux-audio-dev] LADSPA and plugin sample rate
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Mon Dec 11 2000 - 17:17:03 EET
>When finding bounds, application of LADSPA_HINT_SAMPLE_RATE is the job of
>the host. This cannot be done by the plugin as there may not be a plugin
>instantiated. (To instantiate a plugin the host needs a sample rate - I
>cannot imagine it is that difficult to hang on to this information!) Yep,
>this is fiddly when defining a network of plugins in the abstract, away
>from real signals, because there is no known sample rate. But in this case
>the plugin is no more able to provide a sample rate than the host.
>
>LADSPA_HINT_SAMPLE_RATE should only apply to the bound-setting stage (Hmm I
>wonder if this is explicit). Control values at run-time should use their
>obvious values. The example low-pass filter in the LADSPA SDK defines
>LADSPA_HINT_SAMPLE_RATE to declare a cutoff range from 0Hz to the Nyquist
>frequency (0.5 * sample rate). In actual use, a value of 440 is fed to the
>cutoff frequency control port to generate a 440Hz cutoff.
>
>I still have a suspicion I'm still missing the point here. Sorry if I'm
>being foolish :o)
No, you're not missing the point. I'm being mislead by Steve's use of
a non-portable trick in his plugins. He uses the "special" functions
_init() and _fini() to setup the bounds for his plugins. These are
recognized by the run-time linker, and as a result, his bounds are not
const. However, they are also not established at a point where SR is
known.
OK, so back to square one. Can we go back to square one, whereby we
make the SR value a member of the plugin struct, so that the host can
access it at all the right times (e.g. when building setting bounds
for a GUI, or similar) ?
--p
This archive was generated by hypermail 2b28 : Mon Dec 11 2000 - 18:00:51 EET