Subject: Re: [ecasound] update: ECI API
From: Robert Jonsson (email@example.com)
Date: Wed Nov 29 2000 - 08:30:50 EET
I'd first like to say I think this looks great, I've been longing for
python support in ecasound! Can't wait to try it out :)
S. Massy wrote:
> On Tue, 28 Nov 2000, Kai Vehmanen wrote:
>> 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 :)
>> 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).
I was thinking about something similar.... I think.... It really boils
down to an event system. This might not be the right thing for a
"simple" control interface, it is however very useful for the more
advanced applications out there...
As in the example you showed.
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()
The program is in a loop while waiting for things to happen. This might
be okay when the eca setup is small. But in something like heteca i
would think it could get both inefficient and rather sluggish. In the
example you only get status updates once in a second.
If ecasound somehow (not sure of the best way, I'm not experienced with
the internals of ecasound) could propagate
status/error/property-information to the host application I think these
types of issues could be erased efficiently.
Ofcourse I take it all back if a) I misunderstood the question, b) it's
already implemented, c) I'm easily proven wrong 8-)....
-- To unsubscribe send message 'unsubscribe' in the body of the message to <firstname.lastname@example.org>.
This archive was generated by hypermail 2b28 : Wed Nov 29 2000 - 08:52:09 EET