jfk

The NIC was added to the production computer, not the WATCHPAX.

There is a known issue with slow transfers on WATCHOUT Display servers running Windows 7 (which includes WATCHPAX 4) and WATCHOUT Production running Windows 10 or 11. File transfers are at normal speed when the production server is also running Windows 7. While it is suspected this relates to different default NIC settings between Windows 7 and Windows 10, no one has specifically identified the settings to correct this. I did hear from one user who added an additional NIC to his production server and the issue went away, but again the significant settings of the new NIC were not identified.

Because the other methods use different technologies. In order to maintain compatibility with older WATCHPAX, WATCHOUT still requires Microsoft DirectX 9. That is the newest version available in Windows 7. Most (but not all) issues arise from modern gpu drivers issues with DX9. Don’t worry, the next major release of WATCHOUT will remove dependence on DirectX. It will require Windows 10 or above (outdating a lot of servers in use today).

Barry is retired now and Media Fabricators is gone. Last I spoke with him a few months back he still had some gear left stored at his home. But he was preparing to send it to a scrap yard.

This is baffling. It makes no sense for the resolution settings in the watchmaker stage display specifications to cause watchmaker to crash (shut down). Highly unlikely. Incorrect settings there could cause issues with watchpoint, but not watchmaker. In fact, I am always surprised when erroneous display specifications settings have no negative impact on watchmaker. For example a typo entering a setting, like a resolution of 1921x1080 had no negative effect on watchmaker, but of course watchpoint errored on it while trying to go online.

Pretty sure that indicates the driver required by WATCHOUT is not available. Possibly someone who has successfully used a BMD capture card can provide a screen capture of what a correct setup looks like on the watchpoint video input menu?

Post a screenshot of watchpoint’s video input choices.

The BMD capture utility uses a proprietary BMD driver. WATCHOUT requires a generic Windows Driver Model (aka WDM) driver. So while the BMD utility confirms the physical connection, it does not tell you if the WDM driver is correct. Someone correct me here, if the WDM driver is correctly installed, shouldn’t you observe at least two choices per BMD input in watchpoint’s video input menu - one for the proprietary driver and one for the WDM driver? If the BMD utility works and watchpoint only offers one choice, does that then mean the WDM driver is not correctly installed and watchpoint can not capture? BTW fps may be an ambiguous term here - BMD = fields per second, Dataton = frames per second. 50 fields per second = 25 frames per second.

WATCHOUT does not support audio from live streams (capture, NDI). Either pull audio from the source or use an Audio De-Embedder / Extractor. Either way, process audio separately. An audio delay may be needed to resynch video / audio.

True, Dataton discontinued the development of WATCHNET software. Mainly due to lack of customer interest. The WATCHNET software is still available for download. About the only feature in watchout released after WATCHNET development stopped is task window folders. So if you avoid task window folders, WATCHNET works as it always has. Dataton stopped including WATCHNET licences in the standard watchout license (the standard license supports v6 only). The watchnet license is now a seperate type number (3160) at a slightly higher cost and it supports WATCHNET, -or- WATCHOUT v5.5.x -or- all WATCHOUT v6 variants. So it is still accessible to those who wish to continue to use it.

So I guess the goal here is to achieve “jump next”. Seem to be fixated on accomplishing this by jumping between cues on a specified layer. WATCHOUT does not have a built in function to do this remotely, but the tools to build such a function exist. Anyway. What I have done in the past to achieve a functional similar result is use a control cue as a marker with a reserved name. For simplicity, I reserve the letter Q for this purpose. i.e. control cues whose name are “Q” are my jump markers. Doesn’t matter if they are pauses, run, etc, doesn’t matter what layer they are on although I do collect them on a single layer - if a control Cue is named Q it is a valid jump target. From there, the IP command gotoControlCue can be used to accomplish both jump forward or jump reverse. If MIDI is to be the trigger, I would trigger an auxiliary timeline to send the IP command to localhost. (And since I am a staunch believer in performing in cluster mode, I design aux timelines for both production mode [port 3040] and cluster mode [port 3039] and switch between them with a generic input). This technique provides the equivalent function of left or right arrow jumps. Basically forward or reverse to an arbitrary target that allows me to simply and clearly define what I consider to be a “Cue”. While working from the keyboard <Ctrl-F><Q><Enter> jumps forward. The Find command remembers the previous entries, so after the first time it is just <Ctrl-F><Enter>.

