Best practice for projection mapping sync across multiple workspaces

[Jeremy Turner]

Hi all, 

I'm involved with a large outdoor projection mapping installation next year, and would love some advice for the best way to go about this, as it's bigger than anything I've done before. 

Large outdoor area in my city, with projection mapping on to multiple buildings. They will be playing local content with separate sound designs at each building, but are also creating a five minute long video with soundtrack that will span across all buildings at the same time, that they obviously want to be perfectly in sync everywhere.

The AV production company involved will be providing a Macbook Pro and projector for each surface, and they will all be linked together over a local gigabit network. They plan to use Madmapper for all of the mapping, but I would be more comfortable running the content from QLab via Syphon.

At the moment my plan is to have a master QLab session to fire OSC commands to each area at the same time, but I'm worried about how accurate the sync will be if I do this. I know MTC would be better, but is it possible over a large local network? 

[m...@stevensokulski.com]

How many buildings?  Unless it’s like... hundreds, I think MTC is the way to go.

By latching to a central clock you can slave each local workstation. And then unlatch from that clock for the local contenr.

[Sam Kusnetz]

Hello all

I respectfully disagree!

There are two issue at play here: simultaneity and synchrony, and they are different problems with different solutions.

Simultaneity is making sure cues start at the same time. If you have a local gigabit network carrying nothing but OSC traffic, I believe that OSC is likely to provide sufficiently tight timing. If you’re anxious about using a network, regular old MIDI run with XLR cables will work very nicely too.

Synchrony is making sure cues run at the same speed, so that as long as they start at the same time, they'll end at the same time too. QLab cannot sync to timecode (we prefer to say “sync” and not “slave”) so using MTC or LTC can’t help this problem.

The only way to get guaranteed sync between Video cues running on multiple Macs is to:

• make sure all Video cues have audio tracks
• make sure all Macs have audio interfaces with word clock connections
• clock all the interfaces together

Finally, if you do end up using timecode, I cannot recommend strongly enough that you use LTC and not MTC. If you’ve attended a class of mine, you’ll know that I think timecode is a dreadful protocol that should be banished from theaters everywhere, but out of the two, MTC is definitely the inferior version because it uses a quarter-frame format: you need four ticks of the clock to tell what frame you’re on, instead of LTC’s single tick. Plus, distributing LTC is easy because audio infrastructure is easy and cheap. Distributing MTC requires MIDI splitters and MIDI-to-XLR adapters… messy.

Good luck!

Best
Sam

––
Sam Kusnetz [he/him/his] (what is this?)
Figure 53
https://qlab.app | https://figure53.com

--
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/137603eb-da58-4ed0-91ef-1b50616a72afn%40googlegroups.com.

[Richard Sillitto]

Hi Sam,

On 1 Dec 2020, 14:43 +0000, Sam Kusnetz <s...@figure53.com>, wrote:

Finally, if you do end up using timecode, I cannot recommend strongly enough that you use LTC and not MTC. If you’ve attended a class of mine, you’ll know that I think timecode is a dreadful protocol that should be banished from theaters everywhere, but out of the two, MTC is definitely the inferior version because it uses a quarter-frame format: you need four ticks of the clock to tell what frame you’re on, instead of LTC’s single tick. Plus, distributing LTC is easy because audio infrastructure is easy and cheap. Distributing MTC requires MIDI splitters and MIDI-to-XLR adapters… messy.

This is following on from previous conversations we’ve had. Are there any recording of your classes on the subject of timecode?

I’m still aghast at that opinion that timecode is a "dreadful protocol that should be banished” being as we use it daily in broadcast very successfully and robustly.

Your dislike of timecode (for whatever reason - that I’d like to understand more) perhaps hints at the reticence of QLab to embrace sync’ing to it - the capability of which would be a tremendous boon to my workflow.

Best wishes,

Richard.

E: ric...@yoursoundsolution.co.uk
M: 07931 955149
W: www.rs-sound.co.uk

[Sam Kusnetz]

On Dec 3, 2020, 3:04 AM -0500, Richard Sillitto <ric...@yoursoundsolution.co.uk>, wrote:

I’m still aghast at that opinion that timecode is a "dreadful protocol that should be banished” being as we use it daily in broadcast very successfully and robustly.

Hello Richard

You’ve very slightly misquoted me here, which I certainly do not take offense at; I assume you meant none. I never said that timecode should be banished altogether, I said that it should be banished "from theaters everywhere,” by which I meant venues that produce traditional live plays and musicals. I certainly could have been more precise when I said that. My apologies!

