jfk

Maybe, what is a cue server? You should be able to send commands to a control system using the WATCHOUT output object, directly from the WATCHOUT Display computers in cluster mode. Recently assisted on a project where this was done with Crestron. i.e. Crestron used IP display cluster control of the WATCHOUT system and the WATCHOUT Display system sent messages to Crestron via an IP output object. Two separate virtual connections on a single IP physical connection. There were devices under Crestron conrol that needed to be triggered by the timeline and the output messages to Crestron accomplished this. I see no reason AMX should not be able to do the same, but no first hand experience there. Hopefully an AMX knowledgable person will chime it on that.

Is it ok to place WO 5.5.1 on WATCHPAX using watchmaker's new version propagation? It works, I've done it, just want to be sure there are no reasons not to do it that way as opposed to installing a new WATCHPAX image.

FYI While you can still do it that way (maintained for backward compatibility), you don't have to do that any more, there is a newer alternate technique. Updated in v5, reference WATCHOUT 5 User's Guide, Chapter 8 - Commands - Pre-split - page 140.

correct me if I am wrong, according to some of your screen shots, Timing Server is set to to None, so with no timing server, timing client settings will not hold.

No, not individual movie files at this time, make your speed changes before rendering for WATCHOUT. There is an experimental function that provides via IP smooth realtime vari-speed of the entire main timeline ±20%, but that is not what you are looking for.

Mostly, they won't blend across tiers, so you may have to use phantom displays to overcome that (messy, but workable). The pre-split proxy deals with the hold back and the blending. And even more useful, pre-split proxy provides an option to assign one additional movie just to be used for the watchmaker preview screen. So instead of running video as thumbnails, you can provide a scaled down movie of the entire comp to display in preview.

On the topic of watchpoint / Spyder display signal interface, I have encountered issues with the Spyder to watchpoint EDID. Same issue, three different systems, one Radeon based, the other two FirePro / s400 based. All responded in the same way to Spyder EDID. The Spyder operator set the Spyder EDID for the watchpoint inputs to 1920x1080, but the ATi Radeon and AMD FirePro interpreted that EDID as a 1920x1200 raster with a 1920x1080 letterboxed image. The Spyder operator could trim out the extra, so it could be made to work that way, but that is as close as we could get with Spyder EDID. To get the Radeon or FirePro graphics card to actually output pure 1920x1080, we used a Lightware EDID manager on each watchpoint output utilizing the EDID managers internal settings for 1920x1080, and all worked as expected.

If you must edge butt streams, hardware assisted synchronization (v5.5+) is the only choice. By nature, all single slot multi-output GPUs (even FirePros) have an independent free-running clock for each output. The option synch module provides the synchronous clocks to achieve scan-locked synch among outputs. This synch function extends beyond one computer by daisy chaining its proprieatary synch signal bewteen s400 modules. The most tested solutions are the AMD s400 compatible FirePro GPUs with the s400 synchronization module. (not all FirePro offerings are s400 compatible). There is a compatible nVidia equivalent, it is also is accomplished with an option synch module proprietary equivalent to the AMD s400. the nVidia offering is even more expensive than the AMD solution IIRC, but that is also a constantly changing thing. As Mal indicates, prior to hardware assisted synchronization, the work around was to make a small overlap of the watchpoint streams (with watchout blends disabled) and blend them in the Spyder to mask the issue.

Have the audio files changed or are they the same ones that worked prior to the hiatus? Is there by any chance a live tween on the audio files? No hidden special sound settings in WATCHOUT, No command line switches related to audio, no external IP commands related to audio, all settings are in Windows. Check the audio co-processor's driver and make sure it is not from Microsoft. (driver supplier most likely will be the motherboard vendor when the sound co-processor is on the motherboard.) Does not sound like that is the issue, but to be thorough. Good luck

Any part of Windows (cursor, task bar, etc) appearing while watchpoint is in full screen DirectX 3D rendering mode is bad. Quit watchpoint and restart it and the problem will disappear. This most often occurs when the WATCHOUT Display computer powers up and runs watchpoint from Startup items. Other processes occurring after watchpoint starts are trying to punch through. You can possibly use WATCHOUT 5.5's new delay command line option to allow the other processes to complete and then load watchpoint without interference. • A command line option is added to the display software, allowing a delay to be introduced when the software is started. This may occasionally help in avoiding start-up problems, by delaying the start of the display software until things have settled down. To use this feature, append -Delay 3 to the shortcut used to start the display software ("WATCHPOINT.EXE"), where 3 is the desired delay in seconds. For more information on modifying the shortcut, refer to WATCHOUT 5.2 Users Guide - Appendix E pg 258 Another topic related to the same issue - Watchpoint starts, then disappears

