Here are some ideas on how to make OSC work better in PD.

• Decouple the OSC from the transport. netsend/netreceive are used to transport the OSC messages. (Does this make sense since netsend/netreceive need ";" terminators?) It would be nice to also send OSC through netclient for two-way OSC communication.

  I'm also very interested an implimentation of the OSC spec that allows the client to query which children a node has. The message: /node/1/ is supposed to tell the server to return a list of all the children of that node. This is used to crawl the OSC structure without having to manually advertise your OSC names.

• Allow OSCroute? (or whatever it will be called in the future) to route multiple levels:

  [OSCroute /node]? -> [OSCroute /1]? -> [OSCroute /position]?

  becomes:

  [OSCroute /node/1/position]?

  [OSCroute /node /node/1/]? means that all messages that go to /node/1 would also go to /node.

• The ability to "set" the route name with a [set /node/1/position< message. Franks suggestion here is to only allow the "set" message when OSCroute is placed with a single creation argument (so that outlets need not change based on message input).
• Allow "" inside OSC names like /node//position/ would match all children under /node and send to its subchild "/position" if its there, otherwise send through the rejection outlet.

  For more info on the "set" discussion see the following thread

  Please feel free to add stuff, but I would consider the above as an important start.

comments:

decoupling OSC from transport --martinrp, Thu, 30 Mar 2006 23:36:17 +0200 reply
Decouping OSC from transport is not too hard, but it needs [netsend]? and [netreceive]? to be modified to not require the trailing semicolon, or else new [udpin]? and [udpout]?, [tcpin]? and [tcpout]?, analogous to [midiin]? and [midiout]?, that convert float lists to and from byte streams. It's fairly easy to change sendOSC to output a list of floats, and dumpOSC to receive lists of floats. Then objects [udpin]? and [udpout]?, [tcpin]? and [tcpout]?, analogous to [midiin]? and [midiout]?, based on the code for [netsend]? and [netreceive]? would send/receive the lists of floats (constrained to be integers on [0...255]?) as raw bytes. Martin

I think your idea of querying for child nodes could be better implemented as a pd patch, since the dumpOSC has no way of knowing what kind of tree it's in.

Also OSC is supposed to accept wild cards like *, I don't know if this works in pd.

generic net objects --hans, Fri, 31 Mar 2006 03:25:38 +0200 reply
Matju's proposal with [tcp]? and [stream]? objects, IIRC, seems like the way to go. TCP and UDP are bi-directional protocols, so the object should reflect that, like [netserver]?/[netclient]?, or [comport]?.