Damon

I’ve been doing some initial tests of the new node.script object and have been quite heartened by what I’ve seen. My tests have been quite simplistic (not much more that metro bang in -> message out), but as far as I can tell, the reliability of the timing is quite good. In the old js object, simply typing in a number object somewhere in the patch would be enough to cause a hiccup. The timing in node.script, however, seems to be solid and consistent.

I understand that I can’t expect compiled Max object level of performance, but with that caveat, can we really now use JavaScript (in the node.script object) for events where timing is important? Please oh please say it's true...

I’ve been doing some initial tests of the new node.script object and have been quite heartened by what I’ve seen. My tests have been quite s

node-script-and-timing-reliability

From the Facebook Max/MSP group, see the following:

I know that the js object can't handle precise timing or intense cpu stuff because its in the low priority thread but is Node the same way? If I run the same script in the Node object, will the performance be better and can it handle rapid, precise timing?

as a heavy user of nodejs in other circumstances (dealing with high data rates) I’d caution that it’s not usually great at this. timing can be off because whatever is currently being processed has to finish before the event loop can trigger the timer(s). and under high load the phenomenon of “event loop starvation” where the async processing basically all gets held up behind other stuff can be a big problem. we love nodejs and use it a lot but i wouldn’t rely on it for precise timing especially if it’s under heavy load.

Question about Node.
  I know that the js object can't handle precise timing or intense cpu  stuff because its in the low priority thread but is Node the same way?  If I run the same script in the Node object, will the performance be  better and can it handle rapid, precise timing?

Paul Pradip:
 as  a heavy user of nodejs in other circumstances (dealing with high data  rates) I’d caution that it’s not usually great at this. timing can be  off because whatever is currently being processed has to finish before  the event loop can trigger the timer(s).  and under high load the phenomenon of “event loop starvation” where the  async processing basically all gets held up behind other stuff can be a  big problem. we love nodejs and use it a lot but i wouldn’t rely on it  for precise timing especially if it’s under heavy load.

I'm not sure that this addresses my question. It sounds like this refers to JavaScript timing objects (setTimeout, setInterval). I’m aware that these are not reliable in any context. What I’m curious about is direct message processing. That is, sending a message to the node.script (whether it’s a standard message like bang or creating custom handler) and having it come out the other end in a reliable time

I don't think I can give a final answer, but I'll try to be as complete as I can. However, the short answer is that neither object can make any strong assertions about timing accuracy. The JS object defers output to the back of the main thread, so computations in other parts of the patch could affect timing. The node.script object sends messages to a separate process, so there will always be some latency associated with the functions that send + receive messages between the Max process and the Node process.

In practice, you should use whichever one works for you. I'm curious to know exactly what you're trying to do, as there are some things you could try that could make timing more reliable. For example , I've been experimenting with using node.script to send video frames back to Max for display, and I've found that the best way to get smooth, even rendering is to synchronize the messages coming back from node.script to a 60fps timer inside Max.

I don't think I can give a final answer, but I'll try to be as complete as I can. However, the short answer is that neither object can make any strong assertions about timing accuracy. The JS object defers output to the back of the main thread, so computations in other parts of the patch could affect timing. The node.script object sends messages to a separate process, so there will always be some latency associated with the functions that send + receive messages between the Max process and the Node process.

In practice, you should use whichever one works for you.  I'm curious to know exactly what you're trying to do, as there are some things you could try that could make timing more reliable. For example , I've been experimenting with using node.script to send video frames back to Max for display, and I've found that the best way to get smooth, even rendering is to synchronize the messages coming back from node.script to a 60fps timer inside Max.

At the moment I’m not trying to do anything, I’m just trying to evaluate the object’s usefulness. The js object’s utility was extremely limited by the fact that you can’t count on things happening in a consistent manner (due to, as you pointed out, blocking on the main thread) so that you couldn’t use it for anything where timing was even remotely important. Even the simplest of js object scripts in the simplest of Max patches can hiccup with a minor bit of UI interaction.

My initial tests with the node.script object, in contrast, have not demonstrated this inconsistency. At this point all I’m trying to figure out is if I can trust that a message sent in one end of node.script will come out the other end in a predictable amount of time (based on how much work the script is doing, of course). As in your example, I am talking about a Max timer object of some sort being responsible for the timing and the node.script object merely processing that message as fast as possible.

So, while my simple test are positive, I’m just curious to see if anyone has any experience that would suggest that this will in fact scale once the patch gets more involved. I’m guessing that since the script runs on a separate thread that we should be in good shape. But I was hoping to hear from someone who has made a more complicated real-world patch that had a node.script object somewhere in the path of a message to which timing was important. It sounds like your 60fps video patch is a data point in the object’s favor. Thanks.

My initial tests with the node.script object, in contrast, have not demonstrated this inconsistency. At this point all I’m trying to figure out is if I can trust that a message sent in one end of node.script will come out the other end in a predictable amount of time (based on how much work the script is doing, of course). As in your example, I am talking about a Max timer object of some sort being responsible for the timing and the node.script object merely processing that message as fast as possible. 

Could you put that script that, i suppose from your comment,

take video frame through node and output it to jitter world?

Hi sam,
Could you put that script that, i suppose from your comment,
take video frame through node and output it to jitter world?
Thanks


node.script and Timing Reliability