• State Not Answered
  • Date
    Christofer76024
  • Date
  • Replies 4 replies
  • Subscribers 58 subscribers
  • Views 5333 views
  • Users 0 members are here

Timecode glitch Cobalt Nomad

I´m not sure if this is a midi interface problem or a cobalt software issue but i´m throwing the question out to se if anyone else had the same problem.

I´ve designed a show for a restaurant and the operators are under qualified and the hardware must work at all times with as little outside support (read phonecalls to me at the strangest hours from stressed out operators) as possible.

The setup we got is a Mac running Qlab witch in it´s turn sends Midi showcontrol and Midi Timecode to my Asus computer with Cobalt Nomad. The software is running fine on its own but some times when it receives timecode it seems that the Auto Locate function freaks out and starts the wrong sequence steps.

The chain is like this:

Qlab sends MSC to Cobalt to go to black prior to show. OK

QLab starts timecode and starts the wav file. OK

Cobalt receives timecode but should not execute any cue until like 8 seconds in to the timecode but as soon as the timecode starts it jumps to a completely different part of the programming, often some part that already been "played".

When the right part of the timecode is running ( e.g 07.00.08.30 ) and the dedicated seq. step is to be played back it does it right.

This only happens when the timecode starting with 07.00.00.00 is running. (I´ve incremented the timecode to the shows parts, e.g ( 01 = Opening Act, 02 = Beatles Medley and so on)

I´ve checked the cobalt programming over and over to see if there´s any conflict in the "learned" timecode and there´s not.

No MSC messages are being sent at the wrong time as well.

So my question is this. Could this be a Cobalt issue or could it be a glitchy Midi interface.

The Qlab programming is also checked several times and does not seem to be faulty.

Any one else had this issue? 

/ Chris

  • 0
    I had a similar problem with a lost-cost USB/MIDI interface on a Windows PC, with Cubase as timecode source.
    When using a M-Audio MIDI interface, the problem was gone.

    Hans
  • 0 in reply to hleiter
    That´s actually kinda releaving to hear that i´m not alone and stupid :-).
    I´m using M-audio interfaces in both computers but maybe i´ll try getting new ones and try again.
  • 0

    In general you should always have a few seconds of "pre-roll" where timecode is running but nothing actually happens yet (no audio/video or lighting changes).

    This makes the show both technically more resilient in case of bad connection/dropped timecode, and allows a few moments for an operator to see that it's working before the show itself actually starts.
    (Eg plug it back in if they knocked the MIDI or USB cable out!)

    MIDI Timecode works by sending a single "Absolute Start Time" value, then 1/8th of the timecode value every quarter-frame - so while running, it takes 2 full frames to get the complete time.

    As you'd expect, Cobalt assumes timecode runs smoothly unless/until it either gets the "Absolute Start Time" packet, or a set of quarter-frames has an unexpected time.

    So if the USB MIDI interface is unable to send all intended MIDI packets, "Weird Stuff" (TM) can happen - especially if the timecode jumps or is starting!

    However, there are also some 'weird' timecode numbers that may or may not exist depending on the type of timecode being sent by QLab.

    What's the exact timecode number(s) have you seen this with, and what framerate have you chosen in QLab?
    - The Frame #30 mentioned above isn't a valid value.

    If you're using the usual NTSC framerate, the first two frames each minute only exist each 10th minute.
    - eg 01:10:00:00 exists, but 01:11:00:00 does not.
    This framerate is often labelled as 29.997fps, or 30fps DF (drop-frame).

    The other NTSC framerate is 30fps NDF (non-drop-frame).
    This always has all frames 0-29, but the timecode is slightly slower than real time.
    - 1 hour of "30fps" timecode is actually 1hour 3.59 seconds. Normally you don't care!

    Finally, if you're sending 24fps or 25fps, frames #24 or #25 up don't exist.

    Cobalt doesn't check for these 'special' missing frames when you're typing in or adjusting values, as it doesn't know which framerate of timecode you intend to use until it's actually running. (Eg recorded it in NDF and are tweaking for DF)

    PPS: You can use timecode for sequences on all playbacks, whether Main Playback or any of the 80 Masters.

    I've used that for multi-sequence timecoded shows in the past, with no actual "live cues" recorded on the Main Playback, using MSC etc to raise//lower the appropriate Masters and select the right 'show'.

  • 0
    I NEVER start a Q on 01.00.00.00. always let a few frames run i.ex. 01.00.00.06 so the console can start reading the timecode.
    I run Qlab and a USB to midi cable. never had problems if I start the timecode a few frames before the Q.
Related

www.etcconnect.com