(a), (b) and (c) are all trivial within the new extension set (including
speed >1.0 ;-). That this isn't self-apparent is the fault of the
documentation (implicitly, myself). Perhaps I should make an (albeit
inebriated) attempt at explaining what's going on with the API extensions:
As you imply in (1), plugins as we know them expect a sequential input
stream. The problem with a reverse plugin is that it needs blocks of audio
IN A DIFFERENT ORDER. This is what the non-sequential API is all about - it
provides a way for the plugin to select audio rather than accept it in the
obvious order. Yes, this is impossible in real-time, but it is trivial
using pre-recorded sound (e.g. while editing Ardour tracks, even via EDL).
All the API extensions do is allow a plugin to select which bits of input
audio it wants to work with as each output block is requested (i.e. allow
the plugin to call seek() during a run call).
Pseudo code for a few plugins:
I Fade-in: first call, size 1000: how long is the input area?
{length=23456} Don't both requesting special input audio behaviour, just
use an ordinary audio input. Produce the output block from the input block
while scaling 0 to 999/23456. Second call, size 1234: scale from 1000/23456
to 2233/23456.
II Reverse: first call, size 1000: how long is the input area?
{length=23456} Okay, to produce output values 0...999 we cannot use the
corresponding sequential input audio which would start from 0. Instead the
plugin requests (seek()s) input from 22456 in the input data, reverses the
data and outputs. Second call, size 1234: same idea with some extra
counters, request audio from 21222 to 22455. Incidentally, this plugin is
an example in the experimental SDK.
III Varispeed: some call, block size 1000, pitch 1.5 (relative frequency,
i.e. a just-intoned fifth up): ask for the chunk of input audio from where
we were last time of size 1500 (poss. 1501 if petty). Interpolate or sample
happily to produce an output block of 1000 samples. Yes, this does mean it
becomes trivial to build real-time synths with multi-sample capabilities
with LADSPA. If anyone has the GTK experience and time to help me with PNet
please shout...
IV Granular stuff: here the plugin can simply request access to any input
audio it likes and spatter it into the output buffer to hand. As the long
as the input audio is in RAM this should run fine in real time.
[All these algorithms skip the potential additional complexity that arises
when the block size provided by the seek() call is smaller than requested.
IMHO this is plugin implementation detail that should be very familiar to
anyone who has worked with sockets - and there are very good reasons for
the constraint.]
Incidentally, although I disagree with the first sentence of (a), this is
only for reasons of pedantry and I agree with the rest of the paragraph and
the overall sentiment. Applying the reverse plugin to a range of EDL'd data
implies the host providing a chunk of audio to the plugin (albeit not
sequentially) and receiving an audio stream out. The new concepts the host
has to accept are (a) output may not be same length as input and (b) Ardour
has to allow the plugin to request access to particular bits of the input
stream rather than feeding the audio in sequence.
I'm not sure how helpful these comments are, but that's all for this
evening because I must sleep...
--Richard
-----Original Message-----
From: Paul Barton-Davis [SMTP:[EMAIL PROTECTED]]
Sent: Tuesday, December 19, 2000 9:34 PM
To: 'Linux Audio Developer Mailing List (E-mail)'; 'Steve Harris'
Subject: Re: [linux-audio-dev] RE: Non-Sequential LADSPA Extension:
experimental SDK
[...]
a) fade cannot be done with a plugin. its part of the overall
automation system for gain control, which is too complex
to use the port system of LADSPA. i think. prove me wrong, please.
b) reverse cannot be done with a plugin. 2 reasons:
1) before the plugin is executed, there is no sequential stream
of data.
2) when the plugin is executed, there is no concept of "regions"
Since its intended that you will be able to reverse just a section
of data, this has to be done within ardour's own EDL system. the
alternative implies having a "run_plugins()" system that knows
about the "regions", and feeds them one-by-one into the plugin chain.
I don't like this design at all. At this point in the handling of
audio data, we're back to an unbroken stream of ARDOUR::Sample,
and I really don't want to change that.
c) varispeed might be done with a plugin. it would be very useful,
but i haven't fully thought through the implications of the speed
going above 1.0 ....
--p
