Subject: Re: [linux-audio-dev] LADSPA Specs ?
From: Stefan Kost (kost_AT_imn.htwk-leipzig.de)
Date: Mon May 13 2002 - 16:38:05 EEST
Paul Davis wrote:
>>>I certainly agree that envelope control can be implemented by the host
>>>passing dynamically changing parameters to the plugin. I have already
>>>given a lot of thought on that. Consider the situation of a volume
>>>adjustment plugin with host-controlled parameter as the envelope.
>>>Suppose each buffer size is 128 samples, which is reasonably small for
>>>dynamic parameter. When we want to do a fade-out, the host sends the
>>>buffer to the volume adjustment plugin, specifying a decreasing,
>>>negative gain each time. The problem is, for every 128 samples, there is
>>>a leap of the control parameter, resulting in audiable steps of the
>>>volume. Depending on the amount of parameter changes, this can be quite
>>
> [ ...]
>
>>The easiest solution to this kind of problem (parameter change faster than
>>nr. of run() calls) is to make the parameter (here: the envelope) another
>>audio input stream - this way you get 1:1 parameter:sample mapping.
>
>
> We discussed this about 2 months ago (or less). The consensus appeared
> to me to be that its the responsibility of a *plugin* to interpolate
> in the most appropriate fashion whenever the value of a control port
> changes. The host *cannot* know the best way to do this without a
> ridiculous amount of information being supplied by the the plugin, and
> the code is the same in either case. So, the host can choose its own
> level of resolution for automated parameters - for example, it can
> choose to subdivide its own "natural" blocksize into smaller chunks
> for calling process() with - and then the plugin finishes off by some
> parameter-specific interpolation.
>
> Does this need to be discussed again? Does anyone disagree with this
> "annotation" to the API?
>
>
There was one thing, of which we didn't came to a conclusion/solution.
As we have succesufully show with some examples, it is not desired it
the host pre-interpolates the control-data (e.g. for pitch). If the
plugin does it on the other hand, it needs start and end-values.
For subsequent calls the plugin can fad from the last value to the
new value provided. The critical point is the first invocation. The only
solution I can think of is :
in connect_port()
<port>_oldValue=0
<port>_notFirst=FALSE;
in run()
if(<port>_notFirst) {
// interpolate
<port>_oldValue=newValue;
}
else {
// use value statically
<port>_notFirst=TRUE;
}
Ciao
Stefan
--
\|/
<@ @> Stefan Kost private business
+-oOO-(_)-OOo------------------------------------------------------------- - - - - -
| __ Address Zwenkauer Str. 24 HTWK Leipzig, Fb IMN, Postfach 300066
| /// 04277 Leipzig 04277 Leipzig
| __ /// Germany Germany
| \\\/// Phone +49341 3910483 +49341 30766101
| \__/ EMail st_kost_AT_gmx.net kost_AT_imn.htwk-leipzig.de
| WWW http://www.sonicpulse.de http://www.imn.htwk-leipzig.de/~kost/about.html
===-=-=--=---=---------------------------------- - - - - -
This archive was generated by hypermail 2b28 : Mon May 13 2002 - 16:33:45 EEST