Re: [ecasound] Plea for a new controller

Hi,

On Fri, 3 Apr 2009, Julien Claassen wrote:

> fine with me. It's just like km being able to realtime-change a parameter of
> an effect. So you might have something like:
> ecasound -i in.wav -o rt_out -efl:8000 -ko:1,400,10000,whatever_necessary
> Then use your GUI OSC app and your mouse of graphic tablet or what not to
> draw a curve representation of the value's change.

I think this is a clear case that is both implementable (with a reasonable
effort) and useful.

The only thing that I'm worried about is the fact that OSC does not define
standard profiles e.g. for parameter and transport control. Because of
this, you will always need some potential "glue code" to be able to
connect two OSC-supporting apps. I'm not familiar enough with OSC to
really understand how big of a limitation this in practise (-> how useful
the OSC interface will be, and what would make it more useful).

To make this a bit more concrete, a good example from
http://opensoundcontrol.org is Tjshow. If you'd want to use Tjshow to
control ecasound, the end-user has to type in the full path names and
argument types to the configuration GUI:

   http://opensoundcontrol.org/implementation/tjshow-show-controller-software

So knowing this, the interface should be as simple and as intuitive as
possible. But still, some ecasound-specific "glue" needs to be defined.

If we compare to MIDI, one "only" needs to set the MIDI channel and
controller numbers and these are standardized. But that's just an example
(I'm definitely not arguing that because of MIDI, OSC is not needed).

Now I might be very wrong on this, but my understanding is that OSC is
currently used mostly by people who don't mind the amount of patchwork and
details that e.g. use of Tjshow requires. You don't need to be a
programmer, but the experience is not really plug'n'play either. I think
this is a key piece of information in order to design a sane OSC interface
for ecasound. So we should not oversimplify either.

Btw, in this light, I think exposing ECI over OSC is wrong specifically as
it is too low-level, and because it would need more non-trivial "glue
code" to be written (e.g. Tjshow supports sending arbitrary messages,
but it does not seem to support sending OSC messages in bundles).

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Received on Tue Apr 7 04:15:02 2009