Hi Martin,
Please add your comments to the wiki!
And yes the idea of getting OSC children back is a patch implimentation!
route could work as an OSC replacement, but multi level matches [OSCroute /my/node /my/tree] does not make sense: [route my node my tree] would be /my /node /my /tree
Also [route] does not have a set message either.
I'm sure there is an IRC client for windows... ummm Xchat works on linux and OSX, maybe windows too.. I dunno.
.b.
Martin Peach wrote:
B. Bogart wrote:
Hi Martin,
I'll try and dig up some ideas seom emails I sent out about OSC in the past. There were really critisism of OSCroute rather than dumpOSC and sendOSC. I think it is certainly much more logical to have OSC piggyback on the netsend/netreceive objects.
Could you explain what you mean by float-lists? Or do you mean a binary-data stream formatted as a list of floats?
A stream of bytes as a list of pd-floats. I was thinking of an OSCencoder that would output a list of floats which could then go to netsend. Netsend needs a trailing ';' though, so it needs to be modified to accept a 'raw' mode which would accept only floats or lists of floats that were integers on [0...255], so really it needs to be another object to avoid confusion. Mathieu Bouchard's idea of tcp and udp objects might be better than modifying netsend, but it would basically be the same code.
It's easy to change sendOSC to output a list of floats, and dumpOSC to receive lists of floats.
Today I changed sendOSC to use code from netsend, so now TCP is possible. It is faster than netsend because an extra conversion from symbols to bytes is skipped. I'll try modifying dumpOSC the same way to see if OSC works over TCP in pd.
Do you want to get back to me in a couple weeks to meet on IRC about next steps? (maybe a bigger meeting for other opinions if you'd like)
OK, I've never used IRC. Is there a Windows client you know of? I don't have constant access to linux boxes here.
I decided the best thing is to put up a wiki of changes:
https://puredata.org/Members/bbogart/OpenSoundControlProposal
OK, the first one (decouple OSC from transport) is not too hard, but as I said it needs netsend and netreceive to be modified, or else new udpin and udpout, tcpin and tcpout, analagous to midiin and midiout, that convert float lists to and from byte streams.
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.
Possibly if dumpOSC output its path on one outlet (as a list of symbols with the slashes removed) and the data on another as a list of anythings, then route could be used instead of OSCroute.
Also OSC is supposed to accept wild cards like '*', I don't know if this works in pd. Martin
I'll send it out to the pd-dev list also.
Hopefully in a few weeks we can start making headway!
.b.
Martin Peach wrote:
Hi Ben, I would do it for free but if there's money available, then whatever is reasonable ;) I guess we need to clarify what exactly is desired. I was thinking of putting all the OSC stuff into one file to start with (at the moment libosc has to be compiled first), then ripping out the network part and replacing it with float lists which ideally could interface to netsend and netreceive. That seems pretty easy but probably there are reasons why it won't work. I need to look at netsend and netreceive again. Anyway I'll work on it whenever I get time to do so. The next two weeks are packed with final projects here.
Martin
B. Bogart wrote:
Hi Martin,
How much money would you want as compensation to rewrite OSC in PD so that it has the features we have talked about on the list? I'm trying to get SAT to fit the bill as pixelTANGO is dependant on the changes to OSCx.
It think its best we have a concrete proposal to approach the SAT with.
Are you interested?
We can try and do a meeting on IRC sometime soon to talk about it if you would like.
Hope to hear from you soon.
.b.