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...
[1] http://en.wikipedia.org/wiki/Restful#Example
> 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 :)
Claude
-- http://claudiusmaximus.goto10.org ------------------------------------------------------------------------------ _______________________________________________ Ecasound-list mailing list Ecasound-list@email-addr-hidden https://lists.sourceforge.net/lists/listinfo/ecasound-listReceived 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