Subject: Re: [ecasound] Cutting long Live tracks into cdr pieces
From: Kai Vehmanen (email@example.com)
Date: Tue Jan 09 2001 - 16:13:00 EET
On Mon, 25 Dec 2000, Jeremy Hall wrote:
> 1: One might not want the same set of chainops and parameters through the
> whole track, so one needs a way to change them at the right time
This a limitation of ecasound's design. When processing is started, no
objects are created or destroyed. In other words, no memory
(de)allocation. The "ecasound-way" to dynamically control the processing
is using the controller objects to change parameter values. You could for
instance have two chains with the same audio signal, but with separate
parameters. At least in theory, you could have a combination of parameter
controllers that at certain point in time mutes one of the chains, and
lets the other one go through. From user's perspective, this would be just
like you had changed the chainop configuration on-the-fly.
So why make it this difficult? Latency-wise, dynamic memory allocation is
a huge problem. It solvable, but makes things difficult and complicates
code (you have to have a custom rt-capable memory subsystem in your app,
or some kind of preallocation of all object states). And these are two
things I don't like at all.
> 2: One may wish to mute tracks until they are needed, for example, a
> chatty vocal track so real-time processing is necessary for final mixdown
This is possible (c-mute for instance).
> 3: ecasound diminishes amplitude upon adding more tracks, so once things
> are mixed properly, one usually needs to normalize the output. This is
> usually possible only as the last step of a mixdown before cropping.
Ecasound doesn't diminish anything. If it does, you've found a bug. If you
want to add multiple streams of digital audio together, you have to add
the signals together and divide by number of streams. Normalization
(exact) on the other hand is not possible without analyzing all audio
data. You could use compressing (or plain amplification) at the end of the
chains, but ecasound doesn't do this automatically (user might not want
the signal to be automatically compressed).
> 4: short tracks are DEATH TO ONE'S EARS! A short track will place LOUD
> noises in place of silence if the track is finished before the rest of
> them are finished. To hear this lovely effect,
> ecasound -i null -o /dev/dsp
Hmm, no noise here. Are you sure it's not the soundcard driver that's
generating the noise...?
> 5: need a way to print positions in sectors, because what I REALLY want to
> do when I use my dd constructions are:
Ah, this is definitely outside ecasound's scope. Sector has nothing to do
with audio, and dependent (sector size) on the used hardware and OS.
Positions are expressed either as seconds or as a value pair of sample_pos
and sample_rate. Other units are difficult to use in audio context.
> I need a way to shorten the cd making process, for now I need to guess
> where the sectors need to be and then come up with the offset numbers
How about using the .cdr format? Ecasound automatically pads cdr-files to
CDDA sectorsize (2352 bytes).
> I need to write the output to a loop device, then route the output of the
> loop device both to a track file and to /dev/dsp (two chains) so this
> means if I need to perform some effect action, I have to do it both to the
> track chain and to /dev/dsp chain so I can hear what is going on. This is
> a little clumsy at best.
> I suppose Kai's response to some of this is going to be
> Write your own editing software
No, I don't see a big problem here. Ecasound can do these things you've
described. The problem is that these tasks are too complicated for the
current user-interface. So you only have to write a wrapper/user-interface
which does the work for you. The new ECI API is ideal for this kind of
-- . http://www.eca.cx ... [ audio software for linux ] /\ . . http://www.eca.cx/sculpscape [ my armchair-tunes mp3/ra/wav ]
-- To unsubscribe send message 'unsubscribe' in the body of the message to <firstname.lastname@example.org>.
This archive was generated by hypermail 2b28 : Tue Jan 09 2001 - 15:53:59 EET