yerps

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.

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.

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. 

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. 

sendrecieve-question

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

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. :)

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

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

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?

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?

... 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.

OK.. in response to your initial question..  

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.


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.

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

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

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 : ?

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.

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 : ?  

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.

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.

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.

send/recieve question