Subject: Re: [linux-audio-dev] a new application underway
From: David Olofson (audiality_AT_swipnet.se)
Date: ma loka 11 1999 - 19:16:28 EDT
On Mon, 11 Oct 1999, Paul Barton-Davis wrote:
> i spent some time talking with people who use mixers a lot, and asked
> them how helpful it was to be able to use a stereo input signal on a
> single strip. the verdict: as long as you can group (sync) the faders
> for two strips, they didn't care, even when i pointed out that it
> consumed an entire extra strip this way. ah, diehards :)
Actually, I agree with them to some extent. I don't like stereo
plug-ins, unless they have a decent excuse to be stereo. What if I
want to up the treble a little on the left channel of that stereo
strip? These things happen...
> i think it depends in part on what your inputs are. if they really are
> stereo signals (stereo soundfiles, devices etc.), then having audio
> default to stereo is a good choice.
On the contrary, it's usually in that particular case it makes sense
to be able to control the channels independently.
> if they are mostly mono (mono
> soundfiles, devices, mics, etc), which is often true in live
> recording, then it can be a bad choice, computationally.
Yes. However, sooner or later they have to go stereo one way or
another... (Assuming we're playing back from disk/RAM, or monitoring.)
> i noticed that neundo allows both. i'm still thinking about this.
Sounds pretty sensible to me, at least on a digital system where
processing takes power from a common pool. (In an analog system it's
different; either you have enough channels, or you don't.)
> >Hmm, it looks like our designs are actually quite similar. Ecasound's
> >inputs do much the same as your input_device-source-strip abstraction
> >and ecasound's chains are just like your buses (hmm, where do you put
> >additional effect processing... buses or strips?).
>
> like an expensive hardware mixer: both.
Yep. That's a very simple but still efficient way to get the plug-ins
where you want them.
> i'm still working on optimizing the amount of data copying that goes
> on in a net like the one above, but it all works just fine for
> now. MIDI controllable control elements too :)
VST uses the process() and processReplacing() plug-in calls as a
part of that optimization. I suggest process() to be our replacing
method, and process_mix() to add data to the output buffers. The big
difference: process_mix() is *required* to support a linear gain
parameter for each output channel.
But, is the cost of clearing a buffer really significant these days,
when some plug-ins can eat a whole P-II 400 using a single instance?
IMO, it *is* still significant when using lots of simple plug-ins to
build modular synths, so I'd suggest:
"It's *strongly* recommended that fast plug-ins that are
likely to be used in many instances, provide *both*
process() and process_mix(). More CPU intensive plug-ins
may leave out one of them; preferably process(), as that
can be handled by the engine just clearing the buffer
when necessary."
OK? Any other process_*() version that might be even more useful?
(And, hey! Keep in mind that this isn't for audio alone...)
//David
·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
·Rock Solid David Olofson:
·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
·Open Source ·Singer/Composer
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST