I couldn't help myself having a quick glance at those newly introduced classes. It's definitely exciting to have OSC support in vanilla Pd.
I wondered about [oscparse] how address and payload can be distinguished after being parsed, since [oscparse] outputs all in one list.
Example: osc('/bla/bla 12') and osc('/bla bla 12') both are parsed to 'bla bla 12'.
Roman
Correct. The bet I'm making is that nobody who's receiving OSC messages would have any doubt which is it. YOu have to know what messages the source is sending you and what to do with them anyway. And if any source is actually sending "bla 12" to "/bla" and also "12" to /bla/bla, well, I think they're nuts, and anyway you can always grab the ones from mrpeach.
OTOH, if it does turn out that there's any real situation when such disamiguation is needed (for instance, storing OSC streams for later sequencing?) the objects could easily be altered to put in symbolic markers to separate everything - this would be in the form of a creation flag to make it an option. But I think for 99% of the use cases this would just be a huge extra pain.
There are similar limitations in the MIDI implementation that have been in place for years: you can't get note-off velocities (they're mapped to zero-velocity note-ons).
cheers Miller
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list