It does, but the extra processor load for the extra work of generating those extra frames on the fly means you will encounter the systems thresholds sooner than movies that do not require the extra work. Will they play smoothly - yes. But where you might get four or six 29.97/30/60-p movies to play smoothly on a single computer, you might only get two or three 23.98/24-p movies of the same size before stuttering is encountered. i.e. use more hardware to offset the extra work needed. Same is true for de-interlacing, although less so than the 23.98/24-p conversion. No.

We have good results with Lightware products. Both the DA2DVI-HDCP-Pro when using a local confidence monitor or the EDID Manager V4 without. We like the fact that they have their own power supply (as opposed to drawing power from the graphics card's DVI port, which is typically not such a good idea). some do, some don't, that is determined by the extender. We have heard some horror stories about lower cost extenders, specially the HDMI ones that are made for video (YUV) more than computer (RGB) signals. If you are using fiber, Lightware makes an extender with an integrated EDID manager.

I'll let you off the hook on that one, its an easy assumption to make, albeit incorrect. The input window value indicators work the same for all input types. i.e. the indicator always snaps to the new target value as soon as it is received. MIDI and ArtNet/DMX inputs execute fades by sending a rapid stream of new targets, and as such the indicator animates the fade since there is no fade rate data, just a rapidly updating set of new targets. But MIDI and ArtNet/DMX inputs send discrete target, while the setInput command has the option of sending a vector (target and rate), and the indicator does not reflect the fade rate, only the target value

They are not going to sleep, they are literally shutting down when they lose valid EDID signal. They should re-initialze when EDID is restored, but that has its side effects too. Anytime the EDID signal changes, the graphics card reset. If EDID is completely lost, those outputs shut down. And that is a bad thing, as outputs can re-order as part of a reset or shutdown. Consider providing EDID managers on those outputs so that the outputs see a stable constant EDID signal regardless of what is going on downstream.

From watchmaker, there are direct Power Down and Power up commands you could use to do this. Yes, you could use VNC built into watchpoint to access the Windows Restart command as an alternative. As for deleting the cache - welcome to the risks of using watchmaker as a playback controller. As long as you do not update / change WATCHOUT versions, the cache can only be changed via watchmaker connection. If you playback in cluster mode with another form of controller, the watchpoint cache can not change and therefore any new issues related to the cache can not occur. If you think deleting the cache from watchmaker will help, go ahead, but that is not a panacea. It does not have any impact on movie playback. Deleting the cache does not re-transfer the media, it simply goes through the still image media already stored there and re-creates the still image cache.

That show file has no media, no stage objects and no cues ???? If you are expecting to see the Value field of the Input window animate the fade in its indicator, ain't gonna happen. That does not mean it is not fading in actual use. Yes, the value indicator jumps between 0 and 1 when the appropriate commands are received, but the actual result (sound output) does fade as expected. I just added a sound file (a sample file supplied with Win 7 called "Maid with the Flaxen Hair.mp3") and added a display to your sample show, attached the volume input to the volume tween formula of the sound file, connected and typed the setInput commands in MacOS's terminal program (after establishing a telnet connection), and the fades via production protocol work just fine. I even tried the 20 second fade and it worked as expected. Here are the commands that I tried, all worked as expected ... I would post the modified files for you if you would like, but I am running 5.5 and you are running 5.3.1, so you could no use them at this point anyway.

Depends on what version of WATCHOUT 4 you are using. WATCHOUT 4 was introduced before Windows 7, so the early versions of WO4 (v4.0, 4.01. 4.1, 4.1.1) are not Win 7 compatible. WATCHOUT versions 4.2+ are Windows 7 compatible. Incorrect driver initialization is a common issue. While WATCHOUT 4.x installs the license key driver, each time the key is installed into a new USB port, it is necessary to properly initialize that port. If you skip that, it needs to be fixed. With the key plugged in, go to hardware manager and look for yellow question marks. Another reason I have seen for v4 keys not recognized is the USB hardware drivers themselves. When Windows is installed, it places generic drivers so you can use a keyboard and mouse to continue with tuning. The generic Windows driver is not good enough, it must be the driver provided by the hardware provider. In most cases this is handled by the driver installation for the motherboard that contains the USB port. So if you check the USB driver and the source is Microsoft, it needs to be corrected. And if the driver is from Microsoft, you likely will have issues with other drivers typically associated with the motherboard - HD controller and sound co-processor in particular. Also, some USB 3.0 port's drivers have caused issues. Check to see if you can are using a USB 2.0 port, and find one instead if need be.

Out of curiousity, are you using Production Computer Protocol or Display Cluster Protocol? The command is the same for both, For command details, the Display Cluster Protocol references the section in Production Computer Protocol, so the page reference could be either one. That is odd, Clearly it does not matter since you are achieving the target value, but shouldn't the string value be in quotes? Also, of more importance, did you use the Limit setting of the Generic Input to redefine your range? The default range is 0 - 1.0 , for the defaults, your target value is out of range and should be 1.0 for 100% Have you checked the local error log after sending this command? with default limit, try setInput "Volume" 1.0 20000 I have seen the fade rate parameter used succesfully in both targets forms (absolute and relative) in Cluster mode. Albeit not at such a long duration, but I doubt that is the issue.

x2 Good point, I just downloaded it again from dataton.com, the download from WATCHOUT Systems Manager still is WATCHMan_1.0.zip. I also expanded the zip and attempted to re-install/update just in case the archive had been updated, no joy ... So Mike, are you leaking a new development to us here? Glad to see this issue is addressed in an update. ---- I also know iOS 7 breaks the iOS version of WATCHOUT Remote, when you update that app, will it get the reload button too? (I hope so ) v1.0 iOS Until then, the workaround above will keep you out of trouble

I have seen this occur when switching between WATCHOUT Remote and WATCHOUT Production (watchmaker). If the show is loaded by watchmaker, then watchmaker is placed offline or quit, and then WO Remote is opened, WO remote will not re-send the load command since the show is already loaded. The WATCHOUT Display (watchpoint) computer that is connected to WO Remote will be ok, but any other watchpoint cluster members will not respond correctly. The quick fix is to force WO remote to issue the load command by loading a different show and then reloading the correct show. I usually make a separate show file that addresses the exact same stage setup with a single image on each display (usually a text cue with the word black, and I name the show " black "). This gives me a quick loading show to jump to and then back to the real show. Cures the issue with the non-master members not responding correctly.

JG You are correct in your assumptions. However, All multi-output graphics cards, ATi Radeon or FirePro, or nVidia, do not provide perfectly synchronized output. Each output has its own independent clock. Granted WATCHOUT is writing to the outputs in synch, but with the free running clocks, there will be variations. The s400 synch module (and the nVidia equivalent) replace those clocks with synchronized clocks from the synch module. As most of you know, the synch variation without the synch module is nominal. You typically will not notice it with overlapped projection or mullioned flat panels. It is when you have a 0 pixel separation between the display streams or are feeding processors instead of displays that the variation begins to become noticeable.

Just to be clear, not all FirePro models are compatible with the s400 synch card, only some FirePro models, and typically the higher end of the FirePro line. So when selecting a FirePro card, be sure to choose a FirePro model that specifically states is is compatible with the s400.

Start of transmission aka STX = $02 End of transmission aka ETX = $03 So the above command string should look like this in WATCHOUT ... $02OSH:1$03 I would be a bit surprised if the carriage return is needed when ETX is used, but if the above does not work, try it with the carriage return added. $02OSH:1$03$0D

Yes, provided you have an appropriate PCIe x4 slot available (DeckLink SDI works in a PCIe x1 slot). We have a few with the DeckLink SDI Duo (and a few with the DeckLink SDI Quad as well) working fine in customer machines.

Yes. However, you might want to evaluate this before committing. The capture process can alter the quality of motion, progressive signals will look the better. If that is how you choose to do it, yes. With WATCHOUT 5, it might make better sense to use one display computer for both. How many feeds from the external source? Resolution and refresh rate? Depends on the source signal type. With a progressive input video signal, the same source signal type on the same make & model capture card will perform the same on any platform. i.e. a progressive input signal is transferred directly from the capture card to the graphics card bypassing the main memory / cpu altogether. interlaced signals will have higher latency as they do travel through the cpu first (to de-interlace).