On Wednesday 26 January 2011 17:51:41 James Morris wrote:
It is relatively wide spread. However due to its nature, it neither defines=
standard way of detecting "remote" apps with osc interface, nor does it=20
provide a standard way to introspect. So for example a pair of apps that do=
gui->backend split will work because both written by the same author(s) kno=
how to detect and talk to each other. For apps written by different authors=
gets difficult. And its basically impossible to write any "generic osc send=
> For instance, could/should there be an OSC tab in QjackCTL?
If osc was a protocol that has a centralized distribution like jack does fo=
audio and midi and alsa-midi does for midi. But most osc usage happens over=
udp, that is network. That is fine to have gui and backend on different mac=
but completely incompatible with qjackctl providing a "central patchbay" (n=
that this concept would make any sense for osc).
In general it would be possible to send osc over jack-ports. Jack supports=
generic port types and osc isn't actually fixed on using udp. But the probl=
is: when app A sends osc across a jack-osc-connection, who guarantees that =
B can actually do something useful with it? osc just defines a way messages=
sent. It doesn't care about specific messages, it doesn't care about answer=
it doesn't care about the transport...
BTW: For entry into osc, python and its liblo-interface should give you a g=
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
-----END PGP SIGNATURE-----