Subject: Re: [linux-audio-dev] Plugin APIs (again)
From: David Olofson (david_AT_olofson.net)
Date: Mon Dec 09 2002 - 23:01:15 EET
On Monday 09 December 2002 18.56, Steve Harris wrote:
> On Mon, Dec 09, 2002 at 05:31:41PM +0100, David Olofson wrote:
> > So, what do you do if you don't *have* the source signal you want
> > in audio format? Hack the plugin? (Yeah, ordinary users will love
> > that...)
>
> Well ordinary users dont want audio rate controle either... until
> sfotware companies tell them they do ;)
Well... Ok, ok, I'm not an ordinary user! :-)
But I still deal with pretty "ordinary" music, I'd say... Guess I'm
just too much of a perfectionist, or something. ;-)
> > > Well, when people start writing audio rate DSP software that
> > > isn't full of hacky optimisation and aproximations the audio
> > > rate stuff will be much slower than the control rate stuff ;)
> >
> > So, *that's* how desktop applications got as insanely slow as
> > they are these days... :-)
>
> Sure. And so good.
Yes. Trade-offs. Faster hardware can cut development time, or give
the user more actual computing power - both, if you're lucky, or wait
long enough.
> > "If I don't need to optimize this, I don't need to optimize
> > that..."
>
> Hmmm. well there are optimisations that jsut make things faster and
> there are optimisations that make things faster and worse. Events
> are sometimes the later.
Yeah, that can't be avoided. They're not a trivial hack.
In some cases, you simply need some new, custom plugins. Native code,
designed for the task...
Fortunately, we're audio hackers. :-)
> > Well, there's a practical problem with off-line stuff as well;
> > tweaking until you get the perfect sound takes ages... *hehe*
>
> Oh, yeah. RT editing and massive polyphony makes this stuff so much
> more fun. Which is why I'm ecouraging events here :)
Right. It's the best "compromize" for current hardware. Sample
accurate, and not too hairy in relation to the performance advantages.
> > Until we can do away with blocks, we probably can't do away with
> > events either. Those sort of belong in the same order of
> > magnitude of work vs overhead.
>
> Yup. Agreed. Though there are a few sitaution where blocks+cont.
> control is worthwhile. Just not in generic instrument APIs.
No, it probably still belongs only in the inner workings of modular
synths, and internally in some "ordinary" plugins.
> Obviously I'd rather have blockless.
Well, those kind of belong together - at least if you're working on
the level where feedback loops are used frequently. I think an
"ordinary" plugin API can do some of this, but only for sane feedback
delays, unless you can accept burning most of the CPU time on
overhead.
Modular synths that generate code from graphs are a rather
interesting approach, though... :-)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
.- M A I A -------------------------------------------------.
| The Multimedia Application Integration Architecture |
`----------------------------> http://www.linuxdj.com/maia -'
--- http://olofson.net --- http://www.reologica.se ---
This archive was generated by hypermail 2b28 : Mon Dec 09 2002 - 23:05:54 EET