Forums > Max For Live

Changing current_output_sub_routing makes sad times

March 13, 2012 | 11:09 pm

Hi,

I’ve created a patch that changes the output MIDI channel of five tracks at once upon receipt of a control message, and it makes my CPU usage jump about %9 or so and a burst of digital clicks, even if those tracks aren’t outputting anything at the time. Any way around this? (I’ll try spacing the five changes, but that’s sub-optimal and this seems like it shouldn’t be happening anyway). Thoughts?

Cheers,
Adam


March 14, 2012 | 10:16 am

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

Here is some useful explanation.

http://cycling74.com/2004/09/09/event-priority-in-max-scheduler-vs-queue/


March 15, 2012 | 4:17 am

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


March 15, 2012 | 6:15 pm

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?


March 16, 2012 | 5:38 am

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…


March 16, 2012 | 11:06 am

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.


March 16, 2012 | 12:54 pm

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

Cheers
D


Viewing 7 posts - 1 through 7 (of 7 total)