jfk

Yes, there is. But the issue may not be the blend per se, it is more from misregistration of the overlap / double projection

Try ... Quit WATCHOUT Production, move the backup .watch file to the same location as the original .watch file, open

Never seen that one before. On what hardware does this error occur? WATCHPAX? User provided computer / Windows version? ... Where are you seeing that error? WATCHOUT Production error window? WATCHOUT Display error log? Windows 10 OS? ...

Adding WATCHOUT audio playback to your WATCHOUT video output is strictly a matter of the graphics card driver’s audio support. WATCHOUT requires either ASIO or WASAPI audio support. On your display computer go to Window mode and check the audio out menu to determine if display output audio is an option.

This most commonly occurs when there are multiple NICs on the production computer. If the WATCHOUT NIC is not the first NIC in Windows sort order, UDP traffic is lost to the first NIC, while TCP traffic still finds the correct NIC. play sent to the displays is a UDP command. To quickly confirm this is the cause, disable all NICs but the WATCHOUT NIC and normal operation should be restored. If you require multiple NICs (like WiFi and ethernet, etc), re-order the NICs in Windows so the WATCHOUT NIC is first.

What timecode format are you using? Are you specifying the time code format or using automatic?

So the issue is Windows problem. Did you look up the error as described in the knowledge base post?

The Production computer error you observed indicates the production computer has lost communication with the display computer. The most LEAST likely cause is a network issue. The fault most likely occurred in the display computer. To obtain more information on its cause, you will need to look in the display computer’s error logs. On the display computer, go to the folder where WATCHOUT is installed. There you will find a folder named logs. In that folder, look for the most recent text files that begin with WATCHDOG... and WATCHPOINT... and ending in .txt . If the errors you find in the log files do not contain a number, they are WATCHOUT errors and should be self explanatory. If the errors contain a number, they are Windows errors. https://knowledge.dataton.com/knowledge/interpretation/translation-of-error-codes-in-watchout

Depends on the WATCHPAX model. 3360 WATCHPAX were all v5.5.x only, but can be electronically upgraded to add v6 (and you must use v5.5x to upgrade the license to v6 BEFORE upgrading the WATCHOUT software to v6). 3362 WATCHPAX 2 depends on age, some were originally v5.5.x only and some were both v5.5.x and v6. All other WATCHPAX models (4, 20, 20A, 40, 60A, 60B, 60C) license are v6 only. Note, from a WATCHOUT software perspective, the version at time of the release of the hardware is the oldest version that will run on that model WATCHPAX. For example, WATCHPAX 60s require v6.5 or newer. https://knowledge.dataton.com/knowledge/watchout-versions-for-different-watchpaxes-watchmaxes

This seems to go beyond audio input. Video input for external devices require Microsoft Windows Driver Model (WDM) compliance. If the devices you mention are WDM compliant, then they should work.

Already on the wish list ... De-embed audio from video streams containing embedded audio (NDI, capture cards, live streams), mix audio input into WATCHOUT’s audio output with WATCHOUT’s standard audio control (volume, input channel to output channel patching). Individual Programmable delay for for each input / de-embedded audio stream. Is there something you are looking for beyond that?

Mike, thanks for sharing the story. John G, thanks for sharing the data sheet. Appears the SOUNDPAX could be seen as a Dataton one-up on the AVL ProTravler (which had an 8 year production run). A PAX and audio bundle with no System data input? (ie to bypass the audio system and use the PAX when programming from a computer (MICSOFT or TRAX). There is a System data output. Noticed an analog audio CUE TRACK jack, would make sense as an output. But the screening on the back of the prototype would imply its an input to drive the PAX. This must have been an 80s era exercise. My close experience with Dataton goes back to 1990 and i don’t recall seeing that cut sheet.

movie resolution and frame rate significantly factor into that decision.

WATCHOUT does not support any form of external audio input. Bypass WATCHOUT and feed your audio directly to audio system. You will likely need to add some form of audio delay to keep the video input and audio in synch.

WATCHOUT versions 4.2 through version 6.6.x will work under Windows version 7. Beyond that, we can only make a guess. It is my guess now that Microsoft has officially ended support for Windows 7, the next major release (i.e. WATCHOUT 7) will require Windows 10. When that release will see the light of day, your guess is as good as mine.

I suggest you take a look at this ... Pretty much the same holds true for all BlackMagic Design capture cards.

I am a bit baffled by your issue. I can not think of any reason software developers would expect to deal with system clock changes during normal operation. Specially with software that includes millisecond timing accuracy. If you feel you must change the system clock, quit WATCHOUT, make your system clock change, then restart WATCHOUT.

i am probably misinterpreting what you mean by that. MIDI is essentially RS-422 (a balanced line) at a reasonable data rate and you can run it quite a long distance without issue. Longer than a twisted pair ethernet hop for sure. WATCHOUT is commonly used in theatre today (well, before the pandemic) without an operator and without the production computer, triggered from the lighting console via MSC.

What you built already exists. The ETC Eos has the ability to output MIDI Show Control (MSC). WATCHOUT supports synchronising to MSC. You can designate any control cue with a cue number that matches a cue number in the EOS. Anytime the EOS executes a cue, WATCHOUT will jump to the control cue with the matching number and run. In normal show the cues would be in sequence so it is resting on the matching cue number, response is immediate. During rehearsal when you jump around, the timeline will stay in synch with the EOS, but when you jump there will be a brief period while the mew media is loaded. No different than discrete goto and run, maybe a bit quicker.

FYI If an external keyer is an option, many external keying solutions send two SDI signals (one is the video and one is the key). This is supported in WATCHOUT using two SDI inputs and the “masked by layer above” function.

There is no facility within WATCHOUT to add delay to live video. You would need to add a video delay device prior to sending the signal to WATCHOUT.

That does nor rule out an error in the meta data related to duration. As a simple test, try slightly reducing the duration of the first clip.

For your described purpose, absolutely yes. No. Do not do this. Video compression makes this a bad idea. By using a separate video on a single timeline for each cue, each cue will begin with an I-frame.

When triggering aux timelines from the Stop state, it is important to allow enough time at the head of the timeline for the video to cache. Starting video to soon could result in inconsistent playback. Alternately, send the aux timeline a pause to wake it up and cache prior to sending the run command.

Assuming the large error is not occurring at start and does not correct shortly after a start, synch loss that significant is possibly a network issue where the UDP multicast packets that maintain synch are lost or delayed.