I know that timecode is used every day in broadcast very successfully, as well as in television and cinema production, and I believe sometimes radio broadcast and production as well. These are the milieus for which timecode was invented, and in those contexts it is a perfect fit. I would never suggest that it be banished from those contexts, at least not until someone invented something that does the same job in a better way.

Your dislike of timecode (for whatever reason - that I’d like to understand more) perhaps hints at the reticence of QLab to embrace sync’ing to it - the capability of which would be a tremendous boon to my workflow.

My dislike is not for timecode in and of itself. My dislike is for exactly three aspects of timecode:

First: MIDI timecode, because it must exist within the technical limitations MIDI which are objectively very restrictive by modern standards, uses a quarter-frame format. For those who don’t know, that means that four frames of MTC must be read before the receiving device knows exactly what frame we’re on. It’s like a conductor reading measure numbers: “ONE two three four, TWO two three four, THREE two three four…” it’s fine in principle, but in practice what it means is that at 24 frames per second, a device following MTC might be as much as 1/6 of a second off. When the purpose of timecode is perfect sync, 1/6 of a second feels like a gigantic margin of error. LTC does not have this problem at all.

Second: Drop-frame formats are a rather mathematically elegant but technically aggravating solution to problems which only still exist because we’ve grown so accustomed to using drop-frame formats. While it doesn’t often cause problems, particularly in established workflows, it nevertheless hangs around, occasionally causing confusion and wasting time.

The final and most significant cause of my dislike of timecode as used in live theater is that fundamentally, the very concept of timecode is antithetical to the core truth of live theater. The whole point of timecode is that it is rigid and inflexible; one frame is exactly one frame. There is no elasticity. When you are working on a film, television show, or live broadcast on a public schedule, this is exactly what you need. But on stage, time need not be so rigid, and trying to make it so removes some of its power and its beauty. The amount of time that elapses between two events in a film are necessarily the same every time you view the film, so it makes perfect sense to use timecode as a tool in the production of the film. But the time between two events in a play is usually different every time the show runs. Anything which we do that presses against that truth needs to be considered carefully, and avoided unless necessary.

Therefore, for live theater I much prefer event-based show control, where a human person (usually the stage manager) can feel the live tempo of the show and cause design and technical elements to follow that tempo.

Now I will conclude with some good news: while QLab was originally created for live theater, we are beyond delighted that it has been embraced by artists and technicians of all kinds. For this reason, I can quite honestly say that I agree with you that QLab should be able to sync to timecode, and we do indeed plan to add that capability to QLab when we are able. When that time comes, I have every expectation that folks will put it to terrific use, and I’ll be very glad for that!

All my best
Sam

[Rich Walsh]

I'm not sure I completely agree with this interpretation – although I've avoided actually using MTC so may have missed something that comes up with experience?

The precise timecode address is sent over 8 "quarter-frame" messages, but these are sent at 4x frame rate – so your conductor marks quarter beats but only tells you where you are every other beat, Timing information is arguably four times better than LTC (?), but positional information is half as good. This is only relevant when changing position though, so it affects how long a slave takes to lock up. You should include pre-roll to allow for this regardless of timecode format.

I believe a device following MTC won't be off at all, and certainly not by 4 frames. It will take a minimum of 2 frames to catch up with a positional change.

I think you might want to do more dance shows if you think there's no room for timecode in live theatre? ;P

Rich

[Sam Kusnetz]

I think you might want to do more dance shows if you think there's no room for timecode in live theatre? ;P

I love working on dance. When I do, I often use timecode or things similar to timecode.

Dance is magnificent, dance is wonderful. And it is also not theater. It is a separate and distinct art form.

Once more, I respectfully suggest that we excise the word “slave” from our technical vocabularies.

Best
Sam

––
Sam Kusnetz [he/him/his] (what is this?)
Figure 53
https://qlab.app | https://figure53.com

On Dec 3, 2020, 9:52 AM -0500, 'Rich Walsh' via QLab <ql...@googlegroups.com>, wrote:

I'm not sure I completely agree with this interpretation – although I've avoided actually using MTC so may have missed something that comes up with experience?

The precise timecode address is sent over 8 "quarter-frame" messages, but these are sent at 4x frame rate – so your conductor marks quarter beats but only tells you where you are every other beat, Timing information is arguably four times better than LTC (?), but positional information is half as good. This is only relevant when changing position though, so it affects how long a slave takes to lock up. You should include pre-roll to allow for this regardless of timecode format.

