Could anyone give me an example of parsing the OSC output in processing? I've looked at the examples but they only handle OSC input, I want to create a processing interface which updates according to which clip is playing in resolume. I'm unclear as to how to access the clip path sensibly, ideally i want to avoid having to do a separate if statement for each clip location (layer1/clip1/connect - i guess i have to do some string processing to pull out the layer and clip number - but i'm seemingly stuck at a more fundamental level, i guess as i don't get how the OSC message is actually returned and processed.
Any links / code / examples which demonstrate receiving an OSC message from avenue would me very much appreciated.
cheers
tom
[resolved] parsing OSC output [processing]
Re: parsing OSC output [processing]
Code: Select all
int layer1Clip1;
void oscEvent(OscMessage theOscMessage) {
if(theOscMessage.checkAddrPattern("/layer1/clip1/connect") == true) {
layer1Clip1 = theOscMessage.get(0).intValue();
}
println ("clip 1"+layer1Clip1);
}
any clues would be great

Re: parsing OSC output [processing]
Got it working with OscPlug - have to turn off bundles on the output though.
Re: parsing OSC output [processing]
FWIW the standard oscEvent method works as well, but bundles must be off in the osc output settings of arena.
Does anyone have any techniques for parsing the OSC more sensibly? At the moment I have to manually check each address, I'd like to be able to have 2d array which is populated with the layers / clip connected status. Is there anything cunning to do here?
I'm not sure I like the OSC format that resolume currently has it seems to make it hard to get access to clip playing status. It would be good if there was an address such as /layer/status/connected which returns an int containing the clip number currently connected in that layer.
Also i've noticed that sending a connect command to an empty slot causes resolume to send a connect=0 from that clip slot's address, this seems wrong to me the clip cannon be "not connected" as it doesn't exist. When trying to program hardware interfaces it would be very useful to be able to know if a clip slot is empty.
Cheers
Tom
Does anyone have any techniques for parsing the OSC more sensibly? At the moment I have to manually check each address, I'd like to be able to have 2d array which is populated with the layers / clip connected status. Is there anything cunning to do here?
I'm not sure I like the OSC format that resolume currently has it seems to make it hard to get access to clip playing status. It would be good if there was an address such as /layer/status/connected which returns an int containing the clip number currently connected in that layer.
Also i've noticed that sending a connect command to an empty slot causes resolume to send a connect=0 from that clip slot's address, this seems wrong to me the clip cannon be "not connected" as it doesn't exist. When trying to program hardware interfaces it would be very useful to be able to know if a clip slot is empty.
Cheers
Tom
Re: parsing OSC output [processing]
You're right that the current method is a bit repetitive. Fortunately computers are great at doing repetitive tasks.
If you want to get the connected clip status in a 2d array, you can let Processing do the work for you.
Pseudocode:
As long as you're not using 100 layers with 100 clips, CPU wise this is pretty trivial to do.
If you want to get the connected clip status in a 2d array, you can let Processing do the work for you.
Pseudocode:
Code: Select all
int[][] connectGrid = new int[10][3]; //declare 2d array for ten clips, three layers
//populate array
if(messageReceived == "connect")
for(loop through x 10 times)
for(loop through y 3 times)
if(message "layer[y]/clip[x]/connect" == 1)
connectGrid[x][y]=1;
else
connectGrid[x][y]=0;
//do something with your 2d array
Re: parsing OSC output [processing]
Well i couldn't get that to work properly! The problem i'm having is getting the clip / layer values match the array.
At the moment i'm using the following which works, but i'm not sure i like having to do the string processing like this, seems like it is inefficient?
I apologise if these questions are stupid, I'm really not a programer at all! (i should probably go and read some books or something first)
At the moment i'm using the following which works, but i'm not sure i like having to do the string processing like this, seems like it is inefficient?
Code: Select all
void oscEvent(OscMessage theOscMessage) {
String resAddr = theOscMessage.addrPattern();
boolean hasConnect = resAddr.contains("connect");
boolean hasActive = resAddr.contains("active"); // so we can ignore active clip connect msg
boolean hasBug = resAddr.contains("connectclip"); // sometimes resolume sends an ocs message with this, its a bug afaik.
int x = 1,y = 1;
if (hasConnect ==true && hasActive == false && hasBug == false) {
if (resAddr.contains("layer1") == true){y = 3;}
if (resAddr.contains("layer2") == true){y = 2;}
if (resAddr.contains("layer3") == true){y = 1;}
if (resAddr.contains("layer4") == true){y = 0;}
if (resAddr.contains("clip1") == true){x = 0;}
if (resAddr.contains("clip2") == true){x = 1;}
if (resAddr.contains("clip3") == true){x = 2;}
if (resAddr.contains("clip4") == true){x = 3;}
if (resAddr.contains("clip5") == true){x = 4;}
if (resAddr.contains("clip6") == true){x = 5;}
if (resAddr.contains("clip7") == true){x = 6;}
if (resAddr.contains("clip8") == true){x = 7;}
/* check if the typetag is the right one. */
if (theOscMessage.checkTypetag("i")) {
/* parse theOscMessage and extract the values from the osc message arguments. */
int firstValue = theOscMessage.get(0).intValue();
println(resAddr+" OSC Connect msg "+firstValue);
connectGrid[x][y]=firstValue;
return;
}
}
}
Re: parsing OSC output [processing]
Also does anyone know why Resolume sends /layer1/connectclip with an int value of -1 ?
Re: parsing OSC output [processing]
If you could send your .pde file to mail@resolume.com, I'll take a look if I can hack in the for loops.
Re: parsing OSC output [processing]
have sent you a mail.
thanks
tom
thanks
tom