Re: [linux-audio-dev] ecasound status update

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] ecasound status update
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Wed Nov 29 2000 - 00:30:01 EET


On Tue, 28 Nov 2000, Paul Barton-Davis wrote:

>> is to take a subset of functionality provided by libecasound, write a
>> simple (my favorite word! :)) API for it, and port it to various
> any particular reason why you didn't want to use OSC ?

To be honest, this was the first time I heard about OSC. But there doesn't
seem to be much overlap with OSC and ECI. Ok, here's some marketing speak:

Simplicity. Ok, I admit I'm starting to overuse the word, but it really is
a key thing in ecasound. One of my design goals is to be able to do
multitrack recording with _one_ command. This was possible with the very
first version of ecasound, and still is. Sure, there are features that go
way beyond, but still, this one operation must be simple. This requirement
comes from my own recording experience. When I'm both the studio engineer
and the musician, I really don't want to mess with the computer too much.
When I have an idea, I just want to record it fast, without any hassle.

Now this leads us to the ia-mode commands. The whole ia-mode has been
designed these same principle in mind. So it's a minimal set of commands
for adding, setting up and removing ecasound objects (exactly five types:
chainsetups, chains, audio objects, chain operators and controllers). The
new ECI APIs just adds a more convenient way of using these commands (no
need to parse ecasound's output). And as these commands are the very same
commands you issue when using ecasound in interactive mode, they are
already familiar to you. No need to learn anything new.

Another benefit is buzz-word compliance. :) ALSA 0.4.x -> 0.6.x,
OSS, LADSPA, aRts, libaudiofile, interfacing to mpg123, lame, ogg123,
vorbize, mikmod, timidity, 8bit->32bit, ... blaa, blaa. And of course,
double-buffered sched_fifo operation, and the blaa-blaa goes on. So if you
just want to play a soundfile from your shell script, this isn't a bad way
to do it.

So coming back to OSC, which is described as "A protocol for communication
among computers, sound synthesizers, and other multimedia
devices". ECI is more close to "Language-level access to ecasound
interactive mode" - so they are two totally different things.

Ok, let's end the marketing speak. I intend to port some of my own stuff
to this new API, which eases my maintainance burden. It's likely the ECI
API will be quite a stable one. Libecasound on the other hand is
constantly developed. It's annoying when even your own projects start to
be all incompatible with each other. :( It's just that you have limited
time to use. If often seems to come down to either 1) concentrate on one
project, 2) spend all your free-software time to maintainance. So even if
nobody else used the new API, it still seems worth doing. But I do think I
could use help from others. Python is a completely new thing for me, and
it's a while since I've written an API in C. :)

-- 
 . http://www.eca.cx ... [ audio software for linux ] /\ . 
 . http://www.eca.cx/aivastus ... [ aivastus net radio ] /\ . 


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Nov 29 2000 - 00:30:15 EET