Subject: [ecasound] extending the C-API design
From: Kai Vehmanen (k@eca.cx)
Date: Sun Nov 05 2000 - 23:48:19 EET
One thing that I still find problematic is the question of where to the
draw line. Libecasound contains over 25000 lines of code, ie. it's quite a
huge codebase. Hopefully most of this code is useful. On the other hand,
providing alternatives APis to all this functionality would be a
maintainance nightmare. I've taken look at a few "binding generators",
most notably SWIG and SIP. They would cut down the maintainance needed,
but not enough. For instance, I just downloaded Python bindings to both
Gtk and Qt, and what can I say, they are _huge_ packages!
On the other hand, does anyone really want lowlevel (in audio world this
would mean sample-level) access from scripting languages?
Another issue is depencies. If all programs using libecasound would have
access to the whole library, this would mean that all libecasound changes
would require recompilation (and possibly source-level changes) in all
apps. This again would either a) slow down development, or b) generate a
incompatibility mess.
So I've come to the conclusion that it is better to separate a certain
subset of libecasound functionality, and provide alternative APIs to this
functionality alone. So...:
------>
1) Ecasound APIs
a) Ecasound Library Interface
Collection of C++ classes located in libecasound.
b) Ecasound Control Interface
A subset of (a) based on the Ecasound Interactive Mode. Ecasound
Control Interface provides the following services:
- iamode commands
- issue a command (direct, formatted string)
- engine control (start, stop, run, quit)
- session control and information
- global position and length
- runtime info (is running, is finished, etc)
- toggle engine modes (buffersize, raised priority, etc)
- read access to ecasound per-user resources (~/.ecasoundrc)
- chainsetups
- add, remove
- connect, disconnect, select, edit
- load, save
- get selected/connected chainsetup
- get list of chainsetups
- set/get chainsetup parameters
- chains
- add, remove, select
- control; forward, rewind, mute, bypass
- get chain information
- get list of chains
- audio objects
- add, remove
- status; position, open/closed, audio format
- control; setpos, rewind, forward
- get list of audio objects
- list of attached chains
- chain operators
- add, remove
- set/get parameter value
- get list of chain ops
- controllers
- add, remove
- get list of ctrls
- object maps
- get list of supported audio object, chain op and
controller types
2) Bindings to other languages than C++
Instead of providing wrappers for the whole library (a), the aim is to
provide only the functionality belonging to the Control Interface (b). The
C++ implementation of (b) is done in libecasound. As functions included in
(b) are fairly simple, it should be easy to implement them in any language
(C, Python, Perl, Java, etc, etc).
One important thing to note is that various implementations of the Control
Interface don't need to be identical. As a simple example, let's consider
how to implement the service 'get_list_of_chains()'. In C++, the natural
solution is to return a vector of strings (vector<string>). Now how about
other languages...
As usual, things are more difficult in C. Returning a pointer to a struct
or to an array, would just cause resource management problems (who takes
care of reserving and freeing the needed memory). I'd probably resolve
this by providing a simple iterator interface. So you'd have
'get_number_of_chains()' and 'get_chain_number(int n)'. You'd still have
to resolve the ownership of the returned 'char*', but that's at least
somewhat easier than the original problem.
Now, on to the next language. Python (and I guess most other scripting
languages) provide flexible dynamic structures. So you could just return a
list or tuple of strings... This is much more convenient than trying to
design an uniform API that fits all languages.
Another issue is completeness. It's not required that all implementations
of the Control Interface are complete. In most cases, just providing the
basic service for issuing ia-mode commands is enough to get you started.
Even the C++ implementaion still lacks a few important services (most
notably, routines for accesing object maps).
<------
Comments?
-- . 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 : Mon Nov 06 2000 - 00:05:30 EET