Subject: Re: [ecasound] ecasound front end
From: Kai Vehmanen (k_AT_eca.cx)
Date: Thu Nov 01 2001 - 18:15:23 EET
On Thu, 1 Nov 2001, Luke Tindall wrote:
> need to sort out is the data. Writing a ecs parser in c was a pain in the
> arse, python is probably better for this. If the data was better organised
> the parse routines would be a breeze to develop. The major problem I found
> was that all the ecs files always have the chain as the key. I would rather
And at least in theory you shouldn't need to write an ecs parser as
libecasound already has this functionality. You use it by loading the ecs
file with cs-load, and then use ECI commands to query the results.
But of course, in some cases ECI might not be flexible (or easy to use)
enough, and then a custom ecs-parser is needed. In the long run, however,
ECI should be extended to cover as many use-cases as possible, so that ECI
apps could concentrate on adding functionality, not replicating
libecasound code.
Anyway, this is a really interesting topic. At the moment libecasound
understands two "languages", EOS (comand-line line / ecs-files) and EIAM
commands (ECI / iactive-mode). Interpreting these requires quite a lot of
code, so adding support for new input languages (like the .emt multitrack
file format) is usually a bigger task.
On the other hand, once the information is parsed, it's quite easy to
export it. Code for saving ecs-files (cs-save) is only a few hundred lines
of C++!
One interesting option for saving and restoring chainsetups is to use EIAM
directly. It would be relatively easy task to add a new format (let's say
.ees - ecasound eiam stream :)) which would only contain EIAM-commands,
one per line. Some restrictions might be needed (for instance, 'cs-remove'
and 'cs-select' wouldn't be allowed -> one .ees must only affect one
chainsetup).
But, but, would .ees actually be useful... maybe, maybe not. In any case
it's good to keep in mind that adding new formats is a possibility.
The above approach might make more sense to ECI-apps: don't directly
access ecs-files, but instead use ECI for all communication.
- load: cs-load + query parsed information using ECI
- save: create a chainsetup using ECI + cs-save
At the moment at least the load part, more EIAM commands are needed. For
instance querying chainop controller configuration is not possible. You
can get a list of all controllers, but not how they are connected to
chainops nor about their parameters. On the other hand, parsing this
information from ecs files is not easy either.
Yet one more option is to use a custom app specific format, and only use
ECI for execution... ie.
- exec: create a chainsetup using ECI + start/stop/etc
If the state needs to be saved, it is saved into app's own format. This is
actually the approach used by ecawave and ecamegapedal (although they
don't provide support for saving state).
Btw; GAS looks great!
(... some might mix Graphical Audio Sequencer with GNU Assembler. ;))
-- 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 : Thu Nov 01 2001 - 18:09:51 EET