@eblomquist, I’ve migrated your crow m4l glitches to this thread. knowing this info is helpful, thank you! easy to replicate.
detailed explanation: this is actually a byproduct of how the [crow] Max object operates – messages to crow are purposefully put into the low-priority queue (using the [deferlow] object). this is a protection from crashing because of the way that [jit.gl.lua] is currently working in Max (it crashes if it’s hit with a lot of scheduler messages, but remains stable if messages are in the low-priority queue). so, when you perform a higher-priority task in Live (like saving), the low-priority messages going to crow are shuffled around to make sure that high-priority task is completed. this isn’t a performative issue 95% of the time you’re just running sequencers and letting them do their thing – but yeah, if you try to do a system-level task, Max will purposefully prioritize that over the crow messages.
tl;dr: this was assumed to be an unfortunately necessary tradeoff for crow m4l to work. if you want to help us play with fire, here’s a version of ^^command_center which won’t purposefully slow down when you do system-level things in Live: ^^command_center.amxd (56.0 KB)
fwiw, I’ll also be testing with this approach to see if we can get away with it in a high-traffic Live set.
edit pt 1: it’s going really well so far!! thank god.
edit pt 2: ehhh, stopped going really well once I had more than 4 devices running. so, there’s the tradeoff. I think it’s best to stay with pushing things to low priority queue for the sake of overall stability.
