Subject: Re: [ecasound] Submixing in chains
From: Robert Jonsson (firstname.lastname@example.org)
Date: Fri Dec 01 2000 - 08:39:33 EET
Oh, :) a long and very interesting reply, I have to digest it before I
can come up with stupid remarks.
I think I have a few clues how to proceed now, thanks.
Kai Vehmanen wrote:
> On Wed, 29 Nov 2000, Robert Jonsson wrote:
>> In essence I tried to load three mp3 files from disk and process them in
>> different chains. But before sending them to the same output buffer I
>> tried to submix two of them to add common effects. This however didn't
>> work out. The submixer behaved erratic, eca didn't complain, but it was
>> ecasound -a:1 -i:1.mp3 -a:2 -i:2.mp3 -a:3 -i:3.mp3 -a:1 <fxstuff> -a:2
>> <fxstuff> -a:3 <fxstuff> -a:1,2 <commonfxstuff> -a:1,2,3 -o /dev/dsp
> Ok, this shouldn't work. I guess I should add more verbose warnings when
> parsing the above. Root of the problem is adding an effect to multiple
> chains at once; this is not allowed and will result in undefined
> behaviour (at some point, this _was_ allowed, and thus ecasound
> currently lets the error go through).
>> I would consider submixing in the middle of the chains to be a rather
>> complex operation, programmatically, would be nice if ecasound supported
>> it though :-). Opens doors in my mind!! wide open!!
> This is an interesting question. Ecasound in fact doesn't do submixing.
> I call this design one-stage mixing (processing happens during one
> stage). You could compare this to traditional mixers where the mixing
> is clearly two-stage (inputs -> mixer stripes, stripes -> buses,
> buses -> outputs). In addition, many software synths and other "modular"
> gadgets/apps provide n-stage mixing, where you endlessly combine and
> submix signals.
> Now a few reasons why ecasound has one-stage mixing:
> [command-line interface]
> First of all, coming up with a command-line interface for n-stage mixing
> would be really difficult. If we take your example above, the chain "1" is
> selected four times. The first time, it is followed by an input, on the
> second and third you add effects, and the last time it's used for adding
> /dev/dsp output. Now this clearly isn't enough info for 2-stage mixing.
> And even more critical, the last you select "1", it is selected together
> with "2" and "3". From this ecasound knows that /dev/dsp is to be attached
> to all three chains. Routing data from inputs to multiple chains uses the
> same logic. Adding another mix-matrice to this would mean we'd have to
> make the command-line interface quite a bit more complex.
> [software vs hardware]
> Ok, the second reason is that you very rarely need two-stage mixing in the
> "digital domain". With a traditional hardware mixer, it's very convenient
> that you can route all your drum tracks to a single bus, and then run
> that bus through a reverb unit. If this wasn't possibly, you'd need
> multiple reverb units, and you'd need to take care of using identical
> settings in all of them. But when you think about this, adding another
> reverb unit in ecasound (or any other software) is really nothing. Just
> add another -etr and there you are!
> Another example is bouncing. I don't know about you, but at least I've had
> my fair share of doing bounce-mixes on analog recording gear. :) With
> analog gear, it's a slow and painful way of getting a few extra tracks,
> and you always lose in quality. But no so with ecasound. For example, if
> you have a chainsetup/script which mixes all your tracks (with effects) to
> the soundcard. Now all you need to do to make a submix is to replace the
> "-o:/dev/dsp" with "-o:submix-1.wav" and that's it. It's fast, you won't
> lose in quality, and you don't need to do much typing. So if you really
> need to mix track together before applying a common effect (instead of
> applying multiple identical effects), you first do a submix, then apply
> the effect, and start using the submix-file in your recording/mixing work.
> Ok, so there are some good sides in one-stage mixing, but still, why
> make such limitations? This actually is optimizing the common case.
> Thanks to this one-stage limitation, ecasound's engine code is in fact,
> _really_ simple. There's nothing special happening there - read inputs,
> write to chain buffers, process chainops, write to outputs buffers, output
> and back to start. This "core" of ecasound is just about a screenful of
> [the big lie]
> Ok, so I admit it, I've been lying all the time. ;) Although one-stage
> mixing is chosen to be the common-case for optimization (and interface
> design), ecasound does allow even n-stage mixing, but this doesn't come
> for free. There are basicly two ways to get around the one-stage mixing
> 1. effect presets
> Ecasound effect presets are in fact small ecasound engines pretending
> to be effects. Here's an example of multi-chain effect preset:
> -- file 'bassbooster.ecp' --
> # let's put the low freqs into one chain and high freqs in another
> bassbooster = -efl:2000 -ea:200 | -efh:2000 -ea:50
> # note, the '|' sign separates parallel chains
> -- cut --
> ecasound -a:1 -i:some.mp3 -pf:bassbooster.ecp \
> -a:2 -i:another.mp3 -pf:bassbooster.ecp \
> -a:1,2 -o:/dev/dsp
> Here ecasound in fact does 2-stage mixing. Btw; I can't test this
> at the moment, so report if the above doesn't work... (if it doesn't,
> it's a bug!).
> 2. loop devices
> Loop devices were added to ecasound version 1.7.0. You use them like this:
> # note, the second loop parameter is the loop id-number;
> # it is used to associate loop inputs with correct loop outputs
> ecasound -a:1 -i:some.mp3 -o:loop,1 \
> -a:2 -i:another.mp3 -o:loop,1 \
> -a:3 -i:loop,1 -o /dev/dsp -ea:200
> Both inputs are eventually routed to chain "3", where a -ea:200 is
> applied to the signal. This does have one downside, loop device
> adds latency (-b:x -> latency of x frames).
> Huh, hope this reply answered your question. :)
-- To unsubscribe send message 'unsubscribe' in the body of the message to <email@example.com>.
This archive was generated by hypermail 2b28 : Fri Dec 01 2000 - 09:01:00 EET