send/recieve question

    Nov 23 2013 | 6:26 am
    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

    • Nov 23 2013 | 7:00 am
      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. :)
    • Nov 23 2013 | 7:04 am
      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
    • Nov 23 2013 | 7:27 am
      Another option...
    • Nov 23 2013 | 5:55 pm
      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 : >
    • Nov 23 2013 | 6:08 pm
      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.
    • Nov 23 2013 | 11:18 pm
      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
    • Nov 24 2013 | 12:06 am
      Hey I'd be interested in seeing the results if you get around to it.
    • Nov 24 2013 | 12:33 am
      cool, I shall post here if i get it working.
    • Nov 24 2013 | 3:16 am
      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. : )
    • Nov 24 2013 | 3:30 am
      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.