send/recieve question

yerps's icon

hello

I would like to send number data from machine A to B.

someone suggested opensoundcontrol. But I wonder is there any reason why sending data like in my example picture below would be a problem? is it not as efficient as OSC?

I also remember once someone saying never to use a space in a message.

So never (test 22)

instead use (test-22).

But I am unsure how when using (test $1) I can remove the space and insert a dash? unless i use sprintf. (sprintf test-%s); but someone said sprintf was not efficient and I should steer clear.

Any thoughts on making these connections efficient would be great as i plan to use lots of these on a slow network lan and machine.

yerps : P

send-receiv-q.jpg
jpg
Roman Thilenius's icon

sprintf ... or you can do it the other way round, and send the index identifier ("test2") as single message:

number
t f test2
udpsend
...
udpreceive
zl group 2
route test2

of course this only works, when this of data is the only data sent over this connection – you can no longer mix numbers _without index identifier throuhtg this system. :)

-110

Roman Thilenius's icon

you can also use numbers as index, adn control a gate with it on the receiving end.

"1, 87." ... "2, 27."

an then

udpreceive
cycle
gate 100

metamax's icon

Another option...

Max Patch
Copy patch and select New From Clipboard in Max.

yerps's icon

thank you both : )

I think i may used this(picture below) type of system across my patch. I have a 100's of these number boxes to send. Some of them fire out very fast. So my only concern is clogging up a single port. Maybe I should share/distribute these across a few ports instead of just one port? Maybe every 10 of these per port?

heres the pic : >

numbers-ip-.jpg
jpg
metamax's icon

OK.. in response to your initial question..

I wonder is there any reason why sending data like in my example picture below would be a problem? is it not as efficient as OSC?

The magic of OSC is in the bundle... No need to send a ton of individual messages when you can send them as a single bundle. In this case, it looks like OSC would be a lot more efficient. Check out the odot library at CNMAT.

yerps's icon

thank you for this extra option metamax, : )

I may run a latency test to see how using OSC in bundles effects received timing of the number info compared to the other option.

thanks again. : P

metamax's icon

Hey I'd be interested in seeing the results if you get around to it.

yerps's icon

cool, I shall post here if i get it working.

yerps's icon

hi Metamax.

I created a ping style test. I sent osc from machine A to machine B and back to A and measured the latency, along with the previous idea of regexp through udp.

regexp method is quicker of course, but at times both osc method and regexp would become exactly equal as they syncronised. very weird. I was also using (mean) so i could see the average of the latencies. Yet they would be equal at times : ?

osc is using a fast (metro 1)

i cleared the (mean)'s every 20 triggers into the print.

the test patch is a bit cluttered , i shall also include a save of the max print out so you can see the full 30 seconds of latency prints from the (timer) > (mean).

i felt the need to add a few things to the patch: when i trigger 'start' or 'clear' it appears in the print out just makes it easier to see what is going on, i am sure you'll see what i did.

I could not believe the timings would be equal after traveling from machine A>B >A. see what you think.

if you want the patch , perhaps feel like boring yourself to death with a test give me a shout.

yerps. : )

30-secs-udp-osc-Max-print.txt
txt
udp-osc-test.jpg
jpg
yerps's icon

in the print list , look for where the (mean) object is cleared. At times the two methods are absolutely together. Amazing times for an A>B>A> round trip (averaged ofcourse), I should have included a full test without averaging. but its 3am now. Anyhow the initial triggers tell us the latency. Because LAN latency varies so much i wanted to know the average. This test shows us the average and the initial latency that is directly after a 'clear' so we do get both infos.

hope this all makes sense.

peace,