I’ve started using some of these OSC control surfaces, looks like a better way to go than always using MIDI for various reasons. For one thing I can run Sonic Pi with other software on the same PC without the fight for who grabs the midi input first.
These apps often code a lot of the useful into in the message path itself, rather than the following parameters - e.g. the button ID, something like /OSC:foo:9733/1/Push1/, 100
Rather than have lots of live loops syncing on each button, I’d like to have a wildcard sync for a set of buttons, and switch in the code based on the Push1, Push2 bit.
I’ve seen the code here for parsing the path based on an undocumented get_event() function. Is that currently still the only way to do it? Seems like it ought to be a core bit of functionality. Not complaining just asking
My workaround for the minute is to use an OSC app with a piano keyboard, then the note value comes in as a parameter typically. I mean, it’s fine, just be a nice-to-have.
As the author of two parsing routines, one for osc cues and the other for midi cues I agree on the usefulness of such functions to aid decoding multiple osc calls of a similar format from controllers such as TouchOSC. It would be nice to incorporate them, but they are subject to revision, as illustrated by this latest reference indicated one such change when the format of midi cues changed.
There will be further changes soon, as the code Sonic Pi uses to deal with midi cues is fundamentally altering in 3.3beta and as a result the existing parsing functions will require to be tweaked. I have already been discussing one possible change in format I’ve noticed in the developing code with @samaaron.
It would be nice to have the routines you discuss built in, but they necessarily lag a bit behind the development of the cue system, and they are generally for the benefit of a minority of advanced users.
Having said that, although at present such routines make use of the internal get-event function which is not guaranteed to remain “as is”, I have successfully used such functions for several years with a whole range of quite sophisticated programs involving TouchOSC control with correcting tweaks from time to time.
At the end of the day i think it boils down to the limited human resources available for Sonic Pi development. Getting the new internals working for midi is a demanding job, and every additional requirement increases the load for development and testing, but I would hope to have similar functions available for use with 3.3
Thanks Robin. Understood. I was really checking whether i was missing a trick and there was a new or conventional way to get at the raw OSC string - which would be fine. If the format changes, that’s life.
Yes indeed, every feature takes time and effort I know. It’s only because I’m finding Sonic Pi so incredibly useful that I’m going down all these avenues.
I’ll try out your parsing rountines for interest. Right now though my OSC needs are quite simple - triggering samples and a virtual OSC keyboard is fine for that - I was using a midi keyboard for that before.
