OSC Arrays and accuracy

Hey all,
I’m trying to get my OSC game on once and for good… I’ve been on and off OSC for sometime now motivated and discouraged. My main issue is that some numbers just dont pass through, I would change a knob on the other side (be it max or reaktor) and it seems that not all value are being received. I tried with the builtin UDP to OSC decoder, and the Elliot Woods OSC pack. I am trying now (with little success) to figure out the message pack…
long story short… what would be the best way to make sure I get every value coming in (say I send 40 values at the same time)? VL? Message?
I dont know how to work with either of them, so I need make a smart choice before I learn one…
Thanks

Ofer

hm…i’d first try to understand what the reason is for “values not coming through” before betting on a new horse. can you shed some light on how you’re doing things? you say you’re sending 40 values at the same time. is this

  • one osc-message with 40 floats?
  • a bundle with 40 osc-messages to the same address with each one float
  • a bundle with osc-messages with different addresses?

or is this via shaky wifi that drops udp messages?

Hey @joreg
its arrays of 4 sent on different addresses,
e.g
0.5 0.1 0.8 1. on /translatex
and I spread the decoder addresses
unzip by bin size

Its all localhost…

Ofer

@ofersmi the wifi bit is also important. It’s cable or wifi?

@h99 Its all localhost, so loopback…
so not wifi or cable, no?

@ofersmi I thought there could have been another machine in the middle. Though localhost would have been a real good pointer.

are you sending them as bundle?
are you aware of the “Queue Mode” on the UDP (Network Server)?
are you aware of the “Match Rule” input on the OSCDecoder (Network)?
see helppatches for explanations.

Yes, I was experimenting with all combinations of Queue Mode and Match Rule and found that spread and last work best when I use max to send data.
but when I use reaktor I dont get the same results, I guess its related to the way Reaktor sends bundles…
I now have max sending and the data is reliable, but not with reaktor… thats too bad coz Im really sick of max…
These are just dry tests, so there is no real content running yet (visual or audio). I have to now continue testing with a real load on the computer to see if I still get the same results.

hm…seems a bit hard to help here then if you have different results from different senders…

initially you wrote

how do you actually know that? are you changing one knob at a time or multiple at once?

changing a single knob should result in bundle to be sent that contains a single osc-message. right? now of course if you change the knob a lot, many such bundles will be sent. thats fine because typically what you’ll want, is to just receive the last one, and you’d set the UDP Queue mode to “Discard”.

If you’re changing multiple knobs at the same time though, those could now be sent as multiple messages in one bundle or still individual bundles with one message each. in either case you’d now better switch to Queue Mode “Spread”, to make sure all messages are passed to the decoder. and now the decoder can choose to report either all, but most likely just the last received message per address which should work in either case…

@lasal do you have any reaktor/osc experience that could explain ofers problems?

Hey,
sorry for the long silence,
I had to move on with the project. Now it’s gone and done I can get back into the troubles I had…
I know because I mostly use reakotr or max (in the end only max…) to store presets and recall them in live. so I usually pass like 20 parameters in one go…

Ofer

k, i have no idea how to help here if you don’t get more specific.
“I usually pass like 20 parameters in one go…” how exactly do you send your values. describe how the osc-messages look like and how they are sent.

generally i can only say there are no known issues regarding receiving osc in vvvv. things should just work (if you do it right).

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.