unknown
1970-01-01 00:00:00 UTC
<div><br></div><div>I think it should not be called a "protocol for co=
mmunication among computers, sound synthesizers and other multimedia device=
s" but a "protocol for <b>simple one-way control</b>=A0among comp=
uters, sound synthesizers and other multimedia devices".<br>
</div><div><br></div><div>Once this is clarified, we stop wanting to bend O=
SC to do things it should not do.</div><div><br></div><div>For high level i=
nter-node communication I am using ZeroMQ with Msgpack and it is true that =
there is some complexity overhead with asynchronous bi-directional communic=
ation and we probably do not want to have this in a keyboard or continuum c=
ontroller.</div>
<div><br></div><div>As for a query protocol, I think returning JSON or YAML=
with a full description of services would solve all my auto-querying needs=
.</div><div><br></div><div><font face=3D"courier new, monospace"><b>query</=
b>: /__osc/features "</font><b style=3D"font-family:'courier new&#=
39;,monospace">device id"</b><span style=3D"font-family:'courier n=
ew',monospace">=A0</span><span style=3D"font-family:'courier new=
9;,monospace">"some.ip.for.reply" [port]</span></div>
<div><font face=3D"courier new, monospace"><b>reply</b>: /__osc/reply =A0 =
=A0</font><span style=3D"font-family:'courier new',monospace">"=
;</span><b style=3D"font-family:'courier new',monospace">device id<=
/b><span style=3D"font-family:'courier new',monospace">"=A0</s=
pan><span style=3D"font-family:'courier new',monospace">"/feat=
ures"</span><span style=3D"font-family:'courier new',monospace=
">=A0JSON</span></div>
<div><br></div><div>We cannot and should not use device IP for identificati=
on of reply, hence the <b>device id=A0</b>(representing the <b>queried devi=
ce from the sender's view</b>). For example, if osculator wanted to kno=
w what my image processing script has for control, it would first need to s=
ee me on the network (use Zeroconf or human configuration), give me an inte=
rnal name like "dev01" and then:</div>
<div><br></div><div><font face=3D"courier new, monospace"><b>osculator --&g=
t; lubyk:</b>=A0/__osc/features=A0</font><span style=3D"font-family:'co=
urier new',monospace">"dev01"</span><span style=3D"font-famil=
y:'courier new',monospace">=A0"10.0.1.1" 7014</span></div= <div><font face=3D"courier new, monospace"><b>lubyk --> osculator:</b>=
=A0/__osc/reply =A0 =A0</font><span style=3D"font-family:'courier new&#=
39;,monospace">"dev01"=A0</span><span style=3D"font-family:'c=
ourier new',monospace">"/features" JSON</span></div>
<div><br></div><div>Note that the reply is a single OSC address for all rep=
lies with the device id and queried url.</div><div><br></div><div>Cheers,</=
div><div><br></div><div>Gaspard</div></div><div class=3D"gmail_extra"><div>
<div class=3D"h5"><br>
<br><div class=3D"gmail_quote">On Tue, Feb 4, 2014 at 3:27 AM, Adrian Freed=
<span dir=3D"ltr"><<a href=3D"mailto:***@cnmat.berkeley.edu" target=
=3D"_blank">***@cnmat.berkeley.edu</a>></span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">
Ahh, if only we were gods at CNMAT.<br>
We are actually relatively poor, pragmatists and we haven't built much =
around here<br>
that uses the query/reply design pattern. Personally speaking it rubs again=
st my reflex of using stateless protocols.<br>
That said I have never discouraged that sort of work for which OSC is a rea=
sonable encoding.<br>
I have seen several usable implementations of the pattern - at the Topologi=
cal Media Lab., for example.<br>
<br>
One of the more common uses of query/reply is device and service enumeratio=
n (sometimes called "discovery"). We<br>
will soon publish some code that does this in an interesting way for Blueto=
oth LE. It doesn't require changes to OSC and uses<br>
coroutines to avoid the complexities that often arise with query/reply stat=
e machines.<br>
<div><div><br>
<br>
<br>
On Feb 3, 2014, at 1:14 PM, Gaspard Bucher <<a href=3D"mailto:***@te=
ti.ch" target=3D"_blank">***@teti.ch</a>> wrote:<br>
<br>
> A couple of people around osc_dev worked on implementing such an async=
hronous query/reply system back in 2009:<br>
><br>
> <a href=3D"http://lubyk.org/en/software/oscit" target=3D"_blank">http:=
//lubyk.org/en/software/oscit</a><br>
><br>
> [rant]<br>
> The thing worked fine but for a proper query/reply system to work, I h=
ad to implement more structure in replies and have been proposing to use Ha=
sh and List arguments in OSC for ages. I have a slightly modified oscpack v=
ersion that supports nested dictionaries and arbitrary lists. It's ligh=
tweight, fast, but it never got any traction from CNMAT (the gods of OSC) s=
o it's dead.<br>
> [/rant]<br>
><br>
> Whatever you do while designing such a system, my 2c would be to creat=
e real world use cases and implement them with different protocol ideas. It=
's very surprising how some solutions are *very* hard to implement and =
slight modifications become quite easy.<br>
><br>
> Gaspard<br>
><br>
><br>
><br>
> On Fri, Jan 31, 2014 at 2:58 PM, Ray Cutler <<a href=3D"mailto:ray@=
vidvox.net" target=3D"_blank">***@vidvox.net</a>> wrote:<br>
> Howdy-<br>
><br>
> "How does your effort relate to <a href=3D"http://opensoundcontro=
l.org/files/osc-query-system.pdf" target=3D"_blank">http://opensoundcontrol=
.org/files/osc-query-system.pdf</a> ?"<br>
><br>
> That's the doc that got me interested in this stuff, and the first=
link in the proposal! =A0Right now it's somewhere between the Schmeder=
/Wright pdf you linked to and OSNIP, which (as you noted) serves a similar =
purpose through slightly different means. =A0If you have preferences one wa=
y or the other please stop by and let us know- either open a new issue, or =
weigh in on some of the open ones. =A0This is definitely still very much op=
en for discussion!<br>
><br>
><br>
> cheers<br>
> : : ray<br>
><br>
><br>
> _______________________________________________<br>
> OSC_dev mailing list<br>
> <a href=3D"mailto:***@create.ucsb.edu" target=3D"_blank">***@c=
reate.ucsb.edu</a><br>
> <a href=3D"http://lists.create.ucsb.edu/mailman/listinfo/osc_dev" targ=
et=3D"_blank">http://lists.create.ucsb.edu/mailman/listinfo/osc_dev</a><br>
><br>
><br>
><br>
><br>
> --<br>
><br>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Gaspard<br>
> _______________________________________________<br>
> OSC_dev mailing list<br>
> <a href=3D"mailto:***@create.ucsb.edu" target=3D"_blank">***@c=
reate.ucsb.edu</a><br>
> <a href=3D"http://lists.create.ucsb.edu/mailman/listinfo/osc_dev" targ=
et=3D"_blank">http://lists.create.ucsb.edu/mailman/listinfo/osc_dev</a><br>
<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div></div><=
/div><span class=3D"HOEnZb"><font color=3D"#888888">-- <br><br><div>=A0=A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gaspard</div>
</font></span></div>
<br>_______________________________________________<br>
OSC_dev mailing list<br>
<a href=3D"mailto:***@create.ucsb.edu">***@create.ucsb.edu</a><br>
<a href=3D"http://lists.create.ucsb.edu/mailman/listinfo/osc_dev" target=3D=
"_blank">http://lists.create.ucsb.edu/mailman/listinfo/osc_dev</a><br>
<br></blockquote></div><br></div>
--047d7b3432be02760604f1c07351--
mmunication among computers, sound synthesizers and other multimedia device=
s" but a "protocol for <b>simple one-way control</b>=A0among comp=
uters, sound synthesizers and other multimedia devices".<br>
</div><div><br></div><div>Once this is clarified, we stop wanting to bend O=
SC to do things it should not do.</div><div><br></div><div>For high level i=
nter-node communication I am using ZeroMQ with Msgpack and it is true that =
there is some complexity overhead with asynchronous bi-directional communic=
ation and we probably do not want to have this in a keyboard or continuum c=
ontroller.</div>
<div><br></div><div>As for a query protocol, I think returning JSON or YAML=
with a full description of services would solve all my auto-querying needs=
.</div><div><br></div><div><font face=3D"courier new, monospace"><b>query</=
b>: /__osc/features "</font><b style=3D"font-family:'courier new&#=
39;,monospace">device id"</b><span style=3D"font-family:'courier n=
ew',monospace">=A0</span><span style=3D"font-family:'courier new=
9;,monospace">"some.ip.for.reply" [port]</span></div>
<div><font face=3D"courier new, monospace"><b>reply</b>: /__osc/reply =A0 =
=A0</font><span style=3D"font-family:'courier new',monospace">"=
;</span><b style=3D"font-family:'courier new',monospace">device id<=
/b><span style=3D"font-family:'courier new',monospace">"=A0</s=
pan><span style=3D"font-family:'courier new',monospace">"/feat=
ures"</span><span style=3D"font-family:'courier new',monospace=
">=A0JSON</span></div>
<div><br></div><div>We cannot and should not use device IP for identificati=
on of reply, hence the <b>device id=A0</b>(representing the <b>queried devi=
ce from the sender's view</b>). For example, if osculator wanted to kno=
w what my image processing script has for control, it would first need to s=
ee me on the network (use Zeroconf or human configuration), give me an inte=
rnal name like "dev01" and then:</div>
<div><br></div><div><font face=3D"courier new, monospace"><b>osculator --&g=
t; lubyk:</b>=A0/__osc/features=A0</font><span style=3D"font-family:'co=
urier new',monospace">"dev01"</span><span style=3D"font-famil=
y:'courier new',monospace">=A0"10.0.1.1" 7014</span></div= <div><font face=3D"courier new, monospace"><b>lubyk --> osculator:</b>=
=A0/__osc/reply =A0 =A0</font><span style=3D"font-family:'courier new&#=
39;,monospace">"dev01"=A0</span><span style=3D"font-family:'c=
ourier new',monospace">"/features" JSON</span></div>
<div><br></div><div>Note that the reply is a single OSC address for all rep=
lies with the device id and queried url.</div><div><br></div><div>Cheers,</=
div><div><br></div><div>Gaspard</div></div><div class=3D"gmail_extra"><div>
<div class=3D"h5"><br>
<br><div class=3D"gmail_quote">On Tue, Feb 4, 2014 at 3:27 AM, Adrian Freed=
<span dir=3D"ltr"><<a href=3D"mailto:***@cnmat.berkeley.edu" target=
=3D"_blank">***@cnmat.berkeley.edu</a>></span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">
Ahh, if only we were gods at CNMAT.<br>
We are actually relatively poor, pragmatists and we haven't built much =
around here<br>
that uses the query/reply design pattern. Personally speaking it rubs again=
st my reflex of using stateless protocols.<br>
That said I have never discouraged that sort of work for which OSC is a rea=
sonable encoding.<br>
I have seen several usable implementations of the pattern - at the Topologi=
cal Media Lab., for example.<br>
<br>
One of the more common uses of query/reply is device and service enumeratio=
n (sometimes called "discovery"). We<br>
will soon publish some code that does this in an interesting way for Blueto=
oth LE. It doesn't require changes to OSC and uses<br>
coroutines to avoid the complexities that often arise with query/reply stat=
e machines.<br>
<div><div><br>
<br>
<br>
On Feb 3, 2014, at 1:14 PM, Gaspard Bucher <<a href=3D"mailto:***@te=
ti.ch" target=3D"_blank">***@teti.ch</a>> wrote:<br>
<br>
> A couple of people around osc_dev worked on implementing such an async=
hronous query/reply system back in 2009:<br>
><br>
> <a href=3D"http://lubyk.org/en/software/oscit" target=3D"_blank">http:=
//lubyk.org/en/software/oscit</a><br>
><br>
> [rant]<br>
> The thing worked fine but for a proper query/reply system to work, I h=
ad to implement more structure in replies and have been proposing to use Ha=
sh and List arguments in OSC for ages. I have a slightly modified oscpack v=
ersion that supports nested dictionaries and arbitrary lists. It's ligh=
tweight, fast, but it never got any traction from CNMAT (the gods of OSC) s=
o it's dead.<br>
> [/rant]<br>
><br>
> Whatever you do while designing such a system, my 2c would be to creat=
e real world use cases and implement them with different protocol ideas. It=
's very surprising how some solutions are *very* hard to implement and =
slight modifications become quite easy.<br>
><br>
> Gaspard<br>
><br>
><br>
><br>
> On Fri, Jan 31, 2014 at 2:58 PM, Ray Cutler <<a href=3D"mailto:ray@=
vidvox.net" target=3D"_blank">***@vidvox.net</a>> wrote:<br>
> Howdy-<br>
><br>
> "How does your effort relate to <a href=3D"http://opensoundcontro=
l.org/files/osc-query-system.pdf" target=3D"_blank">http://opensoundcontrol=
.org/files/osc-query-system.pdf</a> ?"<br>
><br>
> That's the doc that got me interested in this stuff, and the first=
link in the proposal! =A0Right now it's somewhere between the Schmeder=
/Wright pdf you linked to and OSNIP, which (as you noted) serves a similar =
purpose through slightly different means. =A0If you have preferences one wa=
y or the other please stop by and let us know- either open a new issue, or =
weigh in on some of the open ones. =A0This is definitely still very much op=
en for discussion!<br>
><br>
><br>
> cheers<br>
> : : ray<br>
><br>
><br>
> _______________________________________________<br>
> OSC_dev mailing list<br>
> <a href=3D"mailto:***@create.ucsb.edu" target=3D"_blank">***@c=
reate.ucsb.edu</a><br>
> <a href=3D"http://lists.create.ucsb.edu/mailman/listinfo/osc_dev" targ=
et=3D"_blank">http://lists.create.ucsb.edu/mailman/listinfo/osc_dev</a><br>
><br>
><br>
><br>
><br>
> --<br>
><br>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Gaspard<br>
> _______________________________________________<br>
> OSC_dev mailing list<br>
> <a href=3D"mailto:***@create.ucsb.edu" target=3D"_blank">***@c=
reate.ucsb.edu</a><br>
> <a href=3D"http://lists.create.ucsb.edu/mailman/listinfo/osc_dev" targ=
et=3D"_blank">http://lists.create.ucsb.edu/mailman/listinfo/osc_dev</a><br>
<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div></div><=
/div><span class=3D"HOEnZb"><font color=3D"#888888">-- <br><br><div>=A0=A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gaspard</div>
</font></span></div>
<br>_______________________________________________<br>
OSC_dev mailing list<br>
<a href=3D"mailto:***@create.ucsb.edu">***@create.ucsb.edu</a><br>
<a href=3D"http://lists.create.ucsb.edu/mailman/listinfo/osc_dev" target=3D=
"_blank">http://lists.create.ucsb.edu/mailman/listinfo/osc_dev</a><br>
<br></blockquote></div><br></div>
--047d7b3432be02760604f1c07351--