Regarding speed with javascript

    Dec 14 2012 | 8:30 pm
    I really like working with js in max, but i'm wondering how far i can go with it. Where does using js become not the best choice anymore?

    • Dec 15 2012 | 11:30 am
      That question is so open ended I'm surprised half the letters haven't drifted off! But in all seriousness it depends what exactly you are trying to do. To make a major and questionable generalisation if you are doing anything that is exceedingly time sensitive or involves crossing the max/js barrier very frequently then you might want to re-think your approach. However if you're not experiencing any problems then you're probably fine to keep on going in javascript. It's very good for some things like patcher scripting and it is quite a nice step up to learning java or C if you're coming from a non-programming background. Do you have any specific issues you are running in to? Or are you just worried about future developments?
    • Dec 15 2012 | 2:34 pm
      Sorry, that was quite a vague question indeed. :) I deleted some stuff from what i had originally typed, and didn't check what was left after that.
      I have a programming background and really like doing stuff in max with js, but i am indeed wondering if i should use it for time sensitive stuff. I am worried that any issues will not be very noticeable, and that later on it might just be 'somewhat not in sync'. I am planning to make a beat-slicer/reshuffler, where i intend to have groups of samples that have a chance of being played on a certain step in a sequence. So all i'm doing in js will be doing some random selections in arrays, resulting in an index of the sample to be played, which will be converted to a message to line~ so the correct part of the full sample will be played. This all will be triggered by the beat, so probably from a metro. This isnt all too much in js, but maybe someone advices against any use of timesensitive js at all, no matter what you do.
    • Dec 16 2012 | 8:58 am
      I could be wrong about this, so someone please correct me if I am, but I think everything running through js ends up in the deferred que in Max6. This makes triggering events by running a call through js less than timing-accurate. Array manipulation is incredibly handy, but you might want to send the manipulated arrays out to [coll], and then trigger the data via [metro] (e.g.) so that things happen immediately.
      I tend to use js these days for UI and scripting inside patchers (it's great for that!), but leave all the heavy lifting to native Max objects, java, or gen~. Resultant values can always be fed to pattrs, whose value can be retrieved in the js using this.patcher.getnamed('whatever').getvalueof().
      However, if your input to or output from javascript is already deferred, you won't gain anything by avoiding js.
    • Dec 16 2012 | 1:07 pm
      I could be wrong about this, so someone please correct me if I am, but I think everything running through js ends up in the deferred que in Max6.
      From what i read ( you can force a js-function to be executed in the high-priority thread by setting 'immediate = 1' on a js function.