which language would u suggest for programming externals for max/msp?
i’m using Java for the moment but there seem to be serious CPU problems with Java externals within max.
i’d especially like to programme my own externals for using the kinect.
my 2 cents…
okidoko…thanx a lot…that’s what i heard, too. C is the solution, C it will be ;-)
Hmm, i have a friend who had very, very big CPU problems with a JAVA external he programmed and used in his patcher.
he had crackles in the sound and the patcher crashed regularly – he removed the JAVA stuff and everything works fine.
so he really recommends C….
I use java externals regularly and have no issues, but I don’t do anything audio intensive… Did he try sending his patch to c74 to see if they could identify any issues?
Java is pretty fast if you aren’t passing too much stuff over the Java/native boundary (i.e. between Java and Max). If you’re happy having a JVM installed then you can also use Python, Clojure or Ruby.
Your posts seem a bit like when you already had the answer in your mind and just needed some confirmation ;-)
BTW, my personal experience with Java in Max is that, unless you do some very specific task, there are no serious differences in CPU consumption compared to externals that achieve the same task in C (note that I mentioned ‘achieving the same task’ and not ‘using the same coding solutions’). If there are, that’s usually the symptom of bad design rather than an overall problem with Java. Indeed, to make something efficient, you need to optimize it, and by this I mean, as a first step, that when you design your external you should avoid things that would slow it down unnecessarily. In other words, if the task can be achieved in more than one way (which is usually the situation in complex situations when it is worth to build an external instead of using built-in objects), you should always choose the solution that best suits the actual language and environment.
Hi Nick, I use js object to talk to live.remote~ objects with no (apparent) issue. seems that this is something i need to be thinking about from your post?
So how are things scheduled in this case? Does the entire event sequence get moved off of the high priority thread at the point when a js object is encountered?
Correct – calls entering js/jsui get deferred to low priority.
For better timing accuracy you could look at something Java-based, although then you have the overhead of spinning up a JVM and sending stuff across the JNI boundary. I’ve sequenced with JVM-hosted languages without serious problems.
I’ve never had problems running in js or java either – I guess overall if it isn’t affecting the high priority stuff that is going on then the only cost is extra cpu cycles of crossing the boundaries – this may become more apparent on lower spec machines, buy maybe as the js/java execution environments get better over time this becomes less of an issue… from conversations i’ve had with c74 guys, the gap between the overall performance of js and java is getting smaller over time….
Apart from real-time stuff, this would explain some very anomalous behavior I’ve experienced for several years with my system, some of which I’ve reported on the forums, related to how does one know when a VST has finished loading.
It would also explain why it seemed to take longer to load a VST in my environment than if I just load one raw in a simple patcher.
This is VERY useful info.
I’d be very surprised if that was due to js… If we put this into perspective, whether we’re in the high priority thread or the lower priority thread, we’re still going to be running millions of ops per second… I’m not sure having to put a several second delay into your patch is due to running in js….
It’s not about speed or number of cycles/second.
Deferring the execution changes the order of execution. That can break stuff.
Consider for example the following patcher running in overdrive. The js object simply adds 1 to the incoming inlet and sends out the result. For the very first MIDI event, I would expect (and want) the output (in the max window) to be 3 but in fact I will get 1 because the js object is deferred and so the right inlet of the [+] is still 0
----------begin_max5_patcher---------- 387.3ocyTF0aBBCDG+4xmhl95bj1BBK6s84XwrfPcVCzRn0L2L9cezCXhFVD cpYubDtd2w+62cksdHxb8FggfeF+JFg15gPfKmCT66HRQxlz7DCDFQI9POeE YRyQVwFaiasUHUctUqKzqs4BKjSPqWYFDZc5Oxh6BcgVYUIEB3nWpjI4cmzT A6mkhF8QjJKYxAOvy5UEi7KHRF2mtWGRUmLXsNKSroKkp2eqRjZaJcvS0ofC l5rgQNKm5SwybIryyyYl723yJCdgV6uxLLhXCfnnK.QmjHkUBiPYSrRspG.B inttlECMOs07SwFKGYwwMkAH4T1sfjVLa7L7B2xtt6ULF.Td3s.GkUv8gg.B c.fPOMQtN2khfUffaRO+.lN5Ufv6wJ.+T3fGvAbv8mN.NfuEIWpN9WwP8b9O jQF85pzNw11j382VyDFqTAWw6Eiaz2KnkxrLgp+ZRgLqTW25sZ3WFXiURrQH ov6qhhFojX2OIEOlA2+t41Qj77jT8K679Fv55.ur -----------end_max5_patcher-----------
Quoted from this article
Unfortunately such essential info is not mentioned in the standard documentation.
well, actually you can set
immediate = 1
… ok, here it is
… but in the Max6 doc is stated
Note: Immediate mode has been deprecated as of Max version 6.0.
… ok, forget about that! and then, frankly, C is soooo much better… ;)
I would definitely go C or Java if possible, unfortunately I’m doing m4l stuff so need js to talk to the LOM…..
dhjdhjdhj, i see your point… you could always defer the input in this case – midi is control rate, not audio rate after all….
But I think if you defer the midi input, scheduling at control rate (1 ms) is not applied anymore which may result in unpredictable latency.
Defering MIDI processing is not an option. MIDI event processing has to be done in real time otherwise the results will be very sloppy.
would like to know what issued caused c74 to drop the ability of running js in the high pri thread…..
yeah, i would think something along those lines, would be interesting to know exactly what tho….
Have a look at Rhino (the JS engine for the JVM); this might run JS code at high priority.
which js engine is currently used? I read somewhere it was SpiderMonkey… are you saying that it is Rhino or just to take a look at Rhino?
It might therefore work at high priority (as well as in the UI thread).
I’ve been experimenting with the "immediate" stuff in Max 5.1.9 and it completely solves the issues for which I had used artificial delays and defers as hacks.
However, even though I’m not able to switch over to Max 6, I’ve made sure so far that all my patchers do work in 6. If I start using "immediate", I’ll break that migration path.
Is there something different I have to do to get the high priority behavior with Max 6 and Rhino? If so then I’ll just isolate my changes as much as possible.
Can someone from c74 pls shed some light on this and also why the behaviour was changed between 5 and 6 – seems like a bit of a backwards step…
Rhino as engine in Max would be awesome. This would enable us to use the Max 4 Live API within Java too (same for all the other JS APIs in Max). This would allow some really cool coding.
Also, if calling js caused a crossing from max into java it would make it more expensive to call…