Hi David!
However, to get it to run well on my new Dell laptop running WinCrap XP, I had to go CTL-ALT-DEL, open up processes, and set the priority of chuck.exeto "realtime". Otherwise, when I create and delete shreds, I was getting unwanted glitching. Is there some way to automate this process, so that chuck always has realtime priority? A command line flag would be really helpful I guess.
On windows, there isn't a way to automatically boost the priority (and usually shouldn't have to). This glitching on windows seems to be a new feature of 1.2.0.5. One way to alleviate the problem is to specify a larger audio buffersize (which will increase your latency, but doesn't matter too much if you aren't using interactive input, like joystick, kb, etc.): > chuck --bufsize2048 for example, sets the buffer size to 2048. Try different powers of two.
Also, is it normal for me to need to do this?
Hmm, one shouldn't have to do this... We hope to track the cause down for the next release. It may have something to do with loading sound files, the implementation for that did change a little. Do these shreds that glitch load sound files?
Strangely, despite maxing out the CPU, on an old PIII desktop with only 256 MB RAM (as opposed to 1 gig on the laptop) I had no problems like this and creating and deleting shreds occurred very smoothly. That was with a clean install of WinCrap, however.
That is strange, were both computers running the same version of chuck? If not, you might try running the PIII chuck on your new computer. We hope to fix this soon. Best, Ge!