Subject: Re: [ecasound] ECI and curses
From: Kai Vehmanen (k_AT_eca.cx)
Date: Tue Jan 29 2002 - 21:50:55 EET
On Tue, 23 Oct 2001, janne halttunen wrote:
>> there's always away to solve these. But I wouldn't like to direct all
>> debugging info to the ECI just to get a few important ones.
> Ok. Take 'cs-add', for example. When user does 'cs-add blah', obviously
> ecasound adds chainsetup named 'blah', but user gets no feedback unless I
> write some. (there are quite many of these commands returning None, [-])
[...]
> What if these print commands could be redirected to, f.ex, a FIFO?
> (how about dump-target?) That would really help a lot.
Hmm, I guess I'll have to change my mind... the best solution does seem
to be redirecting all debug messages to ECI. Libecasound has support for
custom debug targets (for instance qtecasound has its own debug widget),
so only thing missing is a way for ECI apps to access the information.
The implementation would have to be based on callback functions. The ECI
client would register a debug callback function, which libecasound calls
for each debug message (containing debug level and message contents).
Unfortunately this would require changing the ECI API (quite a lot of work
as all ECI implementations would have to be changed).
For now, I think the best way is to not rely on libecasound debug
messages and instead print all required messages in the client. So for
instance with 'cs-add', the client should do the following:
cs-add mysetup
tmp = cs-selected
if tmp != "mysetup":
print("Error! Unable to add chainsetup " + mysetup)
else
print("Chainsetup " + mysetup + " added."
-- http://www.eca.cx Audio software for Linux!-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request_AT_wakkanet.fi>.
This archive was generated by hypermail 2b28 : Tue Jan 29 2002 - 21:41:51 EET