teqy

I have been running some tests on the udp send & receive modules.

Yesterday I made a pluggo plugin which can send data via udp from steinberg nuendo into maxmsp. I was impressed that it worked, however I noticed with my eyes that the data received into max seemed skippy and jittery as if there is data lose and uneven moments. So I ran a simple smooth pattern from nuendo and recorded the received udp data in max via the "print" module. I let this pattern loop out of nuendo without moving the mouse or any background prog's running and printed the results out to a jpeg (attached below).there are 4 print columns in the jpeg, these are the beginnings of 4 of the loops. the numbers should be the same on each column but as you can see there are missing numbers.

system :I am running a fairly quick dual core 3.2ghz 800mhz fsb, XP and I was not torturing the cpu during this test. load was fluttering around 4 percent. so i am unsure why there is missing data?

hope this all makes sense any help on this would be cool. : )

I have been running some tests on the udp send & receive modules.
Yesterday I made a pluggo plugin which can send data via udp from steinberg nuendo into maxmsp. I was impressed that it worked, however I noticed with my eyes that the data received into max seemed skippy and jittery as if there is data lose and uneven moments. So I ran a simple smooth pattern from nuendo and recorded the received udp data in max via the "print" module. I let this pattern loop out of nuendo without moving the mouse or any background prog's running and printed the results out to a jpeg (attached below).there are 4 print columns in the jpeg, these are the beginnings of 4 of the loops. the numbers should be the same on each column but as you can see there are missing numbers. 

system :I am running a fairly quick dual core 3.2ghz 800mhz fsb, XP  and I was not torturing the cpu during this test. load was fluttering around 4 percent. so i am unsure why there is missing data? 

udp-sendreceive-data-loss-pics-included

I guess it's due to the weakness of the UDP protocol - it tends to skip messages when they flood your system.

UDP uses a simple transmission model without implicit hand-shaking dialogues for providing reliability, ordering, or data integrity. Thus, UDP provides an unreliable service and datagrams may arrive out of order, appear duplicated, or go missing without notice. UDP assumes that error checking and correction is either not necessary or performed in the application, avoiding the overhead of such processing at the network interface level. Time-sensitive applications often use UDP because dropping packets is preferable to waiting for delayed packets, which may not be an option in a real-time system.[1] If error correction facilities are needed at the network interface level, an application may use the Transmission Control Protocol (TCP) or Stream Control Transmission Protocol (SCTP) which are designed for this purpose.

I set up an UDP connection once, between two computers running Max/MSP, and sent messages in regular intervals (using a metro object). I figured if the interval between messages is less than 6 ms it will skip some of the messages.

Have you tried using TCP instead? The drawback of TCP is that it's a little bit slower, but it always makes sure the packages arrive.

BTW - it's a really nice thing you're making! Does it also work with Cubase?

you might try [count] instead, it doesn't have the overhead that [print] does, I don't think. you can't see it in real-time, just the results, but it may be that you're actually getting the values right but the tiny amount of time it takes for [print] to do its thing could be misleading your analysis.

If it really is skipping due to the udp itself, then, well... you got me :/

I have tried (net.tcp.send) and recv objects but the result was just as poor. so this is rather peculiar ! I am just about to reinstall a fresh OS on a more powerful quad machine and see how I go with that as maybe I have a strange conflict going on somewhere? I was wondering perhaps there is a way to assign more resources (memory and cpu) to the udp or tcp protocol?

if all else fails i may just have to place my entire project inside a vst instrument or plugin so there would be no need to use UDP or tcp as all the data and processing resides inside the vst area ...or so i think? lol.

I shall endeavour to find a solution and post here later today.

I have tried (net.tcp.send) and recv objects but the result was just as poor. so this is rather peculiar ! I am just about to reinstall a fresh OS on a more powerful quad machine and see how I go with that as maybe I have a strange conflict going on somewhere? I was wondering perhaps there is a way to assign more resources (memory and cpu) to the udp or tcp protocol?  

if all else fails i may just have to place my entire project inside a vst instrument or plugin so there would be no need to use UDP or tcp as all the data and processing resides inside the vst area ...or so i think? lol.   

I have just tried the experiment on my other machine with a fresh OS and max/ nuendo install but the same problem arises.

