Subject: Re: [ecasound] ECI standalone in action
From: Kai Vehmanen (k_AT_eca.cx)
Date: Fri Oct 11 2002 - 02:44:47 EEST
Doh, doh, doh. I seem to have developed a very annoying new habit of
forgetting to actually send already written mails. The following is from
last Sunday.
On Sun, 6 Oct 2002, S. Massy wrote:
>> # ecalength linked to my new SA ECI impl
> Yes, that was a problem with the ECI implementation up till now: linkage
> against many libraries (including libstdc++ even for non-C++ apps.)
> The new scheme for ECI really seems straightforward and powerful.
Yes. At first this seemed more like an interesting experiment, but while
working on the implementation I realized the numerous of benefits of the
SA-design:
- this is practically the only possible way to make frontends/scripts that
work with different major versions of ecasound (ie. current with 2.0 and
2.1devX)
- by having the ecasound in its own process, we solve a number of
linking problems (for instance the dlopen() issue with python
and alsa-lib should be solved by this)
- this allows to use NetECI in combination with ECI apps; this might
sound a bit complicated at first, but it really is quite useful;
for instance I'm currently using 'ecamonitor' to monitor my
tkeca session (!)
... and also, althought the first versions seemed a bit unrealiable, the
latest versions is actually quite robust. I've run a few complicated ECI
tests and it seems to survive them just fine. Of course, more testing is
still needed, but it looks quite good.
> BTW, have you thought of making ecasound shell script friendly? Something like
> providing raw access to the command parser (i.e with readline and
> ncurses disabled) so that a shell could interact
> directly with ecasound.
There's already the '-D' option. That disable curses and realine, plus
it directs all output to stderr. Is something more needed?
-- http://www.eca.cx Audio software for Linux!
This archive was generated by hypermail 2b28 : Fri Oct 11 2002 - 02:43:20 EEST