phillip dempster

This device causes audio dropouts when recording, even at very low cpu usage. Does anyone have suggestions to avoid this?

Even when grouped in an audio effect rack, with an empty chain passing dry audio through and this device on a separate muted chain, it will still cause dropouts on the master output.

Tested on two different computers, same result:

Tested on two different computers, same result:
1) Win10 64bit / Live 9.6.2 / Max 7.2.2
2) Win7 64bit / Live 9.5 / Max 7.2.2

dropouts-caused-by-recordbuffer

Oh I should probably clarify, its a device I created. Basically it's for recording ideas and practice runs to RAM, with the option of saving it to disk if desired. Wanted to avoid periodically cleaning up piles of unused audio files.

Also, I've just realised that it works fine, no dropouts at all, when in max edit mode.

I notice that windows task manager indicates that the processing and RAM usage occurs as part of the max.exe thread when in edit mode, as opposed to 'ableton live 9 suite.exe' when loaded normally.

Also, I've just realised that it works fine, no dropouts at all, when in max edit mode. 

I notice that windows task manager indicates that the processing and RAM usage occurs as part of the max.exe thread when in edit mode, as opposed to 'ableton live 9 suite.exe' when loaded normally.


Okay, I have found a workaround that is fine for my purposes.

I'm now using sfrecord~ to record to a temporary .aif, which is then loaded into the buffer~ when recording is stopped.

Dropouts caused by record~/buffer~?