in brief : I create a simple automation pattern on the sequencer timeline, send that into the vst>udp pluggo plugin i made. that info is then sent and received in maxmsp but when it arrives there is missing data at random moments.

so i tried the TCP variation of the plugin ( mxj net.tcp.send) & recv modules. these are worse. How can this be? One in every few numbers are missing at the receive side of max.

So it really is strange. could it be that the (pp) object inside the plugin that converts the vst data into usable max numbers is unable to cope? could the problem be the plugin? I thought to include a (print) inside the plugin itself, but unfortunately print does not work inside pluggo runtime.

however, there is similar plugin called "oscglue" that converts vst into osc but that has the same issues as mine. jittery ,missing data also unable to specify a single IP so it broadcasts to all on the network. hence i decided to make this pluggo.

maybe this is a scheduling issue? a performance tweak needed inside max?

i am using localhost port 71 for my tests. RME raydat and 9636 and EMU 1616m soundcards have been used during these tests on bios primed/ stable machines. i have very low quality graphics cards @ £25 lol. but i cant see that being the issue?

I have just tried the experiment on my other machine with a fresh OS and max/ nuendo install but the same problem arises. 

So it really is strange. could it be that the (pp) object inside the plugin that converts the vst data into usable max numbers is unable to cope? could the problem be the plugin?  I thought to include a (print) inside the plugin itself, but unfortunately print does not work inside pluggo runtime.

however, there is similar plugin called "oscglue" that converts vst into osc but that has the same issues as mine. jittery ,missing data also unable to specify a single IP so it broadcasts to all on the network. hence i decided to make this pluggo. 

i am using localhost port 71 for my tests.  RME raydat and 9636 and EMU 1616m soundcards have been used during these tests on bios primed/ stable machines. i have very low quality graphics cards @ £25 lol. but i cant see that being the issue?

Here are the pluggo plugins (UDP and TCP) and receive patch in a zip. if anyone is interested, it may just be that i've forgotten a simple module in the plugin? Pluggo runtime is needed to make it all work. here:

https://cycling74.com/downloads/discontinued/

max 5 patch and localhost plugins zip file here on fileden:

http://www.fileden.com/files/2009/5/27/2457787/vst-udp%20.zip

i used 4.6.1 to make the plugin, but the receive patch is in max 5 format.

Maybe i'm totally wrong but could you try [jit.qfaker] -> [udpsend ...] so that it force your message to be sended in high-priority thread ?

Actually, I think using VST would be a good solution!

You could make one VST plugin which is loaded both in Max and in Nuendo, and all instances of this plugin will share the same memory allocation. Would that work?

Actually, I think using VST would be a good solution!
You could make one VST plugin which is loaded both in Max and in Nuendo, and all instances of this plugin will share the same memory allocation. Would that work?


I am still testing pluggo and VST, no luck so far, UDP may not be the problem, I shall report when I can be more certain after a few more tests. Needed to reply tonight so you all know I am still tryng to find a way to make this work.

I'm far from better a specialist about these things, so i might be wrong again, but, just wondering : Maybe you have to much udp packets ? What if you group a bit your data before sending it? I was just looking at [aka.datagram] maxhelp ( 

http://maxobjects.com/?v=objects&id_objet=1937

 ) and was looking at the "resizes buffer" option...

I'm far from better a specialist about these things, so i might be wrong again, but, just wondering : Maybe you have to much udp packets ? What if you group a bit your data before sending it? I was just looking at [aka.datagram] maxhelp ( http://maxobjects.com/?v=objects&id_objet=1937 ) and was looking at the "resizes buffer" option...

hello thanks, i shall try that object out alexandre! : )

***Interesting development **** I have found that UDP is not the only prime suspect for missing data.

I created a (line) loop patch so that the line object created a smooth loop 0 > 100 > 0 > 100 , just like i created a rubberband pattern in nuendo.

first test was inside Max5 only , I routed the line loop to a updsend localhost 71 and received it inside the same max patch and of course it worked perfectly. I printed out the results every digit accounted for. After this I created a Pluggo plugin .dll with the same line loop design, So now this next test i'm sending a loop from within the pluggo nuendo VST > back outside and into Max 5 which again has receiveudp 71 running. and behold, perfect results printed out, every last digit.

so udp is perfectly fine with this small stream of data, as it should be. and pluggo is happy too!

'Yet' the problem of missing data still exsists when using rubbberband automation inside vst!!

