New lightweight OSC processing library, LiteOSCParser

[shawn]

I was dabbling with a more lightweight OSC processing library, both with the API and with memory usage.

Here it is: https://github.com/ssilverman/LiteOSCParser

To test it, I built a complete system that relays OSC frames between an ESP8266 and a Teensy over SLIP, and that provides convenience functions for processing messages to and from TouchOSC. Right now, just the parser is being released.

 

[adrianfreed]

Interesting work. Are you skipping the regex part of the OSC parsing?

 

[shawn]

I am. Should be pretty straightforward to add, though, if needed. Maybe I don't completely understand, but I don't know why they're useful.

I just haven't found a use case for them. All of the UI's I've ever made have unique controls, for example, "/control1" and "/control2". I've never had more than a one-to-one correspondence between OSC controls from a UI and their effects. Each control has exactly one action. If I used the pattern "/control[12]" (and there's no "\d" or something, as in regexes), then that would send them to some function that would need to pull out the number, so now I have a function that splits into two actions anyway. And in addition, I'd have to pull out the address and parse the numbers out of it---meaning this parsing has been done several times already. Also, patterns are matched when the messages are received, so not only do I have to have static OSC messages hanging around, I still need to cycle through each one to find the match. If I'm doing all this anyway, why not just match one at a time and call something or set a state or whatever?

Also, because I'd have to pull out the address to parse it to see which number is there, I'd have to use yet another, different buffer with the CNMAT OSC library just to get the address. This is one of the reasons I have the getAddress() function which returns a const pointer directly to the internal memory.

Maybe I'm missing something...

 

[adrianfreed]

I am. Should be pretty straightforward to add, though, if needed. Maybe I don't completely understand, but I don't know why they're useful.

I just haven't found a use case for them. All of the UI's I've ever made have unique controls, for example, "/control1" and "/control2". I've never had more than a one-to-one correspondence between OSC controls from a UI and their effects. Each control has exactly one action. If I used the pattern "/control[12]" (and there's no "\d" or something, as in regexes), then that would send them to some function that would need to pull out the number, so now I have a function that splits into two actions anyway. And in addition, I'd have to pull out the address and parse the numbers out of it---meaning this parsing has been done several times already. Also, patterns are matched when the messages are received, so not only do I have to have static OSC messages hanging around, I still need to cycle through each one to find the match. If I'm doing all this anyway, why not just match one at a time and call something or set a state or whatever?

Also, because I'd have to pull out the address to parse it to see which number is there, I'd have to use yet another, different buffer with the CNMAT OSC library just to get the address. This is one of the reasons I have the getAddress() function which returns a const pointer directly to the internal memory.

Maybe I'm missing something...

Regex allows for more expressivity when you are controlling things. You don't need to invent special commands like other protocols do (ALL NOTES OFF, ALL LIGHTS OFF, etc.). If you want a report on only certain pin values for example, e.g. /d[0-3] as in the Oscuino exampled in the (not so lightweight) OSC library for Arduino.

 

[shawn]

Ok, I think I get it now. I was thinking that the server had the patterns and the client had the non-patterns. Most of my UI's are in the "TouchOSC" style, where there's one name per control, and then the server has to pick out parts of an address. This was why I was having difficulty understanding the use of pattern matching. It turns out that the intent is for the client to send the host the patterns; I had this backwards, but now I see the purpose. It'll be a fun mini-challenge to write a little regex matcher. One of these days I'll add it to the library.

This example helped: http://opensoundcontrol.org/spec-1_0-examples#bundledispatchorder

I still think the CNMAT library could provide better ways to access the address, but at least now I get the wherefore of the patterns. Finally. This was nagging at me...