Subject: Re: [linux-audio-dev] changing control port values with LADSPA: a serious issue?
From: Tim Goetze (tim_AT_quitte.de)
Date: Thu Mar 21 2002 - 23:20:52 EET
Steve Harris wrote:
>On Sat, Mar 16, 2002 at 04:54:03 -0500, Paul Davis wrote:
>> >my proposal for a remedy is rather simple: let control port value
>> >pointers not point to one LADSPA_Data but to an array of two.
>> >
>> >the first represents the start, and the second the end value for the
>> >next run*() call.
[...]
>Erm, not too fast, that doesn't help.
>
>I've always regarded the value as the value at the end of the buffer, and
>all this does is make it easier to lerp the control values, which will
>encourage people, so you will get zipper noise: one reason early vst
>plugins sucked so much.
wait -- if hosts are doing the right thing, they'll shift the two
values so that at t(n+1) the first of the two values will be the
second from t(n). so i can't see why zipper noise should increase.
unfortunately i neither understand precisely what action 'lerping'
describes (i think it must be tossing around the controls madly), nor
do i recall the first vst API's handling of control ports, possibly
because i never did vst.
>The only helpful thing you can do with this is to use the first value as
>the value in the middle of the buffer (doubling the virtual crate) and
>that is just perverse.
basically i understand the values passed to and from the plugin as
sample points of a curve (and probably we all do since we agree there
need be some kind of interpolation?)
so for now we sample this curve at a rate of audio_sample_rate /
frames_per_cycle. we silently accept that the rate ranges from
like less than 1 up to 1000 Hz and more as audio_sample_rate and
frames_per_cycle vary from disk-to-disk processing with huge audio
chunks to duplex mic-to-speaker at tiny chunks. and, for now, in the
API (as well as it is designed otherwise) this is a non-issue.
i see the good thing about my proposal not in that it is the ideal
solution, but in that it introduces the issue to coders right in
<ladspa.h>, and in that it makes basic interpolation methods possible
while requiring the hosts to do the bookkeeping and thus minimizing
impact on the plugin code.
let's see what the control value curves may look like.
a) they can be lines parallel to the time axis -- fine, we're
done already.
b) they can be derived from an audio signal so they'll come at the
audio sample rate -- we probably all agree we're not going to go
there for a few years.
c) they are the value of a mathematical function [algorithm] of
any sort -- then we at least can sample it at any interval.
d) they are the value of an algorithm that is known to the plugin and
the host alike {i'm thinking of splines drawn by the user here,
mostly} -- we can pass the parameters to that function {and must
accept that the number of parameters to the function may not be fixed
between calls}.
e) they are described in a series of events generated through some
means, MIDI or such -- likewise, the number of value points is not
fixed, and the value samples are asynchronous by nature.
f) ?
the best compromise to still deserve being called 'simple' i think
is the host (or the user executing his right to make a choice)
deciding on a sample rate for the control data flow, communicating it
to the plugins and arranging arrays to hold the data at the control
ports. i reckon the chances are good that with this model we can
confine ourselves to linear interpolation within the plugins --
especially if the user gets to make this as a quality vs resources
decision.
the next best i think is to have a fixed array size (2, or possibly
more values) and keep the impact on the API smallest.
as tempting as it is to establish some means of event system that could
encapsulate the control data and possibly more information, the impact
it would have on plugins and hosts is huge, and i feel a 'simple'
solution is within reach.
thanks for listening,
tim
This archive was generated by hypermail 2b28 : Thu Mar 21 2002 - 23:13:43 EET