Subject: Re: [ecasound] update: ECI API
From: Kai Vehmanen (k@eca.cx)
Date: Fri Dec 01 2000 - 01:26:03 EET
On Wed, 29 Nov 2000, S. Massy wrote:
>> 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
Uh, this is fixed. I've written the usual autoconf stuff for pyecasound.
Configure searches for python module (where the modules should be
installed) and include paths. If these are found, pyecasound is enabled
unless --disable-pyecasound is given. Otherwise, pyecasound is disabled.
> foreign to ecasound? I have only the bareminimum of python packages
> installed on my system, not being learned in python myself. Clearing
With most distros, you need to install python-dev, which has the
python.h header file ...
> (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.)
Yup, these still exist, and now we also have --disable-pyecasound.
[ Ecasound Control Interface - proposal 2 ]
> 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...
Mostly it's just a question of specifying what extended info you need, and
then add the appropriate ia-mode command for it. This is easy. Now a much
more difficult thing is supporting events that come from the ecasound
engine - ie. something that happens during processing would trigger an
event which is reported to the ECI client. This would mean that we'd have
to add support for callback functions to the ECI API ("when event x
happens, call my callback routine y"). Whether this is need, I'm not sure
yet.
> 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).
Yup, I've thought about this. I guess the easiest solution would be to
use chain-operator parameters as both inputs and outputs (just like in
LADSPA plugins). So you'd have -ev:result-max-gain-%. When the
extended parameter hints are implemented, there could be an
"input/output" field, that would tell the engine whether the described
parameter is an input (parameter used/read by the chainop) or output
(param written to). So you could use "cop-get" or "copp-get" to get
the result.
One curious detail of ecasound's chainop interface is that objects
can change their parameter configuration on the fly. So at least in
theory, it would be possible for instance to have -ezf (calculate
DC-offset) to report offset-values for channels: -ezf:ch0,ch1,...,chN
If the input is a stereo file, -ezf would have two parameters, 4ch -> 4
params, and so on...
-- . http://www.eca.cx ... [ audio software for linux ] /\ . . http://www.eca.cx/aivastus ... [ aivastus net radio ] /\ .-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Fri Dec 01 2000 - 05:09:08 EET