Subject: Re: [ecasound] time-delay and down-mixing
From: Kai Vehmanen (firstname.lastname@example.org)
Date: Mon Nov 08 1999 - 02:57:54 EET
On Sun, 7 Nov 1999 email@example.com wrote:
> My band (http://gamh.cx) started using ecasound last night. It worked well, but
> there were a couple of features that we really missed.
Hmm, I'll have to a look at your web site. :)
> The first thing we realized was that all the tracks in a song have to start
> from the beginning. So if we add a 1-second sample to a song, it has to be
> padded with silence? This doesn't make a lot of sense. Interactive mode allows
> you to move around within a file, but it doesn't seem to allow you to dump a
> certain section to a sound file (other than by printing to stdout, re-directed
> into a file, or capturing it with ALSA).
Actually ecasound has basic support for this via the .ewf format.
Basicly .ewf file is just an ascii-file that contains a sample offset.
This sample-offset is used to trigger the actual sample file. So you
somefile.ewf (this is given on the command line)
You can change position, insert silence, whatever and only the offset
changes. Then when you start writing real data, somefile.wav is
created and offset is now locked. This is totally transparent to the
rest of the system. I've used it myself a couple of times and it has
worked rather nicely. The biggest problem is that I've haven't had time
to test, debug and document it. If you look at the source code, you
see it's rather simple at the moment. Because of this, I haven't
advertised it very much.
> What we really want to do is to be able to focus on one section of a song and
> record tracks for just that section. So, for instance, we could have percussion
> and guitar tracks that go through the whole song, but record each verse as a
> separate sample. Basically, we need to have chains that start somewhere later
> in the song.
1.6.x series will also offer routines/commands for setting chain
position independently from other chains.
> The second thing we really missed was downmixing. When we're mixing stuff to
> see how it sounds, we don't really care if it's CD quality. It would be nice to
> be able to a bunch of take mono, 16-bit, 44100kHz .wavs and turn them into a
> 22050kHz output, or even an 8-bit, 11025kHz output if we had a really slow CPU.
The biggest problem with this is ecasound's design. By reading
cd-quality files and then downsampling, you won't gain much in speed.
You can already change the internal sample rate with the "-sr" option.
I usually have a "mixdown" script, which I use to make a copy for
listening. I'll have to think about this some more.
> - Interactively move around the full mix of the song to find out which section
> of the song we want to record along with. Ideally, ecasound would pick the best
> sampling rate that it could mix at without skipping.
This is the problematic part. Ecasound's design is rather generic and
program modules don't know much about other modules. To achieve this
kind of "automatic functionality" you'd need to create a new interface to
libecasound for this. If you look at eca-text.cpp (source code for the
console mode user-interface), you see that it is _really_ simple. It
just passes commands to the library routines. Anyway, moving around
the song should be possible.
> - Dump the section to a .wav. If we're in a hurry, we could make a low-quality
> .wav, since we're just mixing against it.
Hmm, this might be a nice feature. I've been thinking about
implementing regions. This way you could select certain ranges for
> - Do a full-duplex recording of the new track along with the .wav. Handling
> only two tracks would hopefully reduce the probability of skipping.
Well, actually, this is how I've done it since the early days of
ecasound. ;) I basicly have two scripts: one for mixdown and one for
recording. The mixdown script always outputs to current-mix.wav so
I don't have to change the recording script.
> So I was wondering:
> 1) Are these features in fact implemented, and we just missed them?
Well, some of them are, but most are not.
> For instance, is the -etd effect smarter than we thought?
No, it's just a dumb old delay. ;)
> 2) Are you planning to include these features soon?
Yes, but these will take time. I've written over 15000 lines of code
during the last 6 months and it seems that I have lot more work ahead
> 3) If not, I wouldn't mind implementing them myself (I'm a reasonably competent
> programmer). Should I start from the latest development version, or is the
> latest stable version close enough?
Well, help is always very, very welcome! For instance, the ewf format
needs testing and improvements. I'm going to release the first 1.6.x
series development version of ecasound today or tomorrow. It contains
so many changes that 1.5.x versions are not a good refence anymore. Of
course with changes like these, it will take some time before 1.6.x
> 4) Do you want me to work closely with you on this, or just fork off a new
> version which will be eventually merged back into ecasound?
Well, basicly whatever suits you best. I guess I'd prefer to have
small (disctinct) patches or additions, but I'm open to suggestions.
New effects, ideas, documentation, bug hunting, everything is
And of course, you can always start a new project around the
libecasound library. ecasound, qtecasound, ecatools programs
and also the upcoming ecawave project all use libecasound.so.
Many people have asked me about a multitrack-recording oriented (and
easy-to-use) graphical interface that would make ecasound more suitable
for the end users. I'd be happy if someone started this project. 1.6.x
series will offer a good platform for doing this (well, as soon as it
-- Kai Vehmanen <firstname.lastname@example.org> -------- CS, University of Turku, Finland . http://www.wakkanet.fi/ecasound/ - linux audio processing . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav . http://www.wakkanet.fi/kerttulin_listat/ - music&movies (in Finnish)
This archive was generated by hypermail 2a24 : Mon Nov 08 1999 - 02:30:24 EET