It is clear from this link in the Max For Live documentation that Live API calls made through Max For Live JavaScript run in the low-priority thread. And, there is also this link in the Max For Live documentation, which states that, "The LiveAPI object cannot be created or used in the high-priority thread."
However, some say Live API calls made through Python MIDI remote scripts ALSO run in the low-priority thread. But, others report the opposite.
Can someone kindly please confirm the answer to these questions:
1. Do Live API calls made through Python MIDI remote scripts run in a low-priority thread?
2. Is there anywhere this is documented? (I am aware of Ableton's Python MIDI remote script no support policy, but this is more of a meta question around whether or not ANY/ALL control surface scripts run in a low-priority thread.)
3. Is there a difference in performance between Live API calls made through Python MIDI remote scripts versus Live API calls made through Max For Live JavaScript?
Why I am asking these questions:
I am looking to port a Python MIDI remote script I developed to Max For Live. I am happy with the Python MIDI remote script's performance; therefore, IF BOTH the Live API calls made through Python MIDI remote scripts AND the Max For Live JavaScript Live API calls run in the low-priority thread, then obviously I can be confident that, all else equal, I will observe the same performance in Live API calls made through Max For Live JavaScript AND Python MIDI remote scripts.
Below is all of the information I have found, and it clearly seems inconsistent.
From this link in Cycling '74's forum:
From this link in the Ableton forum:any Live API calls should come from a low thread object anyway as they will get deferred to the low thread, so using JS for Live API calls is fine. This is the same as the Live API for Python control surface scripts btw - all control surface actions are running in a lower priority thread.
From this link in Cycling '74's forum:the speed of the access to the live api between python access and m4l access - this is what is the same. you can control it with the same speed and accuracy, which is not great as it all happens in the low priority thread, although this is fine for most use scenarios. this is the same in live (python) as it is in m4l (max patching or javascript).
From this link in the Ableton forum:In Ableton's parlance, a "control surface" is actually a script in Python that runs under the control surface plugin model and can interact with Ableton using it's API, which is really the same as the Max4Live API, just in Python. This plugin layer runs in a low priority thread in Live, handling input from midi controllers but then doing stuff to live directly in Python (arming tracks, selecting tracks, etc etc), without needing any kind of midi mapping from the end user.
From this link in the Ableton forum:Macros and everything else I've described works across projects at the Control Surface Level which is a high priority thread as opposed to Max4Lives low priority thread.
From this link in the Ableton forum:I made a comparison between JS and M4L both accessing to a control surface. Just 2 faders mapped to track volumes.
The JS part sucks. The plain M4L part works tight.
You don't want to use javascript for anything audio related or timing sensitive. It runs in the low priority thread and isn't suitable for DSP tasks.