SMPTE vs. MTC

[Tyler]

I usually default to SMPTE in situations requiring TC but do to some recent issues that F53 is aware of I switched to MTC for a production. Wanted to get the communities opinion on which is better. Using QLab and MA2 console, switching to MTC appears to take the console a bit longer to lockon than SMPTE. Not bad, but noticeable Thinking this has to do with how the framing of MTC works.

I usually go with SMPTE for ease of use. Standard XLR and it's run. I ended up moving QLab rig from backstage to FOH when I had to switch to MIDI (max legnth around 15 meters)

[Sam Kusnetz]

On February 22, 2014 at 1:41:00 AM, Tyler (tgot...@gmail.com) wrote:

I usually default to SMPTE in situations requiring TC but do to some recent issues that F53 is aware of I switched to MTC for a production. Wanted to get the communities opinion on which is better.

Hello Tyler

To begin with, I assume by “SMPTE” you mean “SMPTE timecode” which is also called LTC, or linear timecode.

My opinion (not the official position of Figure 53) is that both formats of timecode are headache inducing, and if you are firing cues from QLab to an external device, individual OSC, MIDI, or MSC triggers are superior from a logistical standpoint.

If you are in a situation that absolutely requires actual timecode, I have no strong opinion on which is better.

I usually go with SMPTE for ease of use. Standard XLR and it's run. I ended up moving QLab rig from backstage to FOH when I had to switch to MIDI (max legnth around 15 meters)

You can get or make very inexpensive adapter to run MIDI over 3-pin XLR cable, and doing so dramatically increases the range of MIDI signals. In truth, if your outgoing MIDI device provides the actual amount of power that the MIDI spec asks for, MIDI over XLR should be good for as much as 1000 feet.

Cheerio

Sam

—

Sam Kusnetz
QLab Field Operative
s...@figure53.com

[Charlie Richmond]

On Sat, Feb 22, 2014 at 10:10 AM, Sam Kusnetz <s...@figure53.com> wrote:

You can get or make very inexpensive adapter to run MIDI over 3-pin XLR cable, and doing so dramatically increases the range of MIDI signals. In truth, if your outgoing MIDI device provides the actual amount of power that the MIDI spec asks for, MIDI over XLR should be good for as much as 1000 feet.

http://www.richmondsounddesign.com/faq.html#midilen

Enjoy!

C-)

 

[Rich Walsh]

On 22 Feb 2014, at 18:10, Sam Kusnetz <s...@figure53.com> wrote:

On February 22, 2014 at 1:41:00 AM, Tyler (tgot...@gmail.com) wrote:

I usually default to SMPTE in situations requiring TC but do to some recent issues that F53 is aware of I switched to MTC for a production. Wanted to get the communities opinion on which is better.

Hello Tyler

To begin with, I assume by “SMPTE” you mean “SMPTE timecode” which is also called LTC, or linear timecode.

My opinion (not the official position of Figure 53) is that both formats of timecode are headache inducing, and if you are firing cues from QLab to an external device, individual OSC, MIDI, or MSC triggers are superior from a logistical standpoint.

If you are in a situation that absolutely requires actual timecode, I have no strong opinion on which is better.

