I just had a chance to try out 9.4.1, Mike. Awesome work! The zoom functionality is fantastic. Setting loop cues has never been easier.
I do have a potential issue for you, though, regarding loop release. I have a show where I can use it, and I'm having a little trouble getting it to release on demand. That is, if I release the looping cue too close to the end of the loop, it loops one more time. (If I release early on, it seems to work as expected.) But, in my case, for example, if I release the loop within, say even 3 seconds of the loop end, it goes around one more time.
When I fire the Release Loop cue, the cue dutifully fires (shows "Releasing" in the cue status), and in the Looping cue display, the "Loops" flag changes to "Loop released", (however, I noticed the Release Loop Button does not gray out). But, even after releasing the loop, when the progress hits the loopback point, instead of continuing on, it loops back one more time. I would think it should release immediately after the current loop end is found regardless of how close to the end the release loop is fired.
The delayed release is the same whether the cue is run in the Editor or in Production mode, or whether a Release Loop cue is fired, or the Release Loop button is clicked.
Let me know if you need a sample file.
Thanks Mike!
9.4.1 Loop release issue
-
Mike Daniell
- Site Admin
- Posts: 3629
- Joined: Sun Jul 24, 2005 8:58 am
- Location: Brisbane, Queensland, Australia. TZ:GMT+10
- Contact:
Thanks for your compliments, Dan. I'll have a look into what I can do about the loop release issue. A bit of an explanation will help though.
SCS reads ahead in the audio files, and the amount ahead it reads is determined by the size of the playback buffer (see View /Options / Audio Driver). SCS therefore has two pointers - the first pointer is the file reading position in the audio file, and the second pointer is the 'what you are hearing' position in the playback buffer.
The second pointer is used to place the marker on the progress slider and to display the count up and count down timers.
One of the uses of the first pointer is to determine when a loop end point is reached in the file so that reading can be reset to the start of the loop.
So the first pointer can be ahead of the second pointer by up to the length of the playback buffer. Suppose your playback buffer is 4000ms (4 seconds). This means that the file reading (first pointer) will loop back to the start of the loop up to 4 seconds before you hear the end of the loop. So if you release the loop within 4 seconds of the end of the loop, unfortunately (?) SCS has already started reading back from the start of the loop so the program has to wait one more cycle of the loop.
If you reduce the playback buffer time you will reduce this window that causes the extra cycle of the loop, but I'm sure you're aware that reducing the size of the playback buffer too much may cause stuttering in the playback due to buffer underrun.
I will see if there is any way to effectively flush the data from the beginning of the loop and jump to the point after the end of the loop, but I don't know if that will be particularly easy.
What should be easy is finding out why the loop release button doesn't get greyed out!
SCS reads ahead in the audio files, and the amount ahead it reads is determined by the size of the playback buffer (see View /Options / Audio Driver). SCS therefore has two pointers - the first pointer is the file reading position in the audio file, and the second pointer is the 'what you are hearing' position in the playback buffer.
The second pointer is used to place the marker on the progress slider and to display the count up and count down timers.
One of the uses of the first pointer is to determine when a loop end point is reached in the file so that reading can be reset to the start of the loop.
So the first pointer can be ahead of the second pointer by up to the length of the playback buffer. Suppose your playback buffer is 4000ms (4 seconds). This means that the file reading (first pointer) will loop back to the start of the loop up to 4 seconds before you hear the end of the loop. So if you release the loop within 4 seconds of the end of the loop, unfortunately (?) SCS has already started reading back from the start of the loop so the program has to wait one more cycle of the loop.
If you reduce the playback buffer time you will reduce this window that causes the extra cycle of the loop, but I'm sure you're aware that reducing the size of the playback buffer too much may cause stuttering in the playback due to buffer underrun.
I will see if there is any way to effectively flush the data from the beginning of the loop and jump to the point after the end of the loop, but I don't know if that will be particularly easy.
What should be easy is finding out why the loop release button doesn't get greyed out!
