'Esc' (Stop All) acting differently (fix in 10.6.0)

[trs]

I just upgraded to 10.5 because of something I noticed SCS doing since I downloaded 10.4. If I hit 'Esc', instead of going back to the start of the cue that was running, things are being reset to the first cue. I've never had this happen before, and I've been running SCS for over two years now. I'm running an HP laptop with Windows XP. Any idea why this is going on? Is there any way to change this? Thanks.

[Mike Daniell]

Shouldn't be doing that. SCS should position the cue list at the first cue that was stopped by 'Esc', so it should only go back to the first cue if that cue was still playing at the time. What is displayed in the 'State' column for the first cue immediately prior to hitting 'Esc'?

[Boswell]

Hi Mike,
It does it with me as well. If I take say Q122 (Audio) which is running (looped), all previous cues are completed, then 'ESC' stops Q122 and takes me back to Q14
making it and all following cues ready but leaving q1-13 completed
Running 10.4.1 on XP SP3 (32bit) on AMD Turion64

Never noticed it before as I don't use 'ESC' very often!

Boswell

[trs]

The state is listed as completed. It might be a computer issue. It does this on my laptop, but not on my tower. The laptop is a 32 bit XP, the tower is 64 bit XP.

[Mike Daniell]

Using additional information supplied by Boswell, I found that this error can be caused by having a disabled cue earlier in the cue list. What can happen (depending on the structure of that disabled cue) is that after 'Stop All', SCS repositions the cue list at the first enabled cue after the disabled cue, not at the first cue that was stopped by 'Stop All'.

A fix is ready for the next release, but let me know if you need this sooner.