Subject: [linux-audio-dev] ecasound status update
From: Kai Vehmanen (k_AT_eca.cx)
Date: Tue Nov 28 2000 - 21:04:43 EET
Ok, a little status update of what's happening on the ecasound front.
As I've already mentioned, now that we have Ardour, ecasound's development
will concentrate on other things. Primary focus will still be multitrack
recording, mixing and effect processing, but I will spend less time on
GUI work. And this is probably good, as I admit being one of the
"anti-mouse folks" Paul mentioned earlier. ;D
Anyway, this message is about Ecasound Control Interface (ECI). The idea
is to take a subset of functionality provided by libecasound, write a
simple (my favorite word! :)) API for it, and port it to various
languages. At the moment, the idea is to have at least C++, C and Python
implementations of the API in the main ecasound distribution. Now writing
all this from scratch wouldn't necessarily be wise. Luckily that is not
required as ecasound's ia-mode already exists. Hmm, as a short description
of ia-mode, think of gdb and its CLI - that's ecasound+ia-mode. List of
current ia-mode commands is online at:
http://www.wakkanet.fi/~kaiv/ecasound/Documentation/ecasound-iam_manpage.html
And just to make sure, ECI is a highlevel API. The targetted use-cases
are: 1. automating (scripting in its traditional sense)
2. frontends (generic, specialized, GUI/console, etc)
3. basic sound services to other apps
As an example, Heteca and Eco are two apps that belong to the second
group. Both fork ecasound on the background and use a std-pipe to
communicate with it (like gdb frontends). Both provide a graphical
frontend for multitrack recording. Heteca is written in python and
provides both ncurses and gtk interfaces. Eco is written in perl and
provides a tk ui. For more info, see http://eca.cx/eca_links.html
If you are interested in ECI (either using it, or helping to
design/develop it), drop me a note! And also, I'd like to know whether
I am rewriting something that already exists. ;)
---------- Forwarded message ----------
Subject: [ecasound] update: ECI API
As some of you might already have noticed, couple of new directories have
been added to the CVS-tree: ecasound/libecasoundc and ecasound/pyecasound.
The first one is a C-library implementing the Ecasound Control Inferface,
and the second a Python version of the same thing.
You can already write a simple app using the C-api. Pyecasound doesn't yet
do anything useful, but you can compile it and install the produced Python
module. Then pretty much all you can do is "import pyeca ; a =
pyeca.ECA_CONTROL_INTEFACE()". But nevertheless, it's a good start.
I will also implement this in C++ (class ECA_CONTROL_INTERFACE). I'm not
yet sure whether to put it to libecasound, or to add a separate library
(libecasoundci?) and possibly avoid compatibility problems.
So what's left is to actually implement the ECI services. I've given this
a lot of thought, and managed to reduce the API quite a bit. Reasons for
doing this are:
- minimal API is simple to port to new languages (Perl for example)
- features can be added without affecting the API -> apps using the
ECI API don't need to be rewritten every once in a while
-->
Ecasound Control Interface - proposal 2
- issue an iamode command (direct, formatted string)
- last string
- last list of strings
- last integer
- last long integer
- last double
- error flag (int/boolean)
- last error (string)
<--
Yup, that's it. I left out most of the services listed in the first
proposal. The idea here is that all operations are done by issuing
an ia-mode command. For functions that return a value, you check the
ia-mode documentation and lookup the return type of that function, and
then, use the above functions. So for example, getting a list of chains
would look something like:
eci_command("cs-select record") # select chainsetup "record"
eci_command("c-list-all") # list all chains of "record"
a = eci_last_list_of_strings() # copy the list to 'a'
if len(a) > 0
eci_command("c-select " + a[0]) # select the 1st chain
What do you think? I still have to think about what last_* services are
really needed, and possibly, is some type of return value missing from the
list. This is a somewhat tricky question. The more last_* types you have,
less parsing you have to do in apps using ECI, but on the other hand, if
"last_string()" was the only variant, you wouldn't need to check ia-mode
documentation all the time. Also, a possibility to issue an ia-mode
command with a numerical parameter would also come handy. For instance:
--cut--
eci_command("aio-add-input wicked_drums.wav")
eci_command("aio-add-output /dev/dsp")
eci_command("cop-add -efl:400") # add a lowpass filter
eci_command("start") # start processing
finished = 0
while(finished == 0)
sec = 0.0
while(sec < 10.0)
sleep(1) # sleep for 1s
eci_command("cs-position") # fetch current pos in secs
sec = eci_last_double()
eci_command("cop-select 1") # select the lowpass filter
eci_command("copp-select 1") # select the 1st param (=cutoff)
eci_command("copp-value") # fetch the current filter freq
value = eci_last_parameter()
value = value + 400
eci_command_numeric("copp-set", value) # set a new value
eci_command("cs-is-finished") # check whether still running
finished = eci_last_integer()
--cut--
This would play the 'wicked_drum.wav' applying a lowpass filter
to the signal before sending it to /dev/dsp. Every 10 seconds,
the filter's cutoff freq would be increased by 400Hz (ok, not really
useful :)).
Now I want to emphasize that I _don't_ want to turn ecasound (or any part
of it) into a programming language. There are plenty of complex audio
languages available (Csound, Common music, Cmix, Saol, etc, etc). My
intention is that ia-mode commands are something that any ecasound user
can use. The added bonus is that the same commands are always available:
you type them in ecasound's own ia-mode (ecasound -c), you launch ecasound
on the background and send the commands from your app, use one of the ECI
APIs directly, etc, etc ... So if my proposals start sounding too
weird and/or complex, please, stop me at once! :) ... (I can already see
myself waking up, a couple of years from now, realizing that I have just
reimplemented csound. Uhm, a terrible way to start your day. ;D)
-- . http://www.eca.cx ... [ audio software for linux ] /\ . . http://www.eca.cx/sculpscape [ my armchair-tunes mp3/ra/wav ]
This archive was generated by hypermail 2b28 : Tue Nov 28 2000 - 21:05:01 EET