So could it be the PP object converting rubberband data into usable max data ? Is this the bottleneck? but how can this be a bottleneck with such a simple pattern, with so little information.

Is anyone here running a mac and logic? Most of my tests are on XP and steinberg!

or maybe someone could try the same test on their PC? it only takes a short while and its very interesting to see it work. I have tried the sequencer called "Reaper " and that was worse! Very poor results. Something is happening a mismatch inside the vst to pluggo conversion connection,(perhaps the need for a buffer to aid stability? that object alexandre posted above looks interesting.) i wish the person who made pluggo was here. I wonder if he/she knew about this when they published pluggo?

***Interesting development **** I have found that UDP is not the only prime suspect for missing data. 

I created a (line) loop patch so that the line object created a smooth loop 0 > 100 > 0  > 100 , just like i created a rubberband pattern in nuendo.

first test was inside Max5 only ,  I routed the line loop to a updsend localhost 71 and received it inside the same max patch and of course it worked perfectly. I printed out the results every digit accounted for. After this I created a Pluggo plugin .dll with the same line loop design, So now this next test i'm sending a loop from within the pluggo nuendo VST > back outside and into Max 5 which again has receiveudp 71 running.  and behold, perfect results printed out, every last digit.

so udp is perfectly fine with this small stream of data, as it should be.  and  pluggo is happy too!

So could it be the PP object converting rubberband data into usable max data ?  Is this the bottleneck? but how can this be a bottleneck with such a simple pattern, with so little information.

Is anyone here running a mac and logic?  Most of my tests are on XP and steinberg!
or maybe someone could try the same test on their PC? it only takes a short while and its very interesting to see it work.   I have tried the sequencer called "Reaper " and that was worse! Very poor results.  Something is happening a mismatch inside the vst to pluggo conversion connection,(perhaps the need for a buffer to aid stability? that object alexandre posted above looks interesting.)  i wish the person who made pluggo was here. I wonder if he/she knew about this when they published pluggo? 

(aka.datagram) seems to be mac only, A buffer may be what is needed to solve this puzzle.

(aka.datagram) seems to be mac only,  A buffer may be what is needed to solve this puzzle.


I removed the PP object from my pluggo plugin; and instead went for a (plugmidiin)

This midi object takes a Continuous controller from the timeline of Nuendo, brings it into pluggo and then I routed the data out via udpsend localhost 71. I then received on udp 71 inside max 5 and printed the results, Everything is fine. every bit of data accounted for under midi.

so (PP) is the problem on my XP VST system. So I am unable to use PP as it causes data loss and confusion. I wish I had an apple mac and logic , to see if it is a flaw in actually the windows externals or windozzie itself.

I used the same vst pattern for both tests, both the PP and the midi outputed the same number of digits per 2 bar loop . (I believe it was 84 numbers every 2 seconds?)not that many at all. So the resolution is the same with the same rubber band pattern ( only the possible range is different) ie 0-127 for midi CC and vst (PP) > max is well .... very deep/wide indeed.

so it is unfortunate that i cannot use the vst rubber bands from nuendo and have all that range to play with. i am stuck with midi again..!! :/

I may try to simulate a Mac on my PC?? I've heard that done before. unless anyone else here uses pluggo and maybe logic to run a test?? woooo yeah that would be cool to see. : P

I removed the PP object from my pluggo plugin; and instead went for a (plugmidiin)
This midi object takes a Continuous controller from the timeline of Nuendo, brings it into pluggo and then I routed the data out via udpsend localhost 71. I then received on udp 71 inside max 5 and printed the results,  Everything is fine. every bit of data accounted for under midi. 

I used the same vst pattern for both tests, both the PP and the midi outputed the same number of digits per 2 bar loop . (I believe it was 84 numbers every 2 seconds?)not that many at all. So the resolution is the same with the same rubber band pattern ( only the possible range is different)  ie 0-127 for midi CC and vst (PP) > max is well .... very deep/wide indeed.

so it is unfortunate that i cannot use the vst rubber bands from nuendo and have all that range to play with. i am stuck with midi again..!! :/ 

I may try to simulate a Mac on my PC?? I've heard that done before. unless anyone else here uses pluggo and maybe logic to run a test?? woooo yeah that would be cool to see.  : P  

udp send/receive data loss (pics included)