Subject: Re: [linux-audio-dev] extending LADSPA
From: Conrad Parker (conradp_AT_cse.unsw.EDU.AU)
Date: Wed Oct 25 2000 - 06:58:42 EEST
On Tue, Oct 24, 2000 at 04:28:29PM -0400, Paul Barton-Davis wrote:
>
> in the case in question, the host is a simple soundfile editor, not a
> DAW, and its not doing (audio) sequencing or any work with EDL's. when
> it applies a fade to a region selected by the user, its simply going
> to take the new data produced by the plugin, and use it more or less
> as-is.
yes, the cases of sequencing and editing the EDL itself are not
being addressed in this thread.
However, that the host may use EDL's internally shouldn't matter to
the plugins. Assuming we're talking about plugins that modify audio data
but not control parameters, my understanding of the way LADSPA works is:
* the host sets up the input and output data blocks anyway
* the plugin operates on these in-memory blocks
if the host stores and accesses its data via an EDL internally, the
plugin shouldn't need to know about this -- the plugin *could* operate
transparently, ie. the host can set up the memory blocks, read data
into the input just like it does for playback, and add the output to
the EDL non-destructively just like it does for recording.
I say "could" because this may lack efficiency, though if the host
only makes input sections that already exist in memory contiguously
this may not be a problem.
> in a DAW situation, it looks pretty different, for sure. but thats not
> the case at hand as i understand it. i'd be sympathetic to the notion
> that *all* audio editors should really be using EDL's and doing
> temporal sequencing with them, but that just isn't how the vast
> majority of Linux sound file editors operate at this time.
yet
I don't think it's a problem with LADSPA -- I think the hosts can
hide the EDLs from the plugins, which again lets such plugins
concentrate on doing what they do best.
Conrad.
This archive was generated by hypermail 2b28 : Wed Oct 25 2000 - 07:27:03 EEST