Re: [ecasound] MISC: Of dump-commands

New Message Reply Date view Thread view Subject view Author view Other groups

Subject: Re: [ecasound] MISC: Of dump-commands
From: Kai Vehmanen (
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:

 * 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);

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).

 . ... [ audio software for linux ] /\ . 
 . ... [ aivastus net radio ] /\ . 
 . [ my armchair-tunes mp3/ra/wav ]

-- To unsubscribe send message 'unsubscribe' in the body of the message to <>.

New Message Reply Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sat Oct 28 2000 - 13:45:55 EEST