Hello,
I just had a look at LADSPA, and it looks very nice.
So far I have just been reading all your mails, but
I'd like to participate in the discussion. I have
been thinking about some related stuff, and in
combination with LADSPA I came to the following
questions.
I am wondering what would be the correct way to use
other data types than audio. For example, how would
LADSPA deal with spectral data? Imagine a FFT plugin.
It's input would be audio and control for binsize,
it's output could be
- 1 output, real + imaginary interleaved
- 2 outputs, 1 for real, 1 for imaginary
I think the second is the best, but it certainly is
not control or audio. Should an extra port types be
added?
What is the way to deal with plugins that need more
input than they might get from the host per run call?
For example the FFT, that needs binsize audio. The only
way I see now, it that it will have to remember the data
on it's input. This might not be very efficient. (The FFT
is a bad example though, it will probably need to copy
the data anyway, but you get the picture). A solution
might be that the host *knows* how much data the plugin
needs, and does the necessary buffering.
A related problem: all connected plugins are run, but what
if some plugin (like the FFT) does not modify it's output
at the every run? The next plugin will run anyway, but
uselessly or repeating with the same data. Maybe the
plugin should set a flag ?
Another situation:
In setup like this:
+------ binsize -------+
| | |
v v v
+-----+ r +----+ r +-----+
| |---->| |---->| | +---+
--+->| FFT | | ?? | |IFFT |---->| |
| | |---->| |---->| | | - |--->
| +-----+ i +----+ i +-----+ +->| |
| | +---+
+----------------------------------+
You want to substract the audio calculated by
the IFFT from the original signal. Two problems:
- the IFFT will generate it's output in binsize
blocks, and not in the framesize. Unless, for example,
the all plugins are indeed called everytime, but
a flag is passed from [FFT] to [??] to [IFFT] to tell
whether new data is available.
- the data that goes through [FFT] [??] [IFFT] will have
a delay in relation to the original signal. Who will take
care of that? The host, but placing an delayline in the
original signal? In that case, it will need to know the
latency of each plugin. Or the plugin? In that case, all
data should be timestamped.
Maybe this goes beyond the scope of LADSPA, and is more
of a OO DSP environment, but I'd say that it would be
great if LADSPA would be able to deal with these things.
And besides, this is just an example, I am sure the same
or similiar situations will arise. Better to have them
covered right away :-)
Please comment on this!
Maarten
