Subject: Re: [ecasound] update: ECI API
From: janne halttunen (firstname.lastname@example.org)
Date: Fri Dec 01 2000 - 14:35:52 EET
> > Yihaa! Is the Python-thingie done with SWIG, handcoded, or what?
> 100% handcoded. The Python C APIs turned out to be well designed, so it
> didn't take that long to grasp the basics. As the ECI is going to be a
> small API, using a generator like SWIG would just make thing more complex.
> Uhm, or so I hope. :)
> > (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?
> Multiple instances, yes, but controlling the same engine, no. But that
> shouldn't really be a problem...
> > eci1.command("cs-position")
> > eci2.command("aio-position")
> > a=eci1.last_double()
> > b=eci2.last_double()
> So this would result in a==b. But you can do:
> But of course, if you can come up with a scenario where the above doesn't
> work, then we'll have to make a change.
I'm thinking about threading. I haven't much experience of it yet, but I have a feeling I'm gonna delve into it sometime. So, if:
..there might be a possibility of conflict? (meaning A would get "aio-position" or B, "cs-position"?)
Or is this where those mysterious Locks in the threading-module could help?
> > BTW, how would one find out in this ECI-scheme, is a chainsetup connected or not?
> Something like:
> eci_command("cs-select record_setup")
> a = eci_last_integer()
> if (a != 0) print("Connected!")
> else print("Not connected!")
> Maybe I'll add eci_last_bool()... not 100% sure yet. Anyway, this is the
> standard mechanism for querying information with ECI. Of course, we must
> add quite a few new ia-mode commands (observer funcs to be specific).
Ok. I was just wondering about from where to extract the information. Still not worried about the growing list of iam-commands?
-- To unsubscribe send message 'unsubscribe' in the body of the message to <email@example.com>.
This archive was generated by hypermail 2b28 : Fri Dec 01 2000 - 14:59:46 EET