Subject: Re: [ecasound] MISC: Of dump-commands
From: Kai Vehmanen (k@eca.cx)
Date: Sat Oct 28 2000 - 13:14:37 EEST
On Fri, 27 Oct 2000, Luke Tindall wrote:
>> /**
>> * C-API to libecasound
>> */
[proposal cut away]
> So by linking to libecasound it will be possible to use the above function
> calls. Good. Sound like a good way to go especiialy for a mixdown app.
It'll probably be in a separate library (libecac), although distributed in
the main ecasound package. This way people might actually find the
C-routines. :)
> However how about a song position feed back? If the app was to implement a
> visual time keeper, would the eca_engine_status call be fast enough to
Of course, the proposal I wrote was just a preview what the C-API could
be, ie. I didn't even try to include all necessary functions.
> display time real-time? Also say you have a dial that controls panning, for
> example, how reponsive will this be? In other words how long would it take
> for eca_command() to complete in comparison to using ecasound in interactive
It should as fast as an iactive-mode command. Iamode command consists of
one word command part, and arguments (usually one comma-separated list
of arguments). Here's how the parser works:
1. you issue a command (ecasound ia-mode, C++ library call, C-api)
2. command() function in class ECA_CONTROL parses the first word
(the actual command), and converts it into an integer, or
more accurately, into an enum value)
3. action() funciton in class ECA_CONTROL has a huge switch-case
statement which has cases for every defined enum-value
4. if the issued command operates on currently running
chainsetup, action() insert the command to a FIFO-buffer that
is used for communicating with the engine, otherwise action()
just performs the approapriate function()
When using the C API, you'd only need one extra function call in
(1) compared to C++ program calling command(). The current console-mode
already has to do the extra function call as it uses readline() (a
C-function) to handle user input. So shouldn't be a problem to anyone.
If you want to control panning during runtime, the critical parts are (2)
and the FIFO-mechanism in (4). (2) uses STL map<> structure to do the
string->int conversion and is quite fast (most STL implementations use a
red-black tree here). Engine queries the FIFO buffer mentioned in step
(4) once in each iteration (-b:x defines the length of one iteration).
One way to boost performance would be to make the enum structure
(see libecasound/eca-iamode-parser.h) public. Instead of
passing strings all the time, you could use the enum values
directly. So something like:
--cut--
/**
* C-API: interpret an ecasound command
*
* @param cmd enum-value defined in eca-iamode-parser.h
* @param args a comma-separaed list of arguments
*/
void action(enum Iamode_command cmd, const char* args);
--cut--
But all in all, these shouldn't matter that much. Iamode was designed
user-triggered events in mind. If you need a constant control flow (for
instance, using a drawn envelope to control panning), the correct
way to implement it would be to add a new controller source to
ecasound (like the current sine oscillator, -kos).
-- . http://www.eca.cx ... [ audio software for linux ] /\ . . http://www.eca.cx/aivastus ... [ aivastus net radio ] /\ . . http://www.eca.cx/sculpscape [ my armchair-tunes mp3/ra/wav ]-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Sat Oct 28 2000 - 13:45:55 EEST