Subject: Re: [linux-audio-dev] finding the selection length with LADSPA
From: David Olofson (david_AT_gardena.net)
Date: Thu Oct 19 2000 - 09:03:43 EEST
On Wed, 18 Oct 2000, douglas irving repetto wrote:
[...]
> yes, it seems like it's a problem if it's impossible to implement a fade
> in/out filter that operates on a user selection.
Hmmm... Running "user selection" through my logic abstraction
generator gives "clip".
A Clip (in some cases possibly called a region) is about as close to
a selection you get in a real time streaming system. It's at element
of an EDL type structure that describes how to construct the output
in real time during playback, or when mixing down. (I believe my
"clip" is what Paul calls piece_t in his EDL system.)
Now, rather than resorting to definitey separating off-line
processing from real time processing (which would take away some
flexibility), how about defining some sensible way for hosts to pass
EDL information to plugins? That would minimize the difference
between off-line and real time processing, and could be used for
describing "clips" as well as selections. It could be implemented
as some sort of generic protocol for communicating timing; preferably
in the form of <time, duration[, parameter]> elements.
Did anyone think "events"?
> requiring a user to
> type in a number of samples to fade over is kind of old skool, and is
> redundant if the user has already selected a region.
Indeed! A region *is* a form of parameter; all we need is a sensible
way to communicate it to the plugin.
> i can think of many
> cases where it's necessary to know the total number of samples selected
> before beginning the processing.
Yes... It's beyond the MIDI protocol, but IMHO it's very relevant to
real time processing. (I guess that CSound people will agree here.)
As an example, it makes at least *some* sense that a controller
should be able to specify the length of an envelope section in some
sensible unit, rather than in the form of some arbitrary controller
value without a documented scale, doesn't it? MIDI CCs are sometimes
used to control that kind of parameters, so while in the process of
creating something new, we might as well get it right, and solve some
other problems as a bonus!
> > we're heading for the territory of "host callbacks" like those in VST,
> > where the plugin could find out the circumstances under which it was
> > operating.
>
> perhaps during initialization the plugin could be told whether it's
> running in realtime or not, and if not it could be given some additional
> info like the selection length (total number of samples to . i think
> that that sort of info is generally useful enough to be added to the
> API.
Why make a difference between RT and off-line? That will only
encourage people to write less useful applications, and would still
leave very similar issues for RT unresolved.
An off-line mode might be a useful thing, but this issue has nothing
to do with RT/off-line, and doesn't require a special mode to
function.
BTW, I've been dreaming about a *TRULY* non-destructive audio editor,
that would just assign plugins to EDL clips/regions/pieces, rather
than generating new audio data whenever you do a select + filter type
operation. The plugins would run in real time when the clips were
played, and all parameters could be tweaked in real time, including
those of plugins applied via the select + filter UI.
To realize that, this selection thing HAS TO be done something like I
describe above, or we'd have to add yet another API extension
specifically for that.
> i don't want to knock the LADSPA though, it really looks good and i'm
> excited to start working with it!
Well, it's simple, but still deals nicely with a solid bunch of
issues. :-) However, I'd better finish those strap-on MuCoS event
ports, as the above system would be quite messy to implement without
it.
Speaking of LADSPA + MuCoS events again, as I see it now, there are
basically two problems with that:
1) The MuCoS event system was designed to address most of the
stuff that LADSPA already does in different ways. As
an example, MuCoS has ports, but they're accessed via
events instead of via callbacks.
2) Decoding MuCoS events efficiently and with correct timing
(ie sample accurate dito) requires an outer loop to be
wrapped around the inner loop of existing LADSPA plugins.
You can't just say "I support MuCoS event ports" and then
add an extra callback function.
You can probably see 1) in the few "real" MuCoS API headers I've
released so far. (If you manage to make out what it's all about,
that is! Could use some overview doc.... :-) As to 2), sure, it would
be *possible* to strap on an extra callback or two to deal with
events, but that would be *very* inefficient; probably worse than
doing sample accurate parameter changes on VST. (Which, if you're not
familiar with VST, requires splitting the process() calls in order
to do the parameter changes where intended. This is messy to
implement in the host, and adds lots of function call overhead. The
same goes for LADSPA in it's current form, and any other plugin API
without timestamped events. Note: VST 2.0 *does* have an event
extension, but it's not used as a replacement for the old parameter
interface.)
There; I'll try not to waste more time trying to explain my
incomprehensible event system, but rather spend that time on making
it ready for use!
//David
.- M u C o S -------------------------. .- David Olofson --------.
| A Free/Open Source | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
| for | | Open Source Advocate |
| Professional and Consumer | | Singer |
| Multimedia | | Songwriter |
`-----> http://www.linuxdj.com/mucos -' `---> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Thu Oct 19 2000 - 10:40:32 EEST