Intermittent Loss of Transport Control

Dave,

I haven't seen that here _yet_.  I've been doing a lot of testing with very large projects (I find them the best to shake things out with) and the transport has been fine so far.

ba_midi


Are you seeing it on more than one project?

If not, watch those tiny animated CPU meters to see if anything is 'taking over'.

I had one project in 8.5.3 that had one plugin causing serious weirdness (probably a denormal issue) and it took a while for me to figure it out because I wasn't watching the meters when it would cause this drastic bump in cycles.

Thanks for the feedback, Billy. Interesting points. I've mainly been testing with two demo project becasue they are complex enough to really see how stuff works. Lance's project gave me the most trouble in this respect, especially the 9-bar lead-in. The tranpost would run right up to the end of the last lead-in bar, and then stop.
 
I have an idea now that it might be related to disk buffering. When I first saw this, I was running projects off my usual audio drive with 256kB I/O buffers, and disk load staying under 25%. This morning for grins I put the Cori Yarckin demo on my new cheapo USB 2.0 external drive that I bought with money saved by not ordering the physical kit for X1 . It ran fine with 256kB I/O buffers, peaking at about 62%.
 
I lowered the buffer to 128kB, and things still ran okay (somewhat surprisingly) until I set up to loop about 8 bars. The loop would run right up to the end, and then the transport would just stop. It was quite repeatable, and after a few passes, I noticed that the disk icon was flashing red when the transport stopped, from which I concluded I was getting a dropout due to disk load when SONAR was preparing to jump back to the beginning of the loop.
 
It may be that something like this was happening with my regular audio disk when getting to the beginning of audio track in Lance's demo, though it shouldn't have been a problem with the disk running at a nominal 20%. Next time I see it happen, I will check the disk load.
 
Denormal errors are also a possibility, as I turned off denormal protection a while ago, 'cause I didn't like seeing all the "noise" in BitMeter.   I probably shouldn't have done that. I never encountered a problem with it running that way for the last 6 months or so in 8.5, but it may be that there's something in Lance's project that's causing them.
 

ZeroFillMethod=0 in AUD.INI. I think the default is 2, but I don't know what the different "methods" are other than that 0 disables it.

Strangely, the thread I learned about this from is no longer accessible:

forum.cakewalk.com/tm.aspx?&m=2054046

You can find links to it by Googling "clone transparency flaw" site:forum.cakewalk.com, but none of them work.

Brundlefly, stop / run the audio engine works to work around this. And you don't have to kill sonar.

Wow. Blast from the past. Yeah, Billy was a good guy. IIRC, it turned out there actually was some issue in X1 that Lance's demo project exposed. But I also changed interfaces not long after that, and haven't seen the unresponsive transport thing since. And FWIW, I definitely would have tried resetting the audio engine before killing SONAR, but that doesn't usually do anything when the transport's running.

I narrowed this issue down to the fact that I was using a wireless Keyboard/ mouse combo. I like it so I can move away from the workstation for vocals.. but it can be none responsive and sluggish. 
You type and there is a delay. 
So I now have both hooked up, a wired and the wireless.