Given incoming OSC messages such as knob_1 (data), knob_2 (data), knob_3 (data), etc (slashes omitted because oscparse strips them), extract the index from the command path and format a "y x" message for tabwrite.

It feels somewhat naughty in Pd.

(Not a question btw -- this works!)

hjh

the Mrpeach library is notoriously better than Pd's native OSC objects. I had issues with the TouchOSC app which prepends the page number to all its widgets, and with Mrpeach it was a piece of cake to get the data, while with Pd it is genuinly difficult (actually I can't remember if I got it to work, but even if I did, it sure was ugly).

@ddw_music I will second @alexandros's opinion.
During the interval when Martin Peach's externals were unavailable for 64-bit Pd I experienced a total Vanilla nightmare for TUIO messaging for OSC.
In his library...... [dumpOSC] >>>[unpackOSC] >>> [routeOSC /knob_1 /knob_2 /knob_3]
The worst part in Vanilla was parsing integers in the address received as symbols.... making routing difficult...... it seems that has not been resolved.
We still (0.53) need to know what the data will be and use [makefilename] at [loadbang] to the right inlet of [route dummy] to solve this problem.
"dummy" is pertinent.......
David.

Note that the patch snippet separates /knob_1 into knob_ and 1, eliminating the need for [route knob_1 knob_2 knob_3 ad infinitum]. So the suggestions, while accurate, are not necessarily germane to the goal I had in mind.

Some years ago, it was recommended to me to use fudiformat --> fudiparse after osc parsing, as a workaround. This isn't beautiful but neither is it especially painful (no more painful than trying to remember when you need a "symbol" prefix and when you don't).

hjh