Re: [ecasound] update: ECI API

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

Subject: Re: [ecasound] update: ECI API
From: janne halttunen (jhalttun@pp.htv.fi)
Date: Thu Nov 30 2000 - 21:08:50 EET


> As some of you might already have noticed, couple of new directories have
> been added to the CVS-tree: ecasound/libecasoundc and ecasound/pyecasound.
> The first one is a C-library implementing the Ecasound Control Inferface,
> and the second a Python version of the same thing.

    Yihaa! Is the Python-thingie done with SWIG, handcoded, or what?

> You can already write a simple app using the C-api. Pyecasound doesn't yet
> do anything useful, but you can compile it and install the produced Python
> module. Then pretty much all you can do is "import pyeca ; a =
> pyeca.ECA_CONTROL_INTEFACE()". But nevertheless, it's a good start.

-- >8< --

> -->
> Ecasound Control Interface - proposal 2
>
> - issue an iamode command (direct, formatted string)
> - last string
> - last list of strings
> - last integer
> - last long integer
> - last double
> - error flag (int/boolean)
> - last error (string)
> <--

-- >8< --

> What do you think?

    (from my point of view) An important question: can one have multiple instances of ECI to one engine?
So that the ECIs would bombard the same engine, but have individual last_* -buffers?

eci1.command("cs-position")
eci2.command("aio-position")
a=eci1.last_double()
b=eci2.last_double()

In the above, so that a!=b would be possible..

> I still have to think about what last_* services are
> really needed, and possibly, is some type of return value missing from the
> list. This is a somewhat tricky question. The more last_* types you have,
> less parsing you have to do in apps using ECI, but on the other hand, if
> "last_string()" was the only variant, you wouldn't need to check ia-mode
> documentation all the time.

    BTW, how would one find out in this ECI-scheme, is a chainsetup connected or not?

> Now I want to emphasize that I _don't_ want to turn ecasound (or any part
> of it) into a programming language. There are plenty of complex audio
> languages available (Csound, Common music, Cmix, Saol, etc, etc). My
> intention is that ia-mode commands are something that any ecasound user
> can use. The added bonus is that the same commands are always available:
> you type them in ecasound's own ia-mode (ecasound -c), you launch ecasound
> on the background and send the commands from your app, use one of the ECI
> APIs directly, etc, etc ... So if my proposals start sounding too
> weird and/or complex, please, stop me at once! :) ... (I can already see
> myself waking up, a couple of years from now, realizing that I have just
> reimplemented csound. Uhm, a terrible way to start your day. ;D)

:)

jsh

--
To unsubscribe send message 'unsubscribe' in the body of the
message to <ecasound-list-request@wakkanet.fi>.


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

This archive was generated by hypermail 2b28 : Thu Nov 30 2000 - 21:33:16 EET