9 Jul
2005
9 Jul
'05
10:22 a.m.
Hello all!
I am here to ask you one thing. If I want sample-precise realtime
control for the plugin, should I be getting all the parameters inside
the cycle which travels through the buffer contents?
E.g., should the code that looks like this:
fParameter = *(psMyPlugin->m_pfSomeParameter);
pfInput = psXShaper->m_pfInputBuffer1;
pfOutput = psXShaper->m_pfOutputBuffer1;
for(lSampleIndex = 0; lSampleIndex < SampleCount; lSampleIndex++){
/* do something with the data */
}
be replaced by this:
pfInput = psXShaper->m_pfInputBuffer1;
pfOutput = psXShaper->m_pfOutputBuffer1;
for(lSampleIndex = 0; lSampleIndex < SampleCount; lSampleIndex++){
fParameter = *(psMyPlugin->m_pfSomeParameter);
/* do something with the data */
}
I believe the answer is yes... But maybe I'm wrong?
Thanks!
Artemiy.
9 Jul
9 Jul
10:45 a.m.
On Sat, 2005-07-09 at 15:24 +0300, Artemio wrote:
Hello all!
I am here to ask you one thing. If I want sample-precise realtime
control for the plugin, should I be getting all the parameters inside
the cycle which travels through the buffer contents?
it depends a lot on what are you trying to do. LADSPA control ports
offer only a single scalar value to be used on every run()/run_adding()
call. hosts that support automation will alter this value between calls
to your plugin's run() function, thus providing sample-accurate
automation. however, this is expensive, especially if what you are
actually trying to accomplish is closer to some kind of modulation
effects where one audio signal is used as a control over the operation
of the plugin. in this case, you would not use a LADSPA control port,
but instead would provide another audio input port, and then do
something similar to what you outlined.
note, however, that there is no way at present for hosts to understand
your intent here. this means that free form "modular" hosts like galan
and so forth will work fine, but hosts like ardour that are trying to
fit plugins into a mixer-flow model will not offer the user the control
over what is connected to what.
--p
2:32 p.m.
Am Samstag, 9. Juli 2005 14:45 schrieb Paul Davis:
On Sat, 2005-07-09 at 15:24 +0300, Artemio wrote:
You cannot get control data at special sample positions within the
current processing buffer with LADSPA.
And if you're lucky enough to have a host that breaks down a jack buffer
into smaller buffers, so you get the control data at the correct sample
position, you will have to check all your control ports on whether any of its
contents changed. This is the biggest design flaw of LADSPA.
Paul, remember the small addition to the LADSPA API that i proposed on IRC
yesterday that solves this? ;-)
Ralf
Hello all!
I am here to ask you one thing. If I want sample-precise realtime
control for the plugin, should I be getting all the parameters inside
the cycle which travels through the buffer contents?
10:58 a.m.
New subject: [linux-audio-dev] Re: LADSPA plugin parameters realtime control
On Sat, 9 Jul 2005 15:24:20 +0300, Artemio <artemio(a)kdemail.net> wrote:
Hello all!
I am here to ask you one thing. If I want sample-precise realtime
control for the plugin, should I be getting all the parameters inside
the cycle which travels through the buffer contents?
[...]
Hi,
LADSPA hosts refresh control data on a per buffer basis. Of course you
can read the control data while processing a buffer as many times you
want, but you won't get any different values.
From ladspa.h:
Control data is communicated
using single LADSPA_Data values. Control
data has a single value at the start of a call to the `run()' or
`run_adding()' function, and may be considered to remain this value
for its duration.
However, you may want to do simple interpolation/filtering of the
incoming control stream, so user interaction results in no audible
pops/clicks (due to abrupt changes in incoming control values on buffer
boundaries). It depends on the DSP you perform if this is needed.
Tom
11:04 a.m.
On Sat, Jul 09, 2005 at 03:24:20PM +0300, Artemio wrote:
I am here to ask you one thing. If I want
sample-precise realtime
control for the plugin, should I be getting all the parameters inside
the cycle which travels through the buffer contents?
A control rate parameter does not change during a single call to
your plugin, so it doesn't matter. Reading it again for each sample
is just wasting cpu cycles.
What you can do of course is interpolate it over the length of
the loop. In that case, you use the new value as the one to be
reached at the last sample, and you store this after the loop,
as a starting value for the next call.
Let p represent a paremater value, and N the number of cycles.
p = ... // get parameter value
dp = (p - last_p) / N;
p = last_p;
for (i = 0; i < N; i++)
{
p += dp;
... // use parameter p
}
last_p = p;
Of course, last_p should be part of the instance data.
--
FA
6:28 p.m.
Hello all!
Okay, I now understand the situation but I really think there should
be some development in this area. Interpolation is fine but only for
linear modulation as you guess, and knob/slider tweaks are never
linear, and what about complex-form LFOs?
To Fons:
Thanks a lot, yes, this is what I thought I'd do. I've just spend an
hour tweaking my code, and it works ;-) I already learnt sharing a
value across buffer passes using the LADSPA structure, so that wasn't
hard at all. Thanks for your suggestions!
Thanks again to all for your attention and help!
A.
8:02 p.m.
If you consider the buffer size to be the control rate, then that makes
sense. You don't want to be updating control information as much as
audio information if you want things to run at all quickly. Ie, and lfo
just doesn't need to be audio rate unless it's being used for fm or am
or really high freq stuff, and knob/slider tweaks certainly don't!
Iain
Artemio wrote:
Hello all!
Okay, I now understand the situation but I really think there should
be some development in this area. Interpolation is fine but only for
linear modulation as you guess, and knob/slider tweaks are never
linear, and what about complex-form LFOs?
To Fons:
Thanks a lot, yes, this is what I thought I'd do. I've just spend an
hour tweaking my code, and it works ;-) I already learnt sharing a
value across buffer passes using the LADSPA structure, so that wasn't
hard at all. Thanks for your suggestions!
Thanks again to all for your attention and help!
A.
10 Jul
10 Jul
7:30 a.m.
On Sat, Jul 09, 2005 at 11:30:01PM +0300, Artemio wrote:
Okay, I now understand the situation but I really
think there should
be some development in this area. Interpolation is fine but only for
linear modulation as you guess, and knob/slider tweaks are never
linear, and what about complex-form LFOs?
I don't really think there is a problem here. Even with a period size
of 1024 you have about 40 values per second, and this should be enough
to capture all there is in a knob or slider tweak. And as Paul and
others have already pointed out, a LADSPA host can subdivide the
period at arbitrary points and modify a parameter at exactly the
right time.
If you really want to capture the *exact* waveform of a slider
move, there are other complications. You should then use the
timestamps provided by X on the motion events and reconstruct
the exact movement from the (t, x) values. I've not yet seen
any situation where such a thing is necessary.
If the modulation source is not a widget but an LFO or ENV, then
you can use an audio rate input. This doesn't mean the real
control has to be at audio rate internally. For example, all
my 'synth module' plugins subsample their modulation inputs
at 1/16 of the audio rate, and interpolate linearly. This
still gives a modulation bandwidth of at least 1 kHz. It
all depends on the nature of the plugin if such tricks are
interesting or not.
--
FA
7020
days inactive
7021
days old
linux-audio-dev@lists.linuxaudio.org
7 comments
6 participants
participants (6)
-
Artemio -
fons adriaensen -
Iain Duncan -
Paul Davis -
Ralf Beck -
Tom Szilagyi