Subject: Re: [ecasound] MISC: Of dump-commands
From: Kai Vehmanen (k@eca.cx)
Date: Fri Oct 27 2000 - 00:29:27 EEST
On Wed, 25 Oct 2000, janne halttunen wrote:
> The dump-commands have been useful in my ecasound-frontend at
> reducing the parsing of ecasound normal output. You have to, however,
> to request the dumping, there's no automatic 'when value changes'
> dump-objects. I don't know if it would be worth the effort to extend
> the dump section with commands like: dump-object-add
> <value-to-dump-when-changed>, or to have multiple dump-targets.
[...]
> Depends on you Kai, but I guess at some point it would be easier
> to go straight to libecasound. How is it going with the C-api? :)
The C-api is still in the "might-be-implemented" section. But unlike many
other todo-items, I'm willing to give this top priority. I'm just still
unsure whether C-API is good enough. As you might have noticed, I'd like
to get more people involved in ecasound development (either ecasound
itself, or apps using ecasound/libecasound). There are so many things I'd
like to try, but I just don't have the time. I've tried to make the C++
API as usable as possible, but this hasn't received much interest. So
far, extending the console mode API, and providing LADSPA support have
proven to be most useful. But what to do now...
Possible solutions:
1) continue to extend the iactive-mode
2) provide a small C-API (easy to maintain)
3) provide a more functional C-API (C wrapper for C++)
4) provide wrappers for scripting languages (Python, Perl, ?)
I have little experience with the above mentioned "scripting" languages,
so it's difficult for me to compare the alternatives. Writing a simple
C-API (2) would be a quick task, but I'd like to know what functionality
is needed to do actually do something useful. Here's a short example:
--cut--
/**
* C-API to libecasound
*/
/**
* Initializes session. This call clears all status info and
* prepares ecasound for processing. Can be used to "restart"
* the library.
*/
void eca_init(void);
/**
* Frees all resources.
*/
void eca_cleanup(void);
/**
* Sends a command to the ecasound engine. See ecasound-iam(5) for
* more info. :)
*/
void eca_command(const char* command);
/**
* Fills the structure pointed by 'status'. Provides
* info like "running/stopped", position, active objects,
* selected options, etc.
*/
void eca_engine_status(eca_engine_status_t* status);
...
--cut--
How does this look? Implementing the above would be really an easy a task,
but as you imagine, it can quickly turn into a maintainance hell.
Thoughts; what would be a good subset of libecasound functionality?
Hmm, one thing to note is that the above is actually a C-API to the
iactive-mode C++ implementation. Ie. you won't get access to actual sample
data, or actual objects. I've thought about separating libecasound into
libecasound (core functionality) and libecacontrol (iactive-mode
implementation), to emphasize the difference.
For instance qtecasound and ecawave - although written in C++ - mostly
just use string commands. Only in few special cases (for instance,
to draw the waveform, ecawave requires access to actual sample data)
direct access to libecasound C++ objects is required. From maintainance
point of view, this approach has been very practical (API changes in
libecasound only rarely require changes in qtecasound/ecawave code).
-- . http://www.eca.cx ... [ audio software for linux ] /\ . . 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 : Fri Oct 27 2000 - 02:26:49 EEST