OSC - Open Sound Control

DynamoBen · 2014-11-06 08:06

A while back (2011ish) someone posted propOSC which implemented Open Sound Control for the prop. While the thread still exists the attachment which contained the code is missing. Anyone have a copy? Alternatively does anyone have working OSC code? I'd rather not reinvent the wheel if its already been done. Thanks!

max72 · 2014-11-06 08:56

I missed this one...
Unfortunately I have a 2009 "all obex" only..
That would have been very nice...
Massimo

DynamoBen · 2014-11-24 11:18

I decided to start from scratch since no one seems to have a copy of propOSC. I've got the send portion sorted, now I need to work through receiving and dispatching which might need regex. It's slow going.

max72 · 2014-11-24 13:06

Phil made a regex object... http://forums.parallax.com/showthread.php/117496-Pattern-matching-and-data-extraction-in-Spin-using-regular-expressions.
In case it's not downloadable from the forum I have a copy of this...
Massimo

DynamoBen · 2014-11-24 14:37

max72 wrote: »

Phil made a regex object... http://forums.parallax.com/showthread.php/117496-Pattern-matching-and-data-extraction-in-Spin-using-regular-expressions.
In case it's not downloadable from the forum I have a copy of this...
Massimo

Thanks. I downloaded it the other day and am evaluating whether it will work for my application.

DynamoBen · 2015-01-21 15:13

So I'm mentally stuck on receiving OSC data and could use some help. Here is the spec: http://opensoundcontrol.org/spec-1_0

To give you some background for the transmit code the OSC address is added (stored to a buffer location) and then type tags and arguments are appended (buffer for each) and the the entire assembled string can be requested (each buffer is appended to new buffer location and pointer is returned). This allows any transport method to be used from serial to UDP.

On the receive side I'm stuck on how best to return the data contained in a packet. Right now I'm taking a packet and storing it to three buffers: Address, Type Tags, and Arguments. Returning the Address is pretty easy I just return the pointer to the buffer I stored it to, but returning the arguments are tricky especially when multiple arguments types are mixed together (IE an int32, a string, another int32, another string). One thought was to request data based on type tag position. Using my example position 0 would be an int32, position 1 would be a string, etc. But by doing this I would have to hunt through the buffer by type to find the data and then return it. This seems inefficient and not very elegant. Is this the best way to do it? Thoughts on a better way?

Duane Degn · 2015-01-21 15:58

This is in Spin right?

I think I've done something similar with a Modbus project which used different data types for different registers. When the program first started up, I'd have it build an identification array which would contain the type code.

(The registers in this example were all even numbers.) Edit: Doesn't matter. I changed the code to use both odd and even values.

PUB FillDataTypes

  bytefill(@dataTypes, INTEGER_DATA, NUMBER_OF_REGISTERS)
  
  repeat while floatDataList[result] < NUMBER_OF_REGISTERS
    dataTypes[floatDataList[result]] := FLOATING_POINT_DATA
    result++
  result := 0
    
  repeat while stringDataList[result] < NUMBER_OF_REGISTERS
    dataTypes[stringDataList[result]] := STRING_DATA
    result++

The data types were defined with constants:

#0, INTEGER_DATA, FLOATING_POINT_DATA, STRING_DATA

The data type was initially assumed to be an integer but then the list of floating point registers and the list of string registers were read and appropriate types filled into the "dataTypes" array.

Each of the constants listed of course corresponded to a unique register number.

floatDataList           byte COEFF_A_REG, COEFF_B_REG, COEFF_C_REG
                        byte COEFF_D_REG, COEFF_E_REG, COEFF_F_REG                        
                        byte STATIC_FLOAT_REG, NUMBER_OF_REGISTERS
                        '' "NUMBER_OF_REGISTERS" used to mark end of list
                        
stringDataList          byte VERSION_REG_A, VERSION_REG_B, UNITS_TEXT_REG
                        byte SERIAL_NUMBER_TEXT_REG_A, SERIAL_NUMBER_TEXT_REG_B
                        byte STATIC_STRING_REG, NUMBER_OF_REGISTERS

The value of "dataTypes[registerNumber]" could then be used to identify what type of data the register contained.

I'm sure there's a technical term for this technique. I imagine database software produces lists like these (and then some).

Did I understand the question correctly? If so, maybe the above would be useful.

DynamoBen · 2015-01-21 18:03

Duane thanks for the suggestion, I need think it through some more and see if I could make something like that work. Was the data you were receiving each time the same? In my case the data I'm receiving differs every time, so packet to packet I don't know what mix of data it will contain.

Publison · 2015-01-22 10:30

I thought I had a copy of PropOSC somewhere, but scanning 4 computers turned up nothing. I guess it's lost forever since the guy that developed it hasn't signed in since 20012.

He has no email in his profile. By his IP address, he is located in Canada.

DynamoBen · 2015-01-22 10:50

Publison wrote: »

I thought I had a copy of PropOSC somewhere, but scanning 4 computers turned up nothing. I guess it's lost forever since the guy that developed it hasn't signed in since 20012.

He has no email in his profile. By his IP address, he is located in Canada.

It's a huge bummer, I also tried posting to the original thread thinking he might get an email notification. But no response.

I wonder if Parallax might have a backup of the file...doubt it but one could hope.

Publison · 2015-01-22 10:52

Backups of the old OBEX were not produced. I'm afraid this one is gone.

Duane Degn · 2015-01-22 10:53

DynamoBen wrote: »

Was the data you were receiving each time the same?

No, but the data included a header with the size of the packet and the starting register number. I would use something like:

  case dataType[registerNumber]
    INTEGER_DATA:
      ReceiveIntegerData(rxPacketPointer)
    FLOATING_POINT_DATA:
      ReceiveFloatData(rxPacketPointer)
    STRING_DATA:
      ReceiveStringData(rxPacketPointer)

The array "dataType" had previously been filled with the appropriate values so it acted as a fast lookup table.

I'm not sure if the above code would apply to an OSC packet or not. Looking at the OSC page you linked to, it appears there's an identifier which includes the data type. I'm not sure if I'm reading that correctly or not though.

Could you give a couple examples of data you could receive? Am I correct in thinking the data is sent as ASCII characters?

DynamoBen · 2015-01-22 10:54

Publison wrote: »

Backups of the old OBEX were not produced. I'm afraid this one is gone.

I don't think it made it to the OBEX, I think it was just posted to the forum.

DynamoBen · 2015-01-22 11:22

Duane Degn wrote: »

Could you give a couple examples of data you could receive? Am I correct in thinking the data is sent as ASCII characters?

Spec has examples via hyperlinks, the website isn't loading for me otherwise I would embed a link here.

UPDATE: It's loading here are some message examples: http://opensoundcontrol.org/spec-1_0-examples#addressparts

OSC - Open Sound Control

Comments