quatro

I was disappointed by huge lag caused by send/receive communication between m4l devices. I've had several ms and considered this intolerable for midi data

I'm currently using js Global object for storing data and transport-triggered listener function checking for new data every tick. And it works. I also needed to insert defer object after transport object to make it ok. A bit too cpu intensive but nothing special

I wonder if you ever had better solutions

I have no idea how send/receive were made so badly

I was disappointed by huge lag caused by send/receive communication between m4l devices. I've had several ms and considered this intolerable for midi data
I'm currently using js Global object for storing data and transport-triggered listener function checking for new data every tick. And it works. I also needed to insert defer object after transport object to make it ok. A bit too cpu intensive but nothing special
I wonder if you ever had better solutions
I have no idea how send/receive were made so badly


interdevice-communication-without-latency

Doesn't it induce potential latency again?

I wonder why you need the defer object.
Doesn't it induce potential latency again?


I've had the oposite result with js. When the system bogs, all js activity gets put on the backburner until the system catches up. I'm using js as little as possible for timing critical operations, and pure max for the rest. I actually get pretty accurate send/receive functionality. My main problem with interpatch send/receive is that if you send too much information, the receive object will break.

What operating system/hardware are you using?

regarding @broc: yeah, I have to mention that the defer should be redundant. If you are using js, its already lo-queue, unless you have set immediate=1 in globals for the js. My experience using immediate is that multiple versions of the same js will crash Live/Max.

Have you tested this very extensively? I'm not just being a naysayer, I am genuinely interested in your results.

I've had the oposite result with js.  When the system bogs, all js activity gets put on the backburner until the system catches up.  I'm using js as little as possible for timing critical operations, and pure max for the rest.  I actually get pretty accurate send/receive functionality.  My main problem with interpatch send/receive is that if you send too much information, the receive object will break.

regarding @broc:  yeah, I have to mention that the defer should be redundant.  If you are using js, its already lo-queue, unless you have set immediate=1 in globals for the js.  My experience using immediate is that multiple versions of the same js will crash Live/Max.  

Have you tested this very extensively?  I'm not just being a naysayer, I am genuinely interested in your results.


Can you post the javascript code you are using? I'm interested in inter-device communication as well!

I used defer between trigger and js listener. Otherwise some kind of awful jitter was introduced in midi output

The system is not bogged at all. This makes me wonder how send/receive can be so slack. I've tried to implement the same send/receive without js and I've got exactly the same latency, 6 or 7 ms

I use dual core and XP. My audio device is DirectSound but I don't think this should affect internal Max processes in any way

xanadu, nothing special. Just receive objects on both sides and messnamed js function for message exchange.
Is this exhaustive explanation?


 so I wonder why you need it. Isn't that inducing potential latency again, doesn't it?

The defer object seems to be unnecessaryhttps://essentialsclothing.co/ so I wonder why you need it. Isn't that inducing potential latency again, doesn't it?

Interdevice communication without latency