Re: [ecasound] Plea for a new controller

Hi,

[ there is also a tracker item for OSC support at:
   https://sourceforge.net/tracker/index.php?func=detail&aid=2541462&group_id=4605&atid=104605 ]

On Thu, 2 Apr 2009, Julien Claassen wrote:

> What do you know of OSC? Do you use it? Use it often? Would it be a

btw, I've found these to be good intros:

- Dave Phillips: An Introduction To OSC
   http://www.linuxjournal.com/content/introduction-osc
- http://en.wikipedia.org/wiki/OpenSound_Control
- The main site
   http://opensoundcontrol.org/
- liblo - the implemented I'd probably use for ecasound:
   http://liblo.sourceforge.net

> I was thinking, that it might be nice to have an OSC controller in Ecasound.
> I know a couple of software pieces, that use OSC and I know people, who do
> great things with it.

I've thought about this many times, but so far without concrete actions.
To my understanding, OSC is basicly a compact IPC/RPC mechanism and to me
it is very close to DBus (fairly small spec, bindings to almost every
language, easy to call/emit methods/signals from scripts, etc). Of course,
OSC has more support for audio/music apps, and has some useful audio/music
specific features (like defining transport for MIDI commands in the main
OSC spec). Also of interest is that DBus uses a reliable transport
(TCP/IP), while OSC uses primarily UDP (packet loss possible, but suits
better for real-time messages passing and multicasting).

Now Dbus-vs-OSC-for-audio is not that interesting topic (once you've
implemented one, adding support for the other is very straighforward).
A more difficult question is what functionality to expose via the IPC (be
it OSC or DBus), and which interface spec to use (do your own, or reuse
some existing spec).

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). Also return values would need to be implemented somehow
(or just ignored, although that hurts usefulness of the API quite a bit).
Maybe a similar approach for return values as taken in sooperlooper
(specify the return-value message return address as a param, see below).

We could also implement some other existing interface - here's for example
what has been defined in ardour:

http://viewcvs.ardour.org/index.cgi/ardour2/ardour2/branches/2.0-ongoing/libs/ardour/osc.cc?revision=4889&view=markup
--cut--
                 REGISTER_CALLBACK (serv, "/ardour/add_marker", "",
add_marker);
                 REGISTER_CALLBACK (serv, "/ardour/access_action", "s",
access_action);
                 REGISTER_CALLBACK (serv, "/ardour/loop_toggle", "",
loop_toggle);
                 REGISTER_CALLBACK (serv, "/ardour/goto_start", "",
goto_start);
...
--cut--

But that's of course ardour specific, so wouldn't be so useful (all OSC
clients would have to be modified to support ecasound as mapping the
methods 1:1 is probably not possible as the apps have different designs).
Exposing the ECI is probably both easier to implement as well more
intuitive for the client developer (as the API matches with how ecasound
works).

Sooperlooper also has a pretty rich (but specific to it) OSC
interface:
   - http://www.essej.net/sooperlooper/doc_osc.html

Then there's some other, a bit more general OSC interfaces ecasound
could in theory implement:
   - the DSSI one:
     http://dssi.sourceforge.net/RFC.html
   - SYN interface (for synths):
     http://stud3.tuwien.ac.at/~e0725639/OSC-SYN.txt

A maybe more useful approach would be to specify OSC interfaces for
more specific controls:
   - parameter control (like -km)
   - transport control (start, stop, locate, ...)

... but again you have the problem of what type of OSC interface
to implement for the above. It would seem easiest to just transport MIDI
messages over OSC (and for that you can already use ALSA sequencer API).
But maybe still worthwhile.

So as a summary, I'm interested in adding OSC support, but currently I
don't really have a good idea about which approach would make most sense.

> Why was I thinking of it: It's about a mastering setup, which of course has
> a lot of effects and thus a lot of parameters. So you could realtime control
> them the easy way with MIDI (fine with me) or with OSC. I thought OSC might be
> nice for those, who don't have MIDI gear. I don't know there were a couple of
> OSC tools around and with a GUI and libosc it looks simple to me to create an
> app, that could map mouse movement to OSC controller. I didn't write anything

But basicly you can do this already quite easily with the ECI python API:
make a python application that gets events from various sensors and input
devices, and convert those into ECI commands (which can control transport,
modify parameter values, basicly anything). If you want to control a
remote ecasound instance, you can use NetECI (see
ecasound/tools/ecamonitor which is a python app).

I do agree that if you want the same client application to control other
target apps as well, being able to use OSC to control ecasound as well,
would be certainly beneficial. You'd still need to learn the specific OSC
API ecasound exposes, but an improvement still I guess.

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

------------------------------------------------------------------------------
_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Received on Fri Apr 3 04:15:01 2009