LTC and MTC are both subsets of SMPTE timecode. Timecode is actually a fantastically useful way of running things if you have devices that _chase_ it (which QLab doesn't). If the devices don't chase, then there's no particular advantage to TC over a one-shot trigger command. I wouldn't dismiss timecode out of hand though; I bet the closing ceremony in Sochi today is run chasing TC… The 2012 OOC certainly was.

LTC has at least two considerable advantages over MTC: it is audio so it can be sent for miles, buffered, distributed and even sent wirelessly; secondly, MTC only sends full positional information every 2 frames, so it can be slower to lock up.

Rich

[Joshua Langman]

How does QLab not chase timecode? It will listen to timecode and fire cues with timecode triggers appropriately.

Or does "chase" mean something more specific here?

[Sam Kusnetz]

On February 22, 2014 at 11:49:40 PM, Joshua Langman (jlangma...@gmail.com) wrote:

How does QLab not chase timecode? It will listen to timecode and fire cues with timecode triggers appropriately.

Or does "chase" mean something more specific here?

If QLab is listening to timecode and you rewind that timecode, QLab won’t rewind currently playing cues. If you fast forward, QLab won’t fast forward currently playing cues. All QLab does when listening to timecode is fire any cue that’s set to fire on a particular frame whenever it “hears” that frame.

Since QLab doesn’t have a strict timeline, and there is no explicit timing relationship between cues that aren’t connected with autofollows, autocontinues, or by virtue of being in a start-all group, it makes sense for QLab to behave this way. But for software or hardware that does have an explicit timeline, such as Final Cut Pro, chasing does make sense.

[Tyler]

I like TC because failure is immediately apparent where MIDI/OSC failure wouldn't be realized until it's suppose to fire the cue (too late at that point)

Both have pros/cons and I appreciate the discussion here. Interesting topic

[Richard B. Ingraham]

Chasing, to my mind anyway, I can not speak for Rich, means you can send a device timecode from any specific point and the device will look backwards, find out what should still be playing, shuttle it forward and play just like if you had started prior to the timecode trigger point.

An example, if Q1 starts at a time of 00:00:00.0 and Q2 is a fade of Q1 which starts at 00:00:05.0 and is 30 seconds long, then I send it code that starts at say 00:00:10.0 in Qlab it would just ignore both Q1 and 2, since it is past their trigger point. If it chased it would shuttle Q1 ahead 10 seconds and start playing it at the level 5 seconds into Q2 and the continue that fade.

SFX and some others would do this kind of thing and it's one of a handful of things I really miss when working in QLab.


Richard B. Ingraham

Joshua Langman <jlangma...@gmail.com> wrote:

How does QLab not chase timecode? It will listen to timecode and fire cues with timecode triggers appropriately.

Or does "chase" mean something more specific here?

--
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53
 
---
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Richard B. Ingraham]

I would say "makes sence" is just an opinion. To me it should be an option that it could be set to perform either way. I can think of several situations where I would not use QLab specifically because of that lack of functionality.

Of course, that is just my opinion as well...


Richard B. Ingraham


Sam Kusnetz <s...@figure53.com> wrote:

On February 22, 2014 at 11:49:40 PM, Joshua Langman (jlangma...@gmail.com) wrote:

How does QLab not chase timecode? It will listen to timecode and fire cues with timecode triggers appropriately.

Or does "chase" mean something more specific here?

If QLab is listening to timecode and you rewind that timecode, QLab won’t rewind currently playing cues. If you fast forward, QLab won’t fast forward currently playing cues. All QLab does when listening to timecode is fire any cue that’s set to fire on a particular frame whenever it “hears” that frame.

[Andy Dolph]

I'll second this feature request - there are times that it would really be helpful.

--

[Paul Gotch]

On 23/02/2014 05:51, Andy Dolph wrote:
> I'll second this feature request - there are times that it would really
> be helpful.

How would it work? Chasing timecode works when the thing you are
controlling is symmetric with respect to time. A single video or audio
track for example has this property.

QLab has no fixed timeline and it has cue structures that do not obey
time symmetry, that is to say once the cue has been called it is not
possible to workout what the state of the system was before the cue has
been called.

I think Sam's comment was not strong enough it's not that it 'make's
sense' it's that it cannot work another way without changing QLab in
such a fundamental way that you'd now have a new tool that did a
different thing and no longer did what Qlab does.

Of course it may be that there is a gap in the market for such a tool.

-p

[Rich Walsh]

On 23 Feb 2014, at 06:09, Paul Gotch <pa...@chiark.greenend.org.uk> wrote:

> How would it work? Chasing timecode works when the thing you are controlling is symmetric with respect to time. A single video or audio track for example has this property.

Well, exactly. Any cue/sequence that has a timecode trigger has necessarily been attached to a linear timeline. Hence if a cue is triggered at 01:00:00:00 and QLab receives TC of 01:00:01:00 it is entirely reasonable to expect it to start playing that cue from 1:00 in. It can, after all, load sequences to a given time - so following linear time in this way is not remotely inconceivable or against the nature of QLab.

