Subject: RE: [linux-audio-dev] finding the selection length with LADSPA
From: Richard W.E. Furse (richard_AT_muse.demon.co.uk)
Date: Thu Oct 19 2000 - 21:59:41 EEST
Ooo a fun subject. A tightly related issue is whether or not the plugin is
allowed to exhibit non-causal behaviour. Should a plugin be able to see
into the future? And see which bits of information? As LADSPA plugins are
supposed to be able to run against live streams, the answer is no. OK, some
plugins could support extra functionality that cuts in only when running
offline, but...
Just as fuel for thought, consider how best to encapsulate a 'reverse'
plugin. The plugin needs its last input sample before it can produce any
output. It needs to know how long it is to run and all data that will ever
be fed to it. An API supporting this isn't hard to build, and a natural one
gives the plugin something that looks like a random-access file system. But
it cannot be run 'live' in any meaningful sense and is a fundamentally
different signal-processing paradigm to the somewhat narrower one LADSPA
addresses.
I like the sound of Conrad's future graphical implementation of control
manipulation - I'll be playing with this when it comes out!
In response to David's related mail, running plugins in short sections and
then changing parameters is explicitly supported by the API - properly
written plugins (and anything in CMT) will run quite happily. As you point
out, poorly written plugins should be fixed.
On the efficiency side, this memory reference approach is the most
efficient system I'm aware of under most (all?) circumstances where an
unpredictable agent is feeding scalar control information to the plugin
(okay, things are less simple for complex event data). If the plugin has a
high control-rate overhead because of filter coefficient recalculation or
suchlike it can simply cache its last calculations - the implicit overhead
is then just an if call. [In this context the issue of whether or not the
plugin is entitled to call itself 'hard' realtime is more subtle...]
--Richard
-----Original Message-----
From: Conrad Parker [SMTP:conradp_AT_cse.unsw.EDU.AU]
Sent: Thursday, October 19, 2000 7:05 AM
To: douglas irving repetto
Cc: linux-audio-dev_AT_ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] finding the selection length with LADSPA
On Wed, Oct 18, 2000 at 06:25:28PM -0400, douglas irving repetto wrote:
>
> it seems to me that an awful lot of filter-type operations are most
> conveniently handled by a simple "select the region and run the filter"
> model. and for any process that requires parameters to move from one
> value to another over the run of the process, the plugin needs to know
> the total number of samples that have been selected. having a user type
> in a time parameter could be both awkward and potentially inaccurate.
as most people have pointed out, LADSPA is only designed for dealing
with audio streams, not segments of a given length. Trying to twist
the plugins to do anything else is only going to get messy, both for
you writing the plugin and for the apps needing to coordinate more
information with the plugin.
I'm planning to handle this kind of thing (fades, envelopes) in sweep
as follows: rather than setting individual numeric parameters, the
user could provide (draw...) an envelope describing how that parameter
should vary over the selection. Sweep would then run the LADSPA plugin
in short sections, each time with slightly different parameter values as
given by the contour. This shouldn't be too much trouble from the
point of view of sweep's LADSPA plugin handler, because it runs
those plugins in many short sections already anyway.
In terms of quality, this shouldn't be any worse than the results
given in a realtime streaming environment (eg. in gdam or quasimodo),
where the user manipulates a dial to change LADSPA parameter values
over time.
[...]
This archive was generated by hypermail 2b28 : Thu Oct 19 2000 - 22:46:27 EEST