SMPTE Time Code Stutter issue and possible solution

Post your questions here and we'll all try to help.
Post Reply
Naigi
Posts: 8
Joined: Mon Oct 20, 2014 14:12

SMPTE Time Code Stutter issue and possible solution

Post by Naigi »

Hi guys,

I noticed that playback of video clips when locked to time code is not really that smooth, even when all frame rates are matched and using DXV on top end machines. This is a shame as the overall Time Code functionality in Arena is great, but people seem to be bypassing it because of this issue and using other apps like Qlab to receive LTC and send Arena OSC messages to trigger normal time line clips. This results in smoother playback, at the expense of time code lock of course.

However there would be no need to spend more money and processing power on other apps if Auto Pilot was enabled on SMPTE locked clips. One could achieve the same result by making a dummy clip 1 frame long which is locked to a specific time code reference. Then next to it put a clip with the actual video that should play, and activate AP on the first clip so that when the right TC arrives it will triggered it, which in turn will trigger the correct clip immediately after. This way one could also better calibrate its synch by simply changing the frames in the time code locked dummy clip, or by changing the start/end points on the actual video file.

This seems like a neat solution so im wondering why the Auto Pilot follow actions are disabled from clips that are locked to Time Code?

I found this explanation on this thread
viewtopic.php?f=12&t=10891&hilit=auto+pilot+smpte
Triggering clips via SMPTE or using the autopilot on SMPTE controlled clips are specifically disabled in Resolume.

SMPTE in Resolume was developed to let a VJ run premade content in sync with a DJ track, while that DJ is still able to change and select tracks in the spur of the moment. The VJ communicates with the DJ :o , hears which track is coming in and cues it. The advantage is that the DJ can send out timecode with the same starting point for all tracks, without the need to add specifically timed SMPTE channels to each and every track.

More and more people are now expecting to build and run complete pre made shows based on SMPTE, which is not what the current implementation is designed for.

We're looking into making this sort of use possible in the future. In fact, we've heard of quite a few ingenious workarounds from a few VJ teams already. But for the time being, there is no out of the box way to do this in Resolume.

Hope that explains things a bit.
But I'm not sure i fully understand the logic (sorry if im just missing something!), if the idea is that a Dj should be able to send a 00:00:00:00 time code every time and for the VJ to select the right clip, wouldn't that still be possible with the automation option available? How would autopilot interfere with that?

I'm thinking that enabling the functionality would actually be pretty handy even in those scenarios, where a DJ or producer is playing a fixed set (very often the case for artists that have a visual show), a VJ could just sequence a bunch of clips in order, knowing that when one is over, the next one is selected automatically and ready for time code to start its playback.

interested to know if this seems like a possible solution to get around triggering clips via SMPTE only from Qlab and external software, and perhaps a reason to implement this feature.

Thanks!

Zoltán
Team Resolume
Posts: 7483
Joined: Thu Jan 09, 2014 13:08
Location: Székesfehérvár, Hungary

Re: SMPTE Time Code Stutter issue and possible solution

Post by Zoltán »

If you see a stutter every second once, then your SMPTE frame rates most likely don't match.
this would happen if resolume is on 25 fps and you are sending 30 fps SMPTE, then for 5/30th second the playback would stop as resolume would not get correct code. If resolume is on 30fps and you send 25 fps code then the playback yould jump forward 5 frames each second.
Of yourse your video frame rate should match to the set timecode rate too.
(I don't know how resolume handles not matching video - SMPTE frame rates, averaging from 30 to 25 or just dropping frames. ? )

If you see random stutter, bad cable/contact could be the reason, worth a check.
Software developer, Sound Engineer,
Control Your show with ”Enter” - multiple Resolume servers at once - SMPTE/MTC column launch
try for free: http://programs.palffyzoltan.hu

Naigi
Posts: 8
Joined: Mon Oct 20, 2014 14:12

Re: SMPTE Time Code Stutter issue and possible solution

Post by Naigi »

Thanks for the reply Ravensc

All frame rate setting are matched for time code, clips and Arena settings. It seems like other people also have this issue despite correct settings, so they resort to the technique of using Qlab (or other apps) as the time code receiver to then send OSC or midi to Arena and trigger normal time line clips.

So I'm just curious on what is the reason for de activating Auto Pilot for SMPTE locked clips. As if that was allowed one could achieve the same result but within Arena with the technique i mentioned below. Thus eliminating the need for other apps, and allowing users to still make use of the great time code features Arena offers like receiving LTC directly from audio inputs (no need for MTC conversion) and the easy way of programming and off-setting unique time code references for each clip.

The one thing that is lost with either of these techniques is the frame lock, so one cannot offset and fine tune the synch on the fly as the video/audio are playing. Instead one needs to restart the track/video from the top every time, but although that's inconvenient, its surely not a show stopper, generally takes a few tries, and once its all in synch one doesn't need to go back and change it. Except perhaps if there is a massive change in venue size and thus an offset needs to be added to make sure people further back still get audio/visual synch. But that can be achieved by using the input delay compensation option already present in Arena, thus leaving each track's reference the same, but offsetting synch globally for them all.

Joris
Posts: 5186
Joined: Fri May 22, 2009 11:38

Re: SMPTE Time Code Stutter issue and possible solution

Post by Joris »

We've done some work to make SMPTE playback a little smoother ( probably I should say we've made it as smooth as normal playback ).