I don't think anyone is suggesting that a cuelist full of cues that are GOed independently of a linear source of time could somehow magically chase TC. That _would_ be ridiculous.

Incidentally, the universe itself is not symmetric with respect to time.

Rich

[Andy Dolph]

What Rich said.  I was imagining that maybe there would be some way to have a sequence of cues (maybe requiring having them all in a group if that would simplify things...)  where the cues are all locked together by timing - either actual timecode on every cue, or timecode on the group or 1st cue and then pre/post waits - but in any case the whole sequence DOES run in a timed consistent way. 

The place this would be particularly useful for me would be in multi computer shows - where either for compute/gpu/number of outputs or convenience of having outputs coming from computers located in different places I could build a show with say, one mac mini for each projector, but be able to (essentially) "load to time" across multiple machines.

most of my needs could be solved in other ways of integrating Qlab workspaces across multiple machines, but timecode seems like the shortest path to it...

OTOH, I'd love it if the F53 folks would create a "Qlab render node" program or something like that where I build and run the show on one machine, but am essentially able to specify audio and video outputs on multiple machines as a part of the workspace, and Qlab takes care of making sure that the right media is synced from the master machine to the slaves....  but I suspect that's a much more major endeavor to code.

However, it would be very useful for me in some situations (and I suspect for other folks too) for one thing, it makes it easier to do larger shows if you have more computers but none of them are Mac Pros with lots of graphics power and outputs...

Andy

[Richard B. Ingraham]

Right. Yes, it does get tricky if you have things like MIDI commands or
Telnet messages, etc.. that are linked to timecode triggers because there
will be places where you want them all to fire off, so everything is in the
right "spot" and other times where you only want the one that should have
most recently fired off to be sent and there is no way for app like QLab to
know when to do which method. So some human intervention will always be
required.

However if you look at the SFX model (yes I am biased.. too bad..) the
idea was always when it came to audio playback that you could start up
anywhere in the middle of a sequence of cues that are triggered via timecode
and the application would look through all playback cues and shuttle them to
the appropriate playback location and look through all the various fade cues
and play the appropriate audio at the levels where is would have been had
the timecode been received from prior to the start of the sequence and
played through.

And if I understand your comment correctly Rich, obviously if there are cues
that are not linked to a timecode trigger then they wouldn't be expected to
do anything. That is the entire point of having a cue that is randomly
fired off at some arbitrary point, yes?

Although I've done a bit of video and projections work, I'm not really
enough of an expert to know how this thought process effects video playback.

I guess to my brain, I just found SFX's method of timecode implementation,
with a per cue list, timecode like clock far preferable to building a Group
Cue set to Fire All Simultaneously and then setting prewaits for each event.
That to me is where the SFX model is sorely missed. (or one of few features
I really miss) I also highly miss it's timecode learn function where you
would start timecode for a Q List rolling and you fire off cues by hand and
it would put the timecode values into the cues for you. This was an
excellent way to build complex sequences using your ears rather than typing
in time values to cues. Yeah the Group Cues get you close, but to my way of
thinking they are lacking. The fact that SFX could then really chase to
incoming timecode was a secondary benefit to me.

Of course the catch was/is that SFX 6 was always very buggy and the intended
behavior didn't always match with what happened in reality.


Richard B. Ingraham
RBI Computers and Audio
www.rbicompaudio.20m.com

[John Huntington]

On Sunday, February 23, 2014 11:24:33 AM UTC-5, Richard B. Ingraham wrote:

I guess to my brain, I just found SFX's method of timecode implementation,
with a per cue list, timecode like clock far preferable to building a Group
Cue set to Fire All Simultaneously and then setting prewaits for each event.

Hear, hear...

John

www.controlgeek.net 

[Andy Dolph]

I'll also second Richard's point about having a mode to "learn" timing - I've often wanted that.

The way I imagine it would work is that I would put something in the prewait field other then a time (maybe a ? or "L" for "learn") and then run the cues manually with the right timing and have the prewaits fill in with the timing I performed manually.

[Tyler]

That would be fantastic. This is how most timecoded lighting is done anyway. 'learn' rough timing by firing live and then change any values that were off.