Live API calls thread priority and performance: Python MIDI remote scripts vs Max For Live JavaScript calls

Learn about building and using Max for Live devices.
Post Reply
jbone1313
Posts: 578
Joined: Wed Dec 12, 2007 2:44 am

Live API calls thread priority and performance: Python MIDI remote scripts vs Max For Live JavaScript calls

Post by jbone1313 » Tue May 30, 2023 5:10 pm

I am searching for DEFINITIVE answers to the below questions. As you can see below, I have searched the internet far and wide, and I cannot find anything definitive.

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:
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 the Ableton 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 Cycling '74's 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.
From this link in the Ableton forum:
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.

chapelier fou
Posts: 6011
Joined: Mon May 15, 2006 12:15 pm

Re: Live API calls thread priority and performance: Python MIDI remote scripts vs Max For Live JavaScript calls

Post by chapelier fou » Wed May 31, 2023 10:44 am

Ok, this will not be a DEFINITIVE answer, but from my experience :

JS : extremely slow, can be overflowing quickly.
M4L : slow, but robust. latency is unpredictable.
PYTHON : super fast. If I knew Python, I would ONLY use it (when I don't need a GUI).
MacBook Pro 13" Retina i7 2.8 GHz OS 10.13, L10.0.1, M4L.
MacStudio M1Max 32Go OS 12.3.1

Trevor being Trevor
Posts: 8
Joined: Thu Apr 21, 2022 2:51 pm

Re: Live API calls thread priority and performance: Python MIDI remote scripts vs Max For Live JavaScript calls

Post by Trevor being Trevor » Sun Jun 25, 2023 5:11 pm

Replying mainly because I could benefit from more info on the Live API too. Based on what you posted, it seems like they both run in the low priority thread. My understanding is that Live treats API calls in general as low priority so it can't get overwhelmed as it focuses on processing audio, etc.

jbone1313
Posts: 578
Joined: Wed Dec 12, 2007 2:44 am

Re: Live API calls thread priority and performance: Python MIDI remote scripts vs Max For Live JavaScript calls

Post by jbone1313 » Sun Jun 25, 2023 5:44 pm

I have been meaning to come back and update this thread after I get to a more certain place in my implementation, but here is what I have confirmed so far in my research and testing:

If you use live.remote~ at signal rate, then the target parameter is effected at audio rate with high priority. To do that, you can simply convert incoming float values with a sig~ object.

The latency of live.remote~ is FIXED to the audio buffer, and it is NOT subject to additional latency induced by plugins. However, that fixed latency is not compensated, which is crazy since that latency happens even in Ableton’s Expression Control device, and probably all users are unaware of that. Ableton ought to latency compensate live.remote~ if at all possible or at least document it conspicuously so that users are aware.

Given the above, I am confident enough to invest the time to try to implement my project in Max For Live.

My one open concern is that live.remote~ objects cannot be added dynamically/programmatically, so since I want to allow for “unlimited” mapping with my device, then I must instantiate a ton of live.remote~ objects when my device loads. In my testing, it was no problem instantiating like 10k live.remote~ objects, but we will see how it pans out in a real implementation. I really wish Ableton would allow dynamically instantiating live.remote~ objects.

Post Reply