Re: [ecasound] Plea for a new controller

Hi,

On Thu, 2 Apr 2009, Claude Heiland-Allen wrote:

>> For example OSC could be used to reimplement NetECI. So in practise you
[...]
>> b) "/ecasound/cop-select", int:1
>> c) "/ecasound/copp-select, int:1
>> d) "/ecasound/copp-set, float:5.1234
>
> Sounds horrible to me, but maybe that's just the ECI in general...
[...]
> How about something more restful[1]:

agreed, mixing iterators with restful style interfaces is probably
an idea best forgotten.

OTOH, avoiding use of iterators altogether, is not easy as they are used a
lot in ecasound. Use of container abstractions (chainsetups and chains),
and lack of user-visible instance ids for objects (e.g. if you have
multiple active LADSPA stepMuxer plugins, a specific instance can
be only identified via the containers) are the primary reasons for the
wide use of iterators.

Although you could expose the current namespace in "restful" style, it
wouldn't be very nice to use. The design limitations force us to specify
the full paths for any resource. So that paths would grow to something
like:

/ecasound/my-chainsetup/my-chain/op/1/param/2 5.1234

You could optimize a bit:

/ecasound/my-chainsetup/my-chain/1/2 5.1234

... but that's even more cryptic. This is still doable though, but quite a
bit of work still. One easier way to get started would be to use the above
syntax and only implement support for the "real-time" subset of ECI
commands (see ecasound-iam(1) and its section 'Real-time commands').

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

Yes, these would fit the OSC world much better, but as you noted,
implementing these would require major changes to ecasound internals --
and most probably is not worth the effort. Few specific notes:

   - (a) is not complete, you have to provide a lot more info
     when adding a chain operator (which chainsetup, which chain)
   - (b) being able to attach names to operator instances is a new
     feature and would require changes all over the codebase

Btw, I'm now looking at this purely from current implementation point of
view. If I would be starting from scratch, then that's a different thing.
There are quite a few things I would do different in that case. ;)

> 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 :)

No, no - there's no use-case based discrimination here! ;)

------------------------------------------------------------------------------
_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Received on Sat Apr 4 20:15:02 2009