Re: [ecasound] Plea for a new controller

From: Claude Heiland-Allen <claudiusmaximus@email-addr-hidden>
Date: Fri Apr 03 2009 - 01:08:12 EEST

Kai Vehmanen wrote:
> For example OSC could be used to reimplement NetECI. So in practise you
> could use the ECI API (as documented in ecasound-iam(1)) via OSC. But I'm
> not sure how useful this is as the OSC interface is totally
> ecasound-specific. Anyway, you'd have OSC messages like:
> a) "/ecasound/cop-add -el:stepMuxer,5.0"
> b) "/ecasound/cop-select", int:1
> c) "/ecasound/copp-select, int:1
> d) "/ecasound/copp-set, float:5.1234
> e) "/ecasound/start"
> A client would need to use OSC bundles to ensure atomic execution (e.g.
> actions (b)->(d) must be executed as an OSC bundle or otherwise you might
> end up changing params of something else than those of LADSPA 'stepMuxer'
> you just added).

Sounds horrible to me, but maybe that's just the ECI in general...

How about something more restful[1]:

a) /ecasound/cop-add /myStepMuxer stepMuxer 5.0
b) /myStepMuxer/param1 5.1234
c) /ecasound/start

Would that make sense? Would be a lot more work to implement I imagine...


> Maybe a similar approach for return values as taken in sooperlooper
> (specify the return-value message return address as a param, see below).

Seems sensible.

> Sorry for the long post, but this is interesting topic and I thought it's
> better just do a braindump here. :)

Take my opinions with a grain of salt, as I only use ecasound for simple
tasks like recording stereo from JACK and converting sound file formats :)


Ecasound-list mailing list
Received on Fri Apr 3 04:15:02 2009

This archive was generated by hypermail 2.1.8 : Fri Apr 03 2009 - 04:15:02 EEST