Ginge70 Posted May 25, 2015 Share Posted May 25, 2015 Hi! I have a 64-track orchestral mix that LPX just can't play through without stopping with a "Disk is too slow or System Overload" message. This is a project that runs fine in LP9 with no stops at all, which leads me to conclude that this is not a disk I/O issue, - my RAID is not too slow. At first LPX was stopping as soon as the playhead got close to the block of 64 audioregions and by watching the CPU-meter in LPX I could see that the first of the 24 cpu-meters was spiking. There was only significant activity on the first and last of the CPU-meters, the others were showing some movement, but far from as much as 1 and 24. If I started in the middle of the song the first two or four CPUs would spike. I was suspecting real-time fades to be the culprit, but removing all fades did not help in any way, neither did increasing I/O Buffer Size to 1024 nor switching Processing threads from automatic to 24. I was using Large Process Buffer Range and switching this over to Small almost solved the problem, LPX now plays through portions of the song as long as it is not encountering any edits. As soon as it reaches a spot where I've pasted in a new take, where a block of 64 new audio regions begin, LPX stops. And there are no fades between the regions, mind you. What puzzles me is that LPX has no issue whatsoever with handling the huge orchestral mockups I make before I record the real thing. I've lost count of the number of vienna and kontakt instances and LPX is playing them without a complaint at all. There seems to be no limit to how big the projects can be, but when I throw a measly 64-track orchestral mix at it, it just can't cope. Any idea on how to get the same performance from LPX as LP9? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.