Subject: Re: [linux-audio-dev] extending LADSPA
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Wed Oct 25 2000 - 16:46:10 EEST
>just knowing the total number of frames is not enough -- for these
>types of plugins (think of "reverse") you need to know the last data
>values before you can start outputting the first, so breaking up a
>big chunk of processing into smaller blocks isn't going to work. You
>can't feed reverse only the first 200 frames of a 1000 frame chunk and
>expect it to give you the last 200 frames (which it hasn't seen
>yet), reversed, after calling run().
an excellent observation. this leads me to think that we have 2
choices: we can identify a number of operations where plugins are just
not appropriate, or we can modify the way plugins are executed to
allow them to be used even for these operations.
on the list would be:
* cut
* insert
* replace
* reverse
* fade
these are all basic editing operations, and its hard for me to see the
justification for using a plugin for any of them. the semantics of
each operation is well defined (compare and contrast with, say,
"reverb"), and an editor can do it without resorting to an auxiliary
piece of code.
to deal with the "reverse" case above with plugins, we would clearly
(it seems to me) have to allow a plugin to be handed the entire chunk
of data to be reversed at once, and have it know that that was the
entire chunk (implicitly, i suppose). the same would be true for fade
operations as well. this is completely consonant, as tom has pointed
out, with an edl editing model as well as simpler ones - the host
("editor") simply gets the "selection" ready in a memory buffer, and
calls the plugin on it. it collects the results, and does whatever it
needs to with them.
a consequence of this is that certain kinds of plugins (reverse, time
compression, etc.) cannot be run in real-time streaming mode. so maybe
all we really need is a new flag LADSPA flag that indicates this. it
would indicate that the plugin will accept data for processing, but
will assume that each execution of run() is "self contained" and the
data presented is "all there is".
comments ?
--p
This archive was generated by hypermail 2b28 : Wed Oct 25 2000 - 17:22:24 EEST