Simple answer is No. You have not provided enough information to even guess at a cause. Experience suggests a few possibilities - incorrectly encoded media or improperly prepared hardware being the most common. Video Encoding How to encode HAP files for WATCHOUT playback What tools can I use to encode, decode and transcode my media files? Which video codecs are supported by WATCHOUT? 4:4:4 Color - which codec to use? Operating System - Windows How to choose the right Windows 10 version for WATCHOUT? What is the difference between Windows 10 Pro and Windows Enterprise?

You seem to be requesting a very specific method to achieve a goal that is currently available using a different method.

That can occur when watchpoint loads at startup before Windows has completed its initialisation. Quick test is to simply manually quit and restart watchpoint without restarting Windows. If the restart test is clean, then adding startup delay to watchpoint should address the issue.

Probably so. But if EDID is obtained from the display chain, it could exhibit varying behavior vs EDID that is locked down.

codec? it matters

Any updates are applied by TRAX. Procedure varies if it is a SMARTPAX or SMARTPAX QC.

This could be related to the display or the display chain (adaptors and cables connecting the display). GPU settings are also a possible concern. While this type of thing was less unusual in the analog days, less common in a full digital display chain. Anyway, more detail on the display and connection chain might be helpful. Seriously doubt this is a WATCHOUT bug however.

The Keyspan model USA 28X, USB to Apple serial adaptors were bulletproof. Connects USB to the standard TRAX cable. They still show up in the used market. https://www.priceblaze.com/usa-28x-Tripp-Lite-Accessories-Cables

Yes it is. This is why you should not type an IP address in a display configuration - it masks the real problem. But it does not eliminate the real problem.

Understood. You never answered my question. Can QLab send MIDI Show Control cues? You want it reliable, operate in Cluster mode, not Production mode. (puts on nomex suit) Assuming Qlab can send MSC, the best way to accomplish 'one operator running both' is to send MIDI show Control 'Go cue number' cues. Not blind Go, but timeline position specific Go. i.e. 1, 2, 2.0, 2.00, 12.67, 15.2.3 are all examples of acceptable arguments for the MIDI Show Control 'Go cue number' command accepted by WATCHOUT. Pick any numbering system that suits you. Each pause cue in your timeline that is a waiting point for a Go, is given a cue number as its Name. I would assume QLab can distinguish between each cue point and provide a Cue number related to each Go position. Then you do not need to worry about getting them synced up, etc. Anytime you send a valid 'Go cue number' it will immediately synch. Even if a cue were somehow missed, the next cue would resynch automatically. So a Display Computer in read only mode responding to specific position go commands will make the WATCHOUT system transparent to the operator. Repeatable. Reliable.

Need to better understand what you mean by that. If i wanted to provide a blind go to the Main Timeline triggered from a MIDI note, I would create an Aux timeline with the MIDI note in the trigger field. The makeup of that Aux timeline would have a lot to do with how it functions. Also, the WATCHOUT version could make a difference depending on mode (Paused vs Stopped) and time position of the Control Cue, as that behavior changed at some point. Although that is probably not the issue here. If I were to do it that way (and I probably would not). The Aux Timeline would have one Control Cue at time 0 which simply told the main timeline to Run, immediately followed at time 0.010 by another Control Cue which told the containing Aux timeline to Stop, so that it is immediately ready to function again. If the Aux timeline is allowed to run for any length of time, then while that runout is taking place, it would appear to ignore the MIDI note trigger. It would not actually ignore it, it would appear that way as telling a running aux timeline to run would appear to have no effect., A blind go would never seem to be a "reliable" method. Can QLab send MIDI Show Control cues?

Make sure you have chosen the correct network port on the WATCHPAX 60. Ping is TCP transmission, the network discovery of display servers are UDP transmissions. Is your switch possibly impeding UDP traffic?

When you define the Live Video media object, there is a choice for the input device number set on your display computer in the Basic tab AND and under the Advanced tab a choice for Signal Input. It defaults to 1. Signal input should allow you to select the other input. https://www.dataton.com/watchout-users-guide/commands/media-menu#add-live-video

Are not these windows resizable? Or are you requesting variable magnification?