Show Cue System

Hey all,

While trying to solve my cross-cue cross-fade problem, I am experiencing what seems to be a 0.06 offset with cues:

Duplication Path:
* Cue 1 and Cue 2 working off the same file (a 35.6 mb flac file)
* Cue 1 Setup:
Start: 0:51.74
End: 1:25.03
Fade In: 0:00.50
Fade Out: 0.00.50

* Cue 2 Setup:
Start: 1:24.03
End: 1:57.50
Fade In: 0:00.50
Fade Out: 0.00.50
Auto-Start: 1.00 seconds before end of Cue 1

In other words, I've defined two cues such that cue 2 overlaps cue 1 by 1 second. Cue 2 starts 1 second before the end of cue 1, and starts 1 second earlier in the file. The .5 fade means I won't get any clicks.

It should be something like this:

.....[Cue 1 ......]
[Cue 2 .......]

What happens when I play it is that a single chord seems to sound twice in a bit of a stutter. I was immediately concerned that there was some kind of memory or process utilization issue. But what was nagging was that it was consistently happening along this boundary and nowhere else. That made me suspect a timing latency of some kind. So, I tweaked my "auto-start time" on Cue 2 from 1.0 seconds to 1.06 seconds. Bingo - now it's no longer sounding the chord twice.

That means it's definitely some kind of lag between the two cues which sounds nasty. My audio driver tab has "Use Software Mixer" unchecked, as well as "Do NOT use SCS internal mixer" selected in the right-hand radio-button group. Pre-Buffering is set to defaults as is Update Period of Playback buffers. Sample Rate is set to 48000 (tried at 44 as well, but my .flac files are 48000/24 bit).

Thanks for any assistance or guidance you can provide,

Marc

I presume this related to the click-free transition between cues topic. The latency you observed may be correct (60ms). I have plans to tighten up the timing of auto-starts, but that will take a while to implement.

Hi Mike (and all),

This turned out to be quite a serious problem for me actually with an even worse side-effect. You see, I did the evaluation of SCS, and initial work setting up the cues on my development laptop (Dell Latitude D830, 4gb ram). I then transferred the files over to another Dell laptop (I forget the model, but it's an older machine with a slower CPU) with only 2gb of ram. I then discovered that all the work I did carefully lining up the loops and delays to ensure no clicks or pops vamps had to be completely redone. Auugh!

Marc, have you tried merging the two cues into one cue employing different output devices, and then have a level change cue at 1:24 to fade down your "cue 1" devices and fade up the "cue 2" devices?

This is of course assuming you have enough device slots available to cover the union of devices used in both cues, this is another way of handling a cross-fade of the same audio clip. I've used this method successfully to fade from full house (LR, C, Rears) to a victrola on stage (FX) ... that's four output devices in all. You may also notice an offset in some cases using this method -- as I have in the past but that was 2+ years ago and is something Mike may have already fixed ....

-- John

Marc,

Um, yeah... Carefully adding timing delays that are dependent on CPU instruction execution speed is known to be very non-portable. Some of us used to do that back in the "bad old days", at the assemply language level, adding NOP (no operation) instructions to critical device driver timing loops to match the requirements of the hardware. Well, of course, once you move that code onto a faster machine, it no longer works. For that reason, developers don't try that kind of trick anymore.

I'm curious as to whether any competitive products on the market offer the level of "time coherency" you are looking for. All my sound designs are pretty simple and straightforward, so I've never encountered any of these types of limitations. It seems to me like you may be expecting more of the tool than it was designed to deliver.