[OSC_dev] Application Profiles

[Gaspard Bucher]

A lot happened today, so let's clarify some things and post some more
questions...

1. just reply back to port from message header

Using the sender's port and IP from the UDP header is great in theory,
but in practice I could not make it work:

Impossible to define the output port of "udpsend" in Max/MSP (I
receive the data in rubyk at "50867", replies just get lost). I could
not create an "udpreceive" with port "50867" either (there is probably
something already bound to this port, says max).

All in all, we need at least a dictionary of "received from port" =>
"send to port". So "/reply_to 5005", is needed.

2. libosc limitations

We need to conform to OSC spec and make things easy to implement and
process. This means we need to avoid ambiguities and superfluous
parsing. We have two choices here.

a. use a special syntax for "meta" methods (get information, type, etc
= equivalent of ".h" files in C)

The existence of this special syntax should not make it too heavy to
process incoming messages. I propose Gabriel's idea of using
"/some/url(info)", because the trailing ")" is easy to detect and
means "hey osc processor, this is a special url". It also conforms to
OSC spec.

b. use special method names

This has the advantage of leaving the osc parser out of the "meta"
thing altogether, but it means you have to register all the "meta"
methods: /foo/bar/.info, /foo/bar/.type, etc.

I personally prefer the "special method names". I think it's more in
the spirit of urls.

3. HTML, REST inspiration: we lack the methods (POST, GET, PUT,
DELETE) so we have to hack around it. In the HTML world (from my
experience as a rails programmer), there is nothing like a common API.
If you want app1 to communicate with app2, you have to read the
documentation (equivalent of the ".h" files in C). This works because
you do not plug applications into each like we do with midi gear.

4. Finally some questions:

Why do we want to have some common ground to build on top of ?

My answer: I am building a very generic tool for multi media
programming (rubyk is an open source competitor to max/MSP) and I also
create shows with technology as an artist. What I would love to have
is:

a. you add some service on the network (a controller full of buttons
and sliders / a software like VLC / anything)
b. rubyk sees your new service because of zeroconf automatic service discovery
c. hey ! this thing conforms to some very minimal things rubyk understands
===>
d. I can present an osc browser of the new service to the rubyk user,
with help messages and such
e. the user can put a slider on the rubyk patcher and connect it to
the element in the browser
f. moving the slider, changes the value of the remote thing
g. when something else updates the remote thing, the slider in rubyk
moves as well

5. conclusion

Everyone is free to ignore this effort and the obvious benefit for the
end user. But if some of this succeeds, he/she will produce this
disappointing printer wich just doesn't want to work without the
burden of installing drivers in a world where all the rest just plays
together smoothly.

In order to produce the upper mentioned "browser", we need:

a. /reply_to
b. /some/url/  ==> trailing "/" = listing
c. /some/url   ==> get value
d. /some/url 4 ==> set value
e. /some/url/.info ==> human readable message
f. use zeroconf !

That's not such a deal and I'm ready to provide just the code for this
(with oscpack and zeroconf) in a simple to use package if there is a
need.

Gaspard