Try inserting [deferlow] after receipt of the control message.

Here is some useful explanation.

https://cycling74.com/articles/event-priority-in-max-scheduler-vs-queue/

no dice. even reduced to one track, it's still doing the same thing - CPU jump, graphics (VU meters) freeze, small burst of noise.

In theory this shouldn't happen since deferlow gives lowest priority to the API call.

If you change the routing manually, does it produce similar side-effects?

Yes, it does, even changing a single track at a time.

I tried it with an empty set - one audio source, one MIDI track - no problem. But if I run it up to 64 MIDI tracks (that's not the actual threshold, but when I got tired of duplicating tracks), it starts to occur intermittently. Nowhere to the same degree as my main set, which has rather a lot more going on, but it's clearly the same thing.

The volume of the noise is dependent on the volume of my output - if I do the same thing with the source track pulled down, I don't hear it. It's not the source itself, or occurring on the input side - I recorded a loop in and it's still occurring in the same way playing the loop rather than the input audio. I changed to my laptop's built-in speakers, and it switched from occurring intermittently to occurring without fail. Then I deleted half the MIDI tracks, and it disappeared.

CPU usage with one audio clip playing and 64 empty midi tracks is 2%.

I appreciate your efforts to help but I have a feeling we've hit a dead end here...

So we may conclude that changing the routing on the fly is inherently problematic in Live. Perhaps because it triggers some expensive operations like eg. recalculation of delay compensation.

But you could still try to reduce the glitches by increasing the audio buffer size.

It does the same changing audio routings as well... Avoid like the plague!

Cheers D