The idea behind the current SMPTE implementation is to make synced playback between audio and video as simple and as foolproof as possible. The main reason for using SMPTE is that when the DJ pitches up, the video pitches up as well.

But also we try to prevent strange things when the DJ skips or when the signal glitches. For this reason, SMPTE clips are left as bare-bones as possible. They only play in time with SMPTE, nothing else. The less options there are, the less chances of it breaking.

A lot of people would like to use SMPTE for sending triggers and cueing shows as well. This is a valid request and we will certainly be spending time to properly implement this in the future. But we're not going to open things up to let users 'hack' it in in the meantime.

If you are not interested in the sync possibilities of SMPTE, and just want to trigger a clip at a certain time, surely there must be a more straightforward way to send programmed triggers?

Naigi
Posts: 8
Joined: Mon Oct 20, 2014 14:12

Re: SMPTE Time Code Stutter issue and possible solution

Post by Naigi »

Thanks for the info Joris.

If SMPTE playback has been fixed and will be as smooth as normal time line playback than there is no need for any of these work arounds anyways. Good news!

In the last couple of days I've found a technique that could be interesting for those who want Time Code triggering of normal clips mixed with Auto Pilot. I use Lockstep to convert the same SMPTE signal that Arena is receiving into MTC and send that to Vezer where I create a time line with frame accurate Midi or OSC events that can act as trigger in Arena.

I'll also be using this as a back up to the SMPTE locked tracks, so for instance on Arena Layer 1 SMPTE tracks will play locked to time code, on L2 a double of the same tracks will play Not locked to TC but triggered via midi. This way if there is any problem with the time code signal during the show (resulting in stuttering etc..) I can just fade seamlessly to the free rolling clip.

Ideally it would be great if Arena allowed to unlock a clip from SMPTE once its running (so just setting it back to time line mode), with that clip continuing to play seamlessly instead of being re-triggered from its start. A 'Free Roll' option is always handy when working with SMPTE lock as LTC signal interference errors can happen during a show, and its really not fun to have to just sit there and watch the video stutter/glitch without being able to do much about it.

But in the mean time one can use the technique above, you will need to download the latest beta of Vezer for this to work as until yesterday there was no 'hours' field in its time line. You can use Arena's SMPTE functionality to synch the tracks properly on the fly, than once the right offset is found copy and paste the time code value to the keyframe in Vezer. Just make sure to add 2 frames, so if the value is 01:00:05:00 in Arena, make it 01:00:05:02 in Vezer, this seems to keep things in perfect synch, at least in my configuration.

As Joris mentioned there are often more straight forward ways to create single events triggers. This technique is useful when the band on stage doesn't use computers and so there is no Midi/OSC cues that can be programmed with the audio source, but instead one has a click track and SMPTE LTC as the only source of synch available.

Hope that helps!

martino.cerati
Posts: 25
Joined: Sun Feb 12, 2012 22:51

Re: SMPTE Time Code Stutter issue and possible solution

Post by martino.cerati »

this is probably what you needed times ago

http://www.martinocerati.com/prodotto/clippgo/

User avatar
drazkers
Posts: 968
Joined: Wed May 18, 2011 10:54
Location: Brady V up in Canada

Re: SMPTE Time Code Stutter issue and possible solution

Post by drazkers »

So i recently had two new machines that would randomly stutter every few seconds. It was pretty rough.

It ended up being that since i was using a laptops built in sound card the drivers provided by the laptop manufacturer had some weird hitch. I directly downloaded from the sound card's website and it fixed random stutters.

Post Reply