Re: [ecasound] Plea for a new controller

On Fri, Apr 3, 2009 at 12:08 AM, Claude Heiland-Allen
<claudiusmaximus@goto10.org> wrote:
> 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...

I agree, this is much better than exposing any ECI syntax to OSC. Of
course, parameter names would still be mostly ecasound-specific (in
the absence of any real standards), but all in all this would improve
interoperability with other OSC software. And besides, it looks easier
and prettier.

>> 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.

It's also be possible to use the origin of the message as the default
return address. This is very easy to do with liblo, and might be a
convenient shortcut in many cases. It's not part of the OSC spec
though (it depends on the transport protocol being used), so a way to
explicitly specify an address would still be required.

The bigger problem with return values is the fact that OSC messages
are always transmitted asynchronously, so there's no (easy) way for a
client to wait until a command has completed. There are ways to work
around this, but it can get ugly very quickly. In any case that's
something a client would need to handle (when required), there's
basically nothing ecasound could do about it.

Dominic

------------------------------------------------------------------------------
_______________________________________________
Ecasound-list mailing list
Ecasound-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Received on Fri Apr 3 12:15:02 2009