unknown
1970-01-01 00:00:00 UTC
I think it should not be called a "protocol for communication among
computers, sound synthesizers and other multimedia devices" but a "protocol
for *simple one-way control* among computers, sound synthesizers and other
multimedia devices".
Once this is clarified, we stop wanting to bend OSC to do things it should
not do.
For high level inter-node communication I am using ZeroMQ with Msgpack and
it is true that there is some complexity overhead with asynchronous
bi-directional communication and we probably do not want to have this in a
keyboard or continuum controller.
As for a query protocol, I think returning JSON or YAML with a full
description of services would solve all my auto-querying needs.
*query*: /__osc/features "*device id"* "some.ip.for.reply" [port]
*reply*: /__osc/reply "*device id*" "/features" JSON
We cannot and should not use device IP for identification of reply, hence
the *device id *(representing the *queried device from the sender's view*).
For example, if osculator wanted to know what my image processing script
has for control, it would first need to see me on the network (use Zeroconf
or human configuration), give me an internal name like "dev01" and then:
*osculator --> lubyk:* /__osc/features "dev01" "10.0.1.1" 7014
*lubyk --> osculator:* /__osc/reply "dev01" "/features" JSON
Note that the reply is a single OSC address for all replies with the device
id and queried url.
Cheers,
Gaspard
computers, sound synthesizers and other multimedia devices" but a "protocol
for *simple one-way control* among computers, sound synthesizers and other
multimedia devices".
Once this is clarified, we stop wanting to bend OSC to do things it should
not do.
For high level inter-node communication I am using ZeroMQ with Msgpack and
it is true that there is some complexity overhead with asynchronous
bi-directional communication and we probably do not want to have this in a
keyboard or continuum controller.
As for a query protocol, I think returning JSON or YAML with a full
description of services would solve all my auto-querying needs.
*query*: /__osc/features "*device id"* "some.ip.for.reply" [port]
*reply*: /__osc/reply "*device id*" "/features" JSON
We cannot and should not use device IP for identification of reply, hence
the *device id *(representing the *queried device from the sender's view*).
For example, if osculator wanted to know what my image processing script
has for control, it would first need to see me on the network (use Zeroconf
or human configuration), give me an internal name like "dev01" and then:
*osculator --> lubyk:* /__osc/features "dev01" "10.0.1.1" 7014
*lubyk --> osculator:* /__osc/reply "dev01" "/features" JSON
Note that the reply is a single OSC address for all replies with the device
id and queried url.
Cheers,
Gaspard
Ahh, if only we were gods at CNMAT.
We are actually relatively poor, pragmatists and we haven't built much
around here
that uses the query/reply design pattern. Personally speaking it rubs
against my reflex of using stateless protocols.
That said I have never discouraged that sort of work for which OSC is a
reasonable encoding.
I have seen several usable implementations of the pattern - at the
Topological Media Lab., for example.
One of the more common uses of query/reply is device and service
enumeration (sometimes called "discovery"). We
will soon publish some code that does this in an interesting way for
Bluetooth LE. It doesn't require changes to OSC and uses
coroutines to avoid the complexities that often arise with query/reply
state machines.
and List arguments in OSC for ages. I have a slightly modified oscpack
version that supports nested dictionaries and arbitrary lists. It's
lightweight, fast, but it never got any traction from CNMAT (the gods of
OSC) so it's dead.
very surprising how some solutions are *very* hard to implement and slight
modifications become quite easy.
you linked to and OSNIP, which (as you noted) serves a similar purpose
through slightly different means. If you have preferences one way or the
other please stop by and let us know- either open a new issue, or weigh in
on some of the open ones. This is definitely still very much open for
discussion!
We are actually relatively poor, pragmatists and we haven't built much
around here
that uses the query/reply design pattern. Personally speaking it rubs
against my reflex of using stateless protocols.
That said I have never discouraged that sort of work for which OSC is a
reasonable encoding.
I have seen several usable implementations of the pattern - at the
Topological Media Lab., for example.
One of the more common uses of query/reply is device and service
enumeration (sometimes called "discovery"). We
will soon publish some code that does this in an interesting way for
Bluetooth LE. It doesn't require changes to OSC and uses
coroutines to avoid the complexities that often arise with query/reply
state machines.
A couple of people around osc_dev worked on implementing such an
http://lubyk.org/en/software/oscit
[rant]
The thing worked fine but for a proper query/reply system to work, I had
to implement more structure in replies and have been proposing to use Hashhttp://lubyk.org/en/software/oscit
[rant]
The thing worked fine but for a proper query/reply system to work, I had
and List arguments in OSC for ages. I have a slightly modified oscpack
version that supports nested dictionaries and arbitrary lists. It's
lightweight, fast, but it never got any traction from CNMAT (the gods of
OSC) so it's dead.
[/rant]
Whatever you do while designing such a system, my 2c would be to create
real world use cases and implement them with different protocol ideas. It'sWhatever you do while designing such a system, my 2c would be to create
very surprising how some solutions are *very* hard to implement and slight
modifications become quite easy.
Gaspard
Howdy-
"How does your effort relate to
http://opensoundcontrol.org/files/osc-query-system.pdf ?"Howdy-
"How does your effort relate to
That's the doc that got me interested in this stuff, and the first link
in the proposal! Right now it's somewhere between the Schmeder/Wright pdfyou linked to and OSNIP, which (as you noted) serves a similar purpose
through slightly different means. If you have preferences one way or the
other please stop by and let us know- either open a new issue, or weigh in
on some of the open ones. This is definitely still very much open for
discussion!
cheers
: : ray
_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
--
Gaspard
_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
: : ray
_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
--
Gaspard
_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
--
Gaspard
--20cf303a2dcd9d19b904f18f698e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir="ltr">Sorry for the rant. I should have stated things differently.<div><br></div><div>There are many limitations in the design and implementations of OSC that make it a bad choice for high level command and control operations.
Gaspard
--20cf303a2dcd9d19b904f18f698e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir="ltr">Sorry for the rant. I should have stated things differently.<div><br></div><div>There are many limitations in the design and implementations of OSC that make it a bad choice for high level command and control operations.