23 Sep
2007
23 Sep
'07
5:54 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Does OSC support "reflection"? i.e., is there any way in OSC to interrogate a
device and get back a list of all available parameters that the device supports?
I remember someone posting a complete listing of all the OSC parameters that WhySynth
supports, but I can't seem to find it now, or how they discovered it.
Thanks.
- -ken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFG9sQxe8HF+6xeOIcRAnfCAJ47La86zeU8RsSLbp05jvNUU+zJHwCg254s
FMZ9TFNZ5Nb42g3kQBuIFlw=
=y2/O
-----END PGP SIGNATURE-----
23 Sep
23 Sep
6:02 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, Sep 23, 2007 at 12:53:21PM -0700, Ken Restivo wrote:
Does OSC support "reflection"? i.e., is
there any way in OSC to interrogate a device and get back a list of all available
parameters that the device supports?
I remember someone posting a complete listing of all the OSC parameters that WhySynth
supports, but I can't seem to find it now, or how they discovered it.
Digging around more, I found a post to LAU that described how to interrogate DSSI plugins
using "analyseplugin" and using the [dssi~] external for PD.
Nothing for OSC yet, however.
- -ken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFG9sYMe8HF+6xeOIcRAq6hAJ4x0mvafTUzgFcRP9RsjzjJ81monQCgySaf
Ldl9wXSDW+axp4Ydetl1u7s=
=29iy
-----END PGP SIGNATURE-----
6:39 p.m.
On Sun, 2007-09-23 at 13:01 -0700, Ken Restivo wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, Sep 23, 2007 at 12:53:21PM -0700, Ken Restivo wrote:
Digging around more, I found a post to LAU that described how to
interrogate DSSI plugins using "analyseplugin" and using the [dssi~]
external for PD.
Nothing for OSC yet, however.
There are some proposals for and implementations of OSC introspection,
for example http://liboscqs.sourceforge.net/ . Not many OSC programs
support them.
--ll
Does OSC support "reflection"? i.e., is
there any way in OSC to
interrogate a device and get back a list of all available
parameters
that the device supports?
I remember someone posting a complete listing of all the OSC
parameters that
WhySynth supports, but I can't seem to find it now, or
how they discovered it.
6:36 p.m.
Am Sonntag, 23. September 2007 schrieb Ken Restivo:
Does OSC support "reflection"? i.e., is
there any way in OSC to interrogate
a device and get back a list of all available parameters that the device
supports?
OSC is connectionless, at least if the implementation uses udp as the
transport-protocol (which most do). So there is no real way to even return
values. Most apps send return-values to the host/port the query came from,
but if that fails or is not handled (as the current state of ofqf...),
nothing really happens.
Thats already quite a problem, introspection/interrogation is totally up to
the dev writing the app you want to control.
I would propose some basic "/introspect" to send back some kind of textual
representation of the tree of options that is handled by the app. But its up
to every programmer to implement this. And then we still have to negotiate on
a format for the answer... (/me is voting for some xml: <path
name="bla"><path name="first" ><argument
type="int" /><argument
type="string" /></path></path> :)
Have a nice week,
Arnold
--
visit http://www.arnoldarts.de/
---
Hi, I am a .signature virus. Please copy me into your ~/.signature and send me
to all your contacts.
After a month or so log in as root and do a rm / -rf. Or ask your
administrator to do so...
6:49 p.m.
On Sun, 2007-09-23 at 22:36 +0200, Arnold Krille wrote:
Am Sonntag, 23. September 2007 schrieb Ken Restivo:
D-Bus does this - it is basically OSC + better RPC structures +
introspection + a bus daemon for discovery. All D-Bus objects (are
supposed to) implement the Introspect method, which returns an XML
representation of that object with all its interfaces, methods, signals,
properties and child objects.
But I've never understood why they use XML-in-a-string for that when
they already have a nice message format.
--ll
Does OSC support "reflection"? i.e., is
there any way in OSC to interrogate
a device and get back a list of all available parameters that the device
supports?
OSC is connectionless, at least if the implementation uses udp as the
transport-protocol (which most do). So there is no real way to even return
values. Most apps send return-values to the host/port the query came from,
but if that fails or is not handled (as the current state of ofqf...),
nothing really happens.
Thats already quite a problem, introspection/interrogation is totally up to
the dev writing the app you want to control.
I would propose some basic "/introspect" to send back some kind of textual
representation of the tree of options that is handled by the app. But its up
to every programmer to implement this. And then we still have to negotiate on
a format for the answer... (/me is voting for some xml: <path
name="bla"><path name="first" ><argument
type="int" /><argument
type="string" /></path></path> :) 
9:32 p.m.
söndag 23 september 2007 22:36 skrev Arnold Krille:
Am Sonntag, 23. September 2007 schrieb Ken Restivo:
If OSC ain't waiting for return packets it's not UDP:s fault. You specify
destination _and_ source port in UDP just like in TCP. Ergo. You state your
port that you are going to receive on. So. There's a real way to return
traffic.
/bengan
Does OSC support "reflection"? i.e., is
there any way in OSC to
interrogate a device and get back a list of all available parameters that
the device supports?
OSC is connectionless, at least if the implementation uses udp as the
transport-protocol (which most do). So there is no real way to even return
values. Most apps send return-values to the host/port the query came from,
but if that fails or is not handled (as the current state of ofqf...),
nothing really happens.
9:48 p.m.
On Mon, 2007-09-24 at 01:29 +0200, Bengt Gördén wrote:
söndag 23 september 2007 22:36 skrev Arnold Krille:
But not a reliable way if you are using UDP.
--ll
Am Sonntag, 23. September 2007 schrieb Ken
Restivo:
If OSC ain't waiting for return packets it's not UDP:s fault. You specify
destination _and_ source port in UDP just like in TCP. Ergo. You state your
port that you are going to receive on. So. There's a real way to return
traffic. Does OSC support "reflection"? i.e., is
there any way in OSC to
interrogate a device and get back a list of all available parameters that
the device supports?
OSC is connectionless, at least if the implementation uses udp as the
transport-protocol (which most do). So there is no real way to even return
values. Most apps send return-values to the host/port the query came from,
but if that fails or is not handled (as the current state of ofqf...),
nothing really happens.
24 Sep
24 Sep
4:24 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, Sep 24, 2007 at 01:46:48AM +0200, Lars Luthman wrote:
On Mon, 2007-09-24 at 01:29 +0200, Bengt G??rd??n
wrote:
My NFS server seems to do just fine with UDP. I send it requests, I get back blocks of a
file. I send it blocks of a file, I get back confirmations that they were written to disk.
It's plenty reliable because it's over a local 100Mbps Ethernet connection. The
higher layers of the protocol implement the connection state.
Presumably OSC connections are over media at least as fast. I'd suppose that in 99% of
cases that connection is to localhost from localhost-- not even a wire in the way. I fail
to understand why OSC connections over UDP is a problem unless it is connecting to a OSC
client across the world, in which case I'd have to agree that UDP wouldn't be the
best choice.
Anyway, thanks for all the info on OSC. I was going to try to create a shim that would
enable me to control flexibly a ton of WhySynth parameters via MIDI, but it may be easier
to do that in PD using the dssi~ external.
By the way, looking through my notes, it seems I discovered several months ago a way to
determine which OSC parameters are available: it's called "tcpdump -vnl -i
lo", and then twiddle knobs and buttons on the DSSI synth's GUI.
*hack* cough *hack*
- -ken
s??ndag 23 september 2007 22:36 skrev Arnold
Krille:
But not a reliable way if you are using UDP.
Am Sonntag, 23. September 2007 schrieb Ken
Restivo:
If OSC ain't waiting for return packets it's not UDP:s fault. You specify
destination _and_ source port in UDP just like in TCP. Ergo. You state your
port that you are going to receive on. So. There's a real way to return
traffic. Does OSC support "reflection"? i.e., is
there any way in OSC to
interrogate a device and get back a list of all available parameters that
the device supports?
OSC is connectionless, at least if the implementation uses udp as the
transport-protocol (which most do). So there is no real way to even return
values. Most apps send return-values to the host/port the query came from,
but if that fails or is not handled (as the current state of ofqf...),
nothing really happens. -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFG91f/e8HF+6xeOIcRArnOAJ90Id4gkfGBAFkqq3i4Gty2/U6p9wCeO3fy
eYBZxm+rMhNTCdrN+aSXdac=
=O/M2
-----END PGP SIGNATURE-----
23 Sep
23 Sep
8:20 p.m.
Hallo,
Ken Restivo hat gesagt: // Ken Restivo wrote:
Does OSC support "reflection"? i.e., is
there any way in OSC to
interrogate a device and get back a list of all available parameters
that the device supports?
No, OSC doesn't support or requires that in the specification of the
protocol directly. Synth makers however are free to implement OSC
targets for "reflection" purposes, but even these then aren't
described in the spec, so they will vary between programs.
Ciao
--
Frank Barknecht _ ______footils.org_ __goto10.org__
6077
days inactive
6078
days old
linux-audio-user@lists.linuxaudio.org
8 comments
5 participants
participants (5)
-
Arnold Krille -
Bengt Gördén -
Frank Barknecht -
Ken Restivo -
Lars Luthman