Quite a while ago I found that some of my sessions would show a massive CPU increase by simply arming (or input-enabling) the stereo track I print my mixes to. One session in particular, would go from maybe 20%, to near the top of the meter, which on a 3.33 12-core is no mean feat. Most of these sessions have instrument tracks. It turns out that a default midi preference is the cause.
One session had three instances of Ivory, which can be a bit of a CPU hog. The VI tracks, along with quite a few audio tracks were routed to the master fader, and then to the print track. Enabling the print track dramatically increased CPU usage, far more then enabling a single track would ever be expected to. But if I de-activated the Ivory instances, the issue went away. It was obvious to me that the VI tracks were being thrown into the low buffer, but I could not figure out why. They were just playback tracks, and not record-enabled.
It turns out that a default Preference setting for midi-thru in was set to something other than "none". When set that way, VIs will go into the low buffer if something down the audio path "thinks" it requires real-time-performance. Clearly a playback-only track does not. PT should understand this, but apparently it does not. Setting the pref to "none" completely eliminates the problem.
"Boobytrap" is the only term that fits something like this. I would like to suggest that this pref default be changed to "none". Users can still select "midi-thru" from the Options menu on the fly, so nothing should be lost. If you are having CPU overload issues, and you use midi, you might want to look into this.
One session had three instances of Ivory, which can be a bit of a CPU hog. The VI tracks, along with quite a few audio tracks were routed to the master fader, and then to the print track. Enabling the print track dramatically increased CPU usage, far more then enabling a single track would ever be expected to. But if I de-activated the Ivory instances, the issue went away. It was obvious to me that the VI tracks were being thrown into the low buffer, but I could not figure out why. They were just playback tracks, and not record-enabled.
It turns out that a default Preference setting for midi-thru in was set to something other than "none". When set that way, VIs will go into the low buffer if something down the audio path "thinks" it requires real-time-performance. Clearly a playback-only track does not. PT should understand this, but apparently it does not. Setting the pref to "none" completely eliminates the problem.
"Boobytrap" is the only term that fits something like this. I would like to suggest that this pref default be changed to "none". Users can still select "midi-thru" from the Options menu on the fly, so nothing should be lost. If you are having CPU overload issues, and you use midi, you might want to look into this.
Aucun commentaire:
Enregistrer un commentaire