Link Cues to Timecode in Audio File?

181 views
Skip to first unread message

Tyler Neal

unread,
Mar 8, 2020, 9:31:51 PM3/8/20
to QLab
I have some lighting cues I need to time to certain points in an audio track, the problem is that we have several vamps in the audio track so doing waits won't work because it won't respect the vamps.

Is there a way to tie cues to fire on certain times within an audio file?

Jason Dino

unread,
Mar 8, 2020, 9:38:59 PM3/8/20
to ql...@googlegroups.com
Make a timeline group and move the lighting cue on the timeline. Great for dance shows. Use it all the time triggering midi cues to trigger my lighting console. 

On Sun, Mar 8, 2020 at 6:31 PM Tyler Neal <adv...@gmail.com> wrote:
I have some lighting cues I need to time to certain points in an audio track, the problem is that we have several vamps in the audio track so doing waits won't work because it won't respect the vamps.

Is there a way to tie cues to fire on certain times within an audio file?

--
Contact support anytime: sup...@figure53.com
Follow QLab on Twitter: https://twitter.com/QLabApp
User Group Code of Conduct: https://qlab.app/code-of-conduct/
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/cd3413f2-f393-4c66-8a37-a32155672ec2%40googlegroups.com.
--
Sent from Gmail Mobile

micpool

unread,
Mar 9, 2020, 6:59:03 AM3/9/20
to QLab
This is a real can of worms question.

The answer is, not in the simple way that would seem to be the most obvious.

The problem is that cues in a timeline group are offset by their pre-wait from the timeline group, as soon as the timeline group is fired the pre-wait runs on a separate clock that has no understanding of what the group is doing.

Take an example of a timeline group containing an audio file with slices at 2 & 4 seconds, with an infinite loop. a slice at  7s with an infinite loop, and a MIDI cue placed on the timeline view against the audio waveform at 5 seconds.

Screen Shot 2020-03-09 at 10.16.49.png



Although the audio file won't reach 5 seconds during the first loop  the MIDI cue will still fire at 5 seconds. In the timeline group you will actually see two cursors.

What is confusing is that the timeline group itself never reaches 5secs as the action time of the group follows the audio cue. But the 5 second pre wait on the MIDI cue isn't actually being fired off the elapsed action  time of the timeline, but off it's own prewait timer and so fires at 5secs after the group cue is triggered, regardless of any slicing or looping.

There are 2 work arounds.

1, You could use  duplicate audio cues, and set the start and end times of each cue to create sections and whole cue  loops  which correspond to where you would have sliced your audio.

You then set your MIDI Cues on the timeline relative to the start time of each chunk of audio.

There are several problems with this approach.

You have to calculate the time of any MIDI cues relative to the start time of the chunk of audio you are playing in that cue.

Gapless playback  at the devamp point  is not guaranteed because QLab is now treating each section as a separate audio file. 

If the MIDI cue is in a looping section of audio, it will only fire once.


2. You could make a multichannel audio file with your audio file and LTC and slice and loop it as before.

You loop back the LTC track on your audio interface and set the cue list to use LTC.

You trigger  your lighting cues off Incoming timecode.

The disadvantages are:

It's messy and complex

You can't see the waveform to spot points in the audio cue. Any audio detail is obliterated by the LTC waveform, as you can't select which channels you see in the waveform.

The Advantages are:

Midi cues fire at the exact point in the audio, which is not guaranteed in any other method.

A Midi Cue in a looping section will fire repeatedly every time that the audio and  time code value is looped through. 


All the above is easier to demonstrate than explain so attached are links to a  video and workspace demonstrating the 3 methods.

Screen Shot 2020-03-09 at 10.55.48.png




Although the example uses MIDI cues for the LX cues, they could just as easily be OSC or internal QLab lighting cues.

You can download themeless here:


The files aren't that big but exceed the limits for this google group hence I couldn't attach to the post.

Mic

Harry Halliday

unread,
Mar 9, 2020, 4:02:52 PM3/9/20
to QLab
I could be wrong here, but I think there might be a third workaround in addition to the two Mic mentioned above using some additional slices and a convoluted series of devamp cues: 

Screenshot 2020-03-09 at 19.53.07.png



The above workspace has slices for the point at which every LX cue should fire, as well as slices to denote two looped/vamped section. LX1 goes in the first section of the song, and LX2 starts at the same time the looped section begins. These two LX cues are fired as you normally would with devamp/start cues, and any that need to be fired within the loop (LX2.5 and 2.6) are given pre-waits, and then looped using a start cue with a pre-wait of the total time of the vamped section. Obviously if there are no cues that need to be fired within the vamp, this becomes slightly easier. 

(The arm cue in the screenshot above obviously isn't strictly necessary, and would need a prewait to work using that method, which I forgot to add). 

This obviously doesn't solve the original problem of wanting to just fire cues at a specific timecode in a cue that uses vamped sections, but does seem to work without having to use separate audio files (unless I've misunderstood the complexity of the question).

 

lxcues-with-vamps.qlab4
Reply all
Reply to author
Forward
0 new messages