I believe a device following MTC won't be off at all, and certainly not by 4 frames. It will take a minimum of 2 frames to catch up with a positional change.

Rich

On 3 Dec 2020, at 14:37, Sam Kusnetz <s...@figure53.com> wrote:

My dislike is not for timecode in and of itself. My dislike is for exactly three aspects of timecode:

First: MIDI timecode, because it must exist within the technical limitations MIDI which are objectively very restrictive by modern standards, uses a quarter-frame format. For those who don’t know, that means that four frames of MTC must be read before the receiving device knows exactly what frame we’re on. It’s like a conductor reading measure numbers: “ONE two three four, TWO two three four, THREE two three four…” it’s fine in principle, but in practice what it means is that at 24 frames per second, a device following MTC might be as much as 1/6 of a second off. When the purpose of timecode is perfect sync, 1/6 of a second feels like a gigantic margin of error. LTC does not have this problem at all.

 --

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/720D9BE2-4F4E-43E2-B061-A462BA26B164%40mac.com.

[Charles Coes]

Seconding Sam’s suggestion about language  here, and proposing a alternative.

A number of manufacturers are using Leader/Follower to describe clocking relationships with a single source device and a number of devices that follow along. 

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/9b493ee4-537f-4327-a714-1640cc718df7%40Spark.

[Taylor Glad]

To Jeremy's original question, my experience coincides well with Sam's advice; OSC has worked beautifully for me.

My most relatable experience is with 2 Mac Pros running a total of 5 playlists for 5 screens (and 5 OSC cues per trigger).

In our particular case, we have had great simultaneity and had no problems with synchrony. But Sam's advice on audio tracks and word clocks is good to know if I ever do have a problem with synchronization.

In my case we had two network switches connected with the main QLab connected to the first switch, and the 2 triggered computers connected to the other. So, I don't have experience comparing if one triggered computer were an additional 1 or 2 switch hops away compared to other triggered computers.

In addition to great playback, having the network structure of OSC adds a few other benefits.

I make a closed video network, and use it for file transfer to quickly and easily get all the media files to the right places without having to shuttle usb drives around.

I have scripts programmed that allow me to easily adjust cue settings and crossfade timing all from the main playback computer through OSC cues, making the tech process much easier.

Another thing I weigh when deciding between timecode and OSC is the programming work during the tech process (in addition to the other great advice given in this thread).

On one hand, if OSC cues are fired within a QLab group cue, you have the benefit of seeing the timeline and audio waveform which makes it very easy. But it also means all adjustments need to be made by one QLab operator.

On the other hand, using timecode lets any adjustments to timing be made on the triggered device by its operator instead of adding one other thing for the QLab operator to adjust. But, you don't get the fancy visual timeline view that QLab has.

So, considering the type of production, the schedule, the experience of the other crew members or any other influences, I've had times when I thought timecode might be better.

But I'd say 95% of my experience on my particular types of shows (mostly live theater), I have gone with OSC and have had great results.

Also, no intention of contradicting anyone who favors timecode. In my experiences with it, it worked great for triggering simultaneity (haven't had to use it for synchronization).

My main point to answer Jeremy is that yes, OSC works reliably when you want simultaneous triggering.

Taylor

[Rich Walsh]

I had a technical correction to make but instead we're discussing semantics? "Timecode is a dreadful protocol that should be banished from theaters everywhere" – but a building that puts on "dance" isn't a "theatre" because "dance" isn't "theatre", and using time code driven systems during a musical with click tracks would not be "theatre"…? I've actually found it really handy that there's a standardised, robust, well-established and cross-industry way of sending out a string of time-specific information in relation to a sequence of fixed duration that can be understood effortlessly by the vast majority of professional devices. Anyway, that's all irrelevant.

I used the noun "slave" in a very specific and limited way to precisely describe a "receiver" (cf: SMPTE 12-1:2014) using a time and control code signal from a "Time Code Source" to derive both timing and positional information. This is a perfectly acceptable word in the context of an audio device that is using an external source to derive its wordclock (timing information) – see, for example, Clock Status in Dante Controller. It is also the word used in Pro Tools, Ableton Live, Pyramix ("Pyramix will chase an external TimeCode source as a slave … External machines, capable of chasing TimeCode can, of course, follow Pyramix as slaves."), etc. Googling "time code follower" doesn't lead me to a long list of manufacturers moving away from this terminology?

QLab can not be a "slave" because it can not delegate its positional information to an external source. It can take positional information from time code and use that to trigger cues, but in use this is actually no more sophisticated than taking pitch information from a MIDI input or time of day from the system clock to trigger cues. There's no "sync" or "following" or "chasing"; there is merely "triggering" when the precise control code arrives on that trigger input. As MTC takes 2 frames to send the positional reference for a single frame it clearly can't send every single trigger code available – only every other trigger code. Is QLab capable of interpolating the missing positional information on the intermediate frames and deducing the correct timing from the ongoing messages? If not then it will presumably take 2 frames to reconstruct the trigger code so cues will always be late – as if you were using OSC but having to wait 80ms (PAL) for the whole message to arrive. Half of your possible choices won't fire at all…

In the world of triggering multiple QLab machines I think discussing "synchronisation" at all is misleading. All you can really do is "remote triggering" with specific trigger codes – OSC messages sent ad hoc or frame addresses that will scuttle past if time code is running. Either way if you miss the single trigger code you won't be running, let alone be in "sync". The interesting question is which form of trigger can QLab understand faster (and which form is least likely to be lost or corrupted)?

What is the additional meaning gained by saying that a receiver "syncs" to a time code source rather than "slaves" (verb) to it? Are we worrying about jam sync and freewheeling? What is driving the concern about a form of language that's been familiar and understandable to me for 25 years? Please tell me more.

Rich

[Taylor Glad]

My two cents on what I perceive to be your two main points.

The term "slave"

There's been a push lately in the industry (seemingly more so among academics and theater folks) to avoid this term because of the connotation with human slavery. I know it's a term that has been used for years and years in a strictly technical sense without any widespread concern, and others may have a lot more to say about that than I do, but all I know is right now people are starting to ask other to refrain from using that language, and I personally find it easy to simply change my language.

Timecode in theater.

I think theater itself has a wide expanse of what that can be, let alone when it is more like dance or more like other art forms. And the same could be said for dance, music, or any other performative artform. I used to work at a large theater where the music for their musicals was always either recorded or used a click track. The lighting team always requested time code, and that's what we always did and it always worked. They were able to make all the timing adjustments on their end without leaning over the audio's QLab workspace. And in my 5 screen show I used as an example, I essentially use OSC cues in a very similar way to how timecode functions (inside a group, so timing is set in stone), and it wouldn't be an overall large adjustment to switch over to timecode.

But I think Sam's distinction is more between OSC's inherently single-cue triggering and timecode's inherently multi-cue, locked-in triggering. I hate putting words in other people's mouths, let alone people much more eloquent than I, so I hope I'm not doing a disservice by that summary.

When a lot of people refer to theater and the essence of theater, as I understand it, they are referring to a very organic and reactive form of art. I've seen a lot of theater productions where timecode would simply be unreasonable, since no 2 points in time could be guaranteed to be consistent across multiple rehearsals or performances. 

In that case I'm not talking about shows like Music Man or My Fair Lady, but modern devised theater, or even classic "straight plays" like Shakespeare. Triggers to audio, lighting, or video are all dependent on actor dialogue, blocking, or even subtle gestures. There aren't points where the show enters into a sizable chunk of 'follow along with the recorded media'.

It's like there's a fork in the road between having live performers following prerecorded media, and having media follow live performers. And if you go further and further down either fork in the road, the different approaches to programming these triggers make more and more sense.

To use a random and somewhat bizarre example, a show like this would have only maybe one short 15 second segment that might be a little easier with timecode over OSC. You could argue that the whole show could be accomplished with timecode by triggering a 1 second segment of timecode every so often, but the thought is that at a certain point it's just easier to move to an individual "Go" trigger for each specific cue, instead of stringing multiple cues together in a locked-in, inflexible, set of timings.

Best,

Taylor

[Rich Walsh]

Thank you for the thought you've put into this reply. You've actually missed my main point, so I'll number them in increasing relevance:

1: The nature of theatre. This was meant to be throwaway, and I thought I'd buttoned the discussion up with "a sequence of fixed duration" to cover use cases in any medium where time code is relevant, regardless of how you wish to categorise that medium (or if you want to use that same word to describe the buildings you practise that medium in). Sam doesn't "like" time code. I don't "like" OSC because it is one-to-one not one-to-many, can't be paralleled, and crucially is not remotely standardised. An MSC GO is a GO, but it's up to you if you want the same action to be called "start" or "go" or "play" or "fire" in your OSC-handling device. Semantics! If I want to trigger a device in time with a sequence I am sending I can send time code throughout and set the client to respond appropriately, or I can interrogate the client's manual, learn its peculiar OSC syntax and make a number of bespoke cues to achieve the same thing. With OSC the programming is done at the source end; with time code the programming is done at the client end. What's more, if you load to part way through a sequence in QLab, time code will start from that load time whilst OSC cues won't – you'll get a flurry of all the cues that should have fired by that point when you start.

2. Which word starting with s to describe a very specific way of responding to time code. I completely got the wrong end of the stick, and I am sorry for being a thoughtless idiot. I saw my trigger of "QLab works with time code" and thought I was being corrected on a technical point between "staying in time" and "following changes in the timeline" – neither of which QLab can use time code to do, actually. I thought Sam was saying that Figure 53 prefer to describe QLab as "syncing" than the other word. I don't think "sync" is the right word in general either, as the key concept is the fact that when a time code source jumps to a different address a time code receiver will jump to the same address; "sync" generally doesn't mean that. There is a distinction between playing in time with the conductor and jumping to the correct part of the score when they skip around. "Sync" is the first part. The second part needs a different word.

3. My actual point. I don't agree that MTC receivers are inherently 1/6 of a second out from the time code source. I can believe that because QLab does not do anything more with incoming time code than respond to frame addresses as triggers there will be a latency set by the time it takes to decode those frame addresses (8 MTC messages over the duration of 2 frames). I don't know if QLab is using any form of "locking up" to be able to reduce that latency with pre roll – ie: guess the address of the next frame when you see its first message as you know the address of the previous one. This would make the latency inconsistent across a sequence that starts when time code starts but then takes later triggers from time code that is still running (better to ignore the first trigger before "lock up" in that case…).

I think I'm done flogging this one though as I don't think I'm helping clarify anything.

Rich

[Sam Kusnetz]

Rich

I’m quite sorry to have gotten under your skin. I was not trying to convince you of anything, only to make clear why I feel as I do.

Making too much of throwaway comments is all too easy in an asynchronous, textual conversation and again I’m sorry to have made a mountain over a molehill.

It’s also easy to forget that we are all so very far away from each other; you are in the UK, I believe, right? And I’m in New York in the USA. Over here, the topic of language which has racist underpinnings is very much of the moment, and it’s possible that it’s simply not as much so elsewhere. My brevity on the subject belies my US-centric mindset, and that was careless of me.

Timecode pre-rolling and full, proper timecode sync/lock/follow are on the slate for the future of QLab, and that’s really all I should have said about it.

All my best
Sam

––
Sam Kusnetz [he/him/his] (what is this?)
Figure 53
https://qlab.app | https://figure53.com

--

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/555A056E-DCA8-47CC-924A-149CA4A5AB29%40mac.com.

[Chris Ashworth]

On December 4, 2020 at 8:45:15 AM, Sam Kusnetz (s...@figure53.com) wrote:

Timecode pre-rolling and full, proper timecode sync/lock/follow are on the slate for the future of QLab, 

I’ll gently bend our company guidelines against sharing future roadmaps to say:

Indeed! I’d call the audio side of it “done”; still working on the video side. Expected in v5. (No ETA yet on v5 though.)

To expand on the technical conversation, I’ll also mention that our mixed feelings about timecode also stem from some technical details not yet mentioned here. We've done some (early) R&D on at least one approach that we feel could improve on the technical limitations of how timecode works.

 

The readme file on this page includes a description of the limitations we’re interested in improving on when it comes to how timecode works from a technical perspective:

https://github.com/Figure53/ActionSync 

But from a user perspective, as Sam says, we agree that better timecode sync is still quite useful despite the issues, and are working to add it.

-C

[m...@stevensokulski.com]

Hi Chris,

I'm getting a 404 error on that GitHub URL. Perhaps it's a private repo, or maybe it's got a different name?

[Chris Ashworth]

Whoops! I thought that one was public. Well, now that I’ve talked about it in public, I guess I’d better make it public. (Done.) 

It’s very much an R&D project still; not intended for production use at this time.

-C

[Jeremy Turner]

I got distracted with a busy production week and forgot to check on this thread. I'm sorry to have caused such a heated debate! 

Given the scale of the planned project I've decided that running some additional audio lines and using LTC will be a much safer option. Will use QLab as the master control for sending OSC commands to fade local content in and out, as well as sending timecode to all playback machines when synchrony is required.

Thanks so much to everyone for the valuable input. I've lurked here for a long time and it is such a great community that has taught me a lot of tips over the years.

[micpool]

I think that you may have misunderstood the actual answers to your questions, which are in the thread, but somewhat buried within the debate of the side issues.

Distributing LTC to your QLab machines will not improve Synchrony; Once QLab has acted on the timecode trigger, there is no further use of the timecode in that cue.

As Sam said in his first reply

The only way to get guaranteed sync between Video cues running on multiple Macs is to:

• make sure all Video cues have audio tracks
• make sure all Macs have audio interfaces with word clock connections
• clock all the interfaces together

If your cues are relatively short, this may not matter, and the sync may remain tight enough for the duration required, within the clock variations of the individual macs without the word clock.

The critical thing is, which method of  triggering, OSC, MSC, musical MIDI, or matching an incoming LTC frame from your show control computer will give  you the most accurate and reliable  simultaneous start of all your content playing computers. 

Because of the distractions,, this doesn’t seem to have  been definitively answered.  

There has also not been a discussion of the relative merits of a set of individually addressed  OSC cues, 1 for each playback computer, in a group as opposed to 1 OSC cue being sent to a broadcast address, for simultaneous triggering.

Another relevant topic might be the relative advantages of  sending a standard OSC message over the network using UDP, or the same message as text using TCP. Presumably the latter would be more reliable, but the former might be more immediate.

And if using MIDI what would be better, MSC over copper, or Musical MIDI over a network using iPMIDI software?

Mic

[micpool]

It’s probably also worth pointing out that in many complex systems that use high  end media playback servers, a completely different approach,  to the one QLab uses, is taken.

The  video servers get a single frame of video off the disk as fast as possible, do all the processing as fast as possible, and deliver it to the displays as close to the precise frame of incoming timecode, or internal clock as possible

Generally the video files do not have audio tracks, or ignore them  and  the servers use proprietary methods rather than Quicktime and core libraries to achieve best results. They are optimised primarily  for frame by frame video delivery in response to incoming timecode.

Some media servers will additionally  handle Quicktime files with sound tracks in the normal way, but these will not have the same performance as   video  only files as they will use the core libraries to handle these as opposed to the proprietary systems

The audio and timecode will usually be handled by a completely separate system. Sometimes the audio and timecode will be derived from one  computer, but again they may be separately sourced.

It’s also interesting that in some other  video playback software e.g Resolume Arena, it is necessary to (virtually) strip files of their audio content, before they will  sync to incoming LTC. This is because of the difficulties of combining synchronous playback to timecode of frame based video, with sample based audio. In my experience it’s still difficult to get video playback that looks as smooth as normal quicktime,  from inexpensive  frame based timecode synchronised video playback.

This all makes video playback much more complicated, and with many more potential pitfalls than the ease and simplicity we are used to with  QLab’s video implementation.

While there are situations where true synchronous playback to incoming timecode would be very desirable, for many situations the functionality and simplicity of QLab’s current video implementation is arguably much better suited to most users day to day needs. 

The fact you can just drag a core video/audio compatible  file into QLab running on an off the shelf Mac, hit the space bar and immediately see the output on a display with synchronous audio, without worrying about  frame and sample rates or much else, is a great thing. That with barely more attention to details like codecs and resolution, you can play many videos simultaneously or asynchronously  to multiple surfaces, is even more marvellous. 

To maintain this level of simplicity while incorporating  advanced time code sync options, is I imagine far from trivial.

Mic

[Jeremy Turner]

Thanks for the response. I was probably too vague in my reply - I'll use QLab as the leader for sending LTC from my main machine, and will most likely end up using Millumin on each follower machine to receive LTC (AV production company already has licences for this so is preferred for them anyway). Videos are about five minutes long so I am concerned about losing sync over that time. I will try OSC triggering only (QLAB→QLAB) in the initial tests though to see how close it stays together, before going down the timecode route.

Interesting point about sending OSC to a broadcast address, had never considered this. Have you tried this and noticed any significant difference?

[Richard Williamson]

I’ve had issues with macOS losing broadcast OSC messages - I think that the OS de-prioritises them - so I would always steer clear of them where possible, sending multiple targeted messages if you need to 

---

Richard Williamson
www.richard-williamson.com
ric...@theatre.support
07957 457 362

--
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/d6ce10c0-0a25-4c88-a38a-484fb72fefefn%40googlegroups.com.