I just downloaded your files and tested them out, even with a buffer size of 128 samples there are no clicks and pops. so I think its your buffer size settings, to try it out put the buffer size for your soundcard on 2048 samples. Having an external soundcard is a must with heavy sets. I use osX 10.6.8 with a presonus firestudio card. Live.9.05. Soi its not a bug. Stick with 32 bit (thats what i used) 64 bit is still flakey with other VSTS and so on.. Also disable all the inputs and outputs you don't use with your soundcard. Try it with all external usb devices not connected as well. Hope this helps

I'm not saying you're wrong, Andro, but you are using a different version of live than Martin is; it *could* theoretically still be the issue.

Hi Andro, hi Wetterberg, thank you very much for testing! My standard interface is a fireface 400 (I installed newest firmware and drivers). So I use an external soundcard already. I tried different buffersize settings, too - it sounds better with a higher setting, but should work also with a lower setting. E.g. with 64 bit it doesn't click, when the tempo change is over. Today I tried my set on another machine running OSX 10.8.2 with Live 9.05 64 Bit without any problems! That's why I believe now, that this problem is OS related. I personally run the newest OSX (10.8.5) and I experience these issue since a while, maybe since 10.8.4. That would explain, that Ableton support couldn't reproduce it (maybe they use another version), but cycling74 support could reproduce it at the end with the 32 bit Version of Live 9(!). You, Andro couldn't reproduce it with 32 Bit - quite confusing. I shall ask them, which OS versions they use and post it back here. So thanks again, Martin

Cycling74 support uses 10.8.5, too. So it seems to have nothing to do with different OS versions. The initial point for my support request to cycling74 were problems with the line~ object, which definitely has a bug on tempo changes. It puts out bangs on the right outlet without any purpose. This seems to trigger CPU spikes and could lead to the clicks (even, if the bangs are filtered). This was introduced in Max 6.1.3 (I'm not totally sure). Cycling takes a look on it and I hope, that this is the main reason for this issue. In my dummy-set in the original post I included lots of dummy devices with line~.

After some time I come back to this problem, because it still exists. Some max objects create glitches / dropouts in combination with tempo changes. I just bought a new Mac Book Pro in hope of getting rid of this problem, but there is hardly any improvement in comparison to my 4 years older machine. I ask you for trying the attached live-set (please use a Buffersize of 128 Samples). In bar 1 everything sounds great. The accelerando starts in bar 2 - now the problem begins. In bar 13 everything gets back to a good sound (tempo changes are over). The used "DummyDevice" contains a line~ which causes the problems. I also tested most other Max objects. All marked "not good" objects cause the problem (even some Max-only objects), the others don't. You can test it by altering the device. In the set 100 dummy-line~ devices are used - this happens for example in real life, if you run a max-made little sampler with buffer~ line~ and play~ and you use 100 voices (which is absolutely not much).

On my new MacBook Pro (Mid 2014, 2,5 GHz) I get about 10% CPU without tempo changes and 14-17% during the accelerando (I use a buffer size of 128 samples). Normally I shouldn't get any dropouts. I tested it with the internal sound card and my RME Fireface 400 (no difference).

Hi all, I have the some problem and can recreate the error. all the best Frank

Clicks? is a kind of hearing test.. pretend they are not there :) or use laptop speakers, sometimes disappear!!!.. I wish you luck with that!!!

All MaxForLive Users, who ever use tempo automation should try this! It's a fundamental Max problem. Thank you Frank and Barbara for checking the set. @Frank: good to have a confirm. Which machine / system are you using? @Barbara: You should listen to it with headphones. The sound is rhythmically distorted / broken. If you don't have this experience (at buffersize

I attached a new set to reproduce the error which uses a basic 1-voice operator and 6x10 Max For Live Building Block gain devices. TestTempoSweepBug_BasicOperatorAndM4L_Gain.als Please try this with a buffersize of 128 Samples. If you use higher buffer sizes you have to increase the amount of devices.

For comparison I attached a second live-set (TestTempoSweepBug_BasicOperatorAndLive_Utility.als), which is made without MaxForLive. It uses the same operator and tempo automation together with 6x10 Live Utility devices (doing gain changes, too). About 75% less CPU and absolutely no distorted / broken sound.

I'm thankful to everyone, who can test this and write about her/his experiences.