> As some of you might already have noticed, couple of new directories have
> been added to the CVS-tree: ecasound/libecasoundc and ecasound/pyecasound.
Great! It's exciting to see the framework getting in place :)
> The first one is a C-library implementing the Ecasound Control Inferface,
> and the second a Python version of the same thing.
The compilation halted because of this: apparently it was trying to
"#include" a header named python.h and couldn't find it, is it a file
foreign to ecasound? I have only the bareminimum of python packages
installed on my system, not being learned in python myself. Clearing
references to pyecasound in the Makefile fixed this, BTW. I guess it
would be wise to eventually include an option in configure to select
the building of this library: something like "--build-python-api",
or a distinct make target.
(I just checked for new configure options, after having written the above;
I saw --with-python-modules and --with-python-includes but nothing to
actually disable the building of the ecasound related library.)

>
> -->
> 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
Well, it makes sense to me, but I don't plan to write extremely complex apps around ecasound either, basically just things to make life easier, you might find people with greater exigences.

Two things: and I admit they might be questions just showing my ignorance :)
1) Would there be ways to get real time "extended" status informations as
the process would go on? (for example: an app in which there would be a
mechanism to emmit a warning each time an underrun would occur.) "Extended
status" is a little vague, I know, but I'm thinking of problems that could
occur during processing time and that one might wish to monitor...
2) How one would do, with the material you gave above, to, for example,
discover the amound of clipped samples in a recording? As far as I know there
is no ia-mode command returning that information, or is it? More generally,
I'm thinking of chain-operators returning useful information in real time (-ev for example).

> 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)
lol, indeed