jfk

The short answer is - no. TCP/IP Generic input is not the way to approach that, you have to connect and obtain permission, most simple sensors are not that smart and would require an intermediate device (Medialon, Mediamation, Crestron, AMX etc.) to interpret the input to the IP format and manage the IP connection. I would think sensors that transmit MIDI notes or MIDI continuous controllers would be the easiest way, that should be straight plug and play. Once you know what you want the "sensor" to do, post on the The Show Control Mailing List, you should find some good input there.

Pretty generic question.How to set one up in the WATCHOUT input window? How to use one that is already setup? The format for the command sent from a controller? Generic input is only available when commanding a Production Computer via Production Computer Protocol (ref: WATCHOUT 5 User Guide - Appendix D - pg 241) No Display Cluster Protocol equivalent. The generic input accepts an unsigned floating point value to WATCHOUT Production via IP command from a controller supplied by others. So it only accepts a value. I like the ability to override a DMX or MIDI controller input if need be. :thumbsup: From there you use the name you assigned when you made the input as a value in the expression string of live tweens or in the task window condition field.

That is one way to do it, yes.But if you do it that way, then no, you can not use command files with that method. You enable timecode chase in the production computer preferences, save the file, and it will remember that preference when the file is reopened. You can automate show load on Production from a third party control system via IP, but not a command file. I think we are mixing our metaphors here. There are two chapters in the User Guide related to control - Appendix D Production Computer Protocol and Appendix E Display Cluster Protocol. [strong]The two are mutually exclusive.[/strong] Display Cluster Protocol only works when the WATCHOUT Production system if offline, better yet, with no WATCHOUT Production system at all. The only time the script you posted would work is when there is no production computer online, and the WATCHOUT Display group defined in the orignal show file's stage are acting as a single playback entity, i.e. Display Cluster Protocol You have got a command script file working on WATCHOUT Production (watchmaker.exe)?I did not catch that new feature, can not find it in Appendix D Production Computer Protocol. No timecodeMode command in Production Computer Protocol either, timecodeMode is unique to Display Cluster Protocol. Maybe I misunderstand. If you [em]meant[/em] this is how you [strong]think[/strong] it works - you are wrong. If you meant you really do know how that works with Production, then I am wrong - please "school me". In WATCHOUT 5, for the first time since version 1, new commands were added to Production Computer Protocol, so maybe there is more new there than I am aware of :iono: No, if you re using a script in a file that is executed on the start of WATCHOUT Display, you do not feed the SMPTE to Production, since by definition Production is not online, you feed it to the one member of the group that contains the command script. You put the script file and modify the shortcut to reference the script file on just one display machine. You feed SMPTE timecode to the audio input of that same machine (with the command script), and it syncs all the others over the network. Pick any display machine, does not matter which one, but choose just one. WATCHOUT Display with the script file learns who all the others are from the definition of your stage in your original .watch show made on production. Production transfers and stores that info to the displays when you go online or update. The display cluster load command executed on one display from a script file loads the show on all displays in the cluster by using the stored list of cluster members for that show placed on every display during the show transfer process. So even though the info needed is stored on every display, you only need to execute it on one display, it will manage all the others.

There is nothing in the IP [strong]control[/strong] commands to do this. You may be able to accomplish your goals with output devices and output commands on the aux timelines to communicate this to your iPad apps.

But it seems its not ok, a message of : "invalid file data format. Shows made on older versions of WATCHOUT must first be saved using version 2.3" is shown Also i tried the timecode reader and it seems to work ok so the machine is recieving the timecode... Can anyone help me with that? It appears as if your script's load command is failing.Once a script command fails, it stops executing, so if the fail is occurring on the load command, the script timecode command never executes. BTW kudos for explicitly stating the timecode format (EBU 25 fps) in your timecodeMode command You indicate your load command as load "the path of my show" [strong]You should never enter a path in this command.[/strong] The path is implied to be the shows folder of the watchout display computer. The only control over path on the display computer that you have is either the location of WATCHOUT Display application file (watchpoint.exe) which is the default location for the "shows" folder or the command line option to set an alternate path . This can not be done in the load command or any script command for that matter. If I have misunderstood that part of your posted script and you are doing it correctly ... Do you have more than one copy of WATCHOUT Display installed on your computer? (search the entire PC for a file named watchpoint.exe to confirm, there should only be one). After receiving the error, without quitting WATCHOUT Display (if it is still running, window or full screen mode), open your show in WATCHOUT Production and go online with the display(s) in question to update the stored show materials. Go offline and quit WATCHOUT Production and then retest. You might find it useful to use the setLogoString command as a troubleshooting aid. Something like this: Note: This forum is a bit too clever, automatically substituting the fancy curly quote marks ( "" ) for quote marks entered as standard straight quotes. I have not figured out a way to overcome that on these forum posts :banghead: So if you copy and paste WATCHOUT commands out of a forum post, you must correct the quote marks - the "curly" quote marks will cause errors.

I am not going to recommend a switch, but beware, the OS you are running may make a difference. Win 7 changed the default NIC settings and some switches will not play well together with Win 7 until you adjust the NIC settings. Symptom is super slow network transfer and what appears to be network loss, reported by watchmaker. This is a common issue independent of WATCHOUT, google "windows 7" "slow network" and you will find lots of info on addressing that issue. Point is, what someone finds works well for them may not work well for you with Win 7 without the proper tuning. It is easier just to search for an unmanaged switch that specifies Win 7 certification.

There is no cluster control of power. The production computer (watchmaker) talks to each individual WATCHOUT Display (watchpoint) computer to power them down. No big deal with IP like watchmaker does it. So if you wanted to do it through RS-232, at the least, you would need to connect and enable RS-232 to every individual computer. to powerDown an indivual watchpoint computer, connect to that computer, authenticate at Level 2 and send the (case sensitive) command powerDown Another useful individual / level 2 watchpoint command is getMACAddr Retrieves the MAC address of the watchpoint computer connected too, if possible, as six bytes. A General Runtime Error is returned instead if the MAC address is unknown. Example: getMACAddr Reply 23 33 12 45 143 230 where Reply is the response returned by WATCHPOINT for the command. IP control users probably want to use command tagging here to tie the response to the query. watchmkaer sends the getMACAddr command and stores the MAC address for later use on power on (Wake On LAN). That is why you must first power down from watchmaker before power up can work. (and after a successful power off / power on cycle, save your show file to store the MAC addresses). Of course, you can not power on with RS-232, as that port is dead with power off. The NIC of course is designed to provide power up with the computer off.

Hello Rogier, The Move command comes to mind, but I don't think you can simultaneously move displays on different tiers. Display settings are usually set and forget, aren't they? That math is often worked out before media is created. In the rare instances where the stage is re-arranged, it is not that big a deal to duplicate the new settings. I think you are doing it the right way now. For backup or double stacked projectors, the advantage is you have discrete / separate geometry and colorimetry adjustments with unique display objects.

Seems your license key driver may be failing. What version license key (wibu) driver are you using? (the one in the WO 5 installer has shown this issue on some systems, a newer one on wibu's web site cures it.) Next release of WO 5 will have the newer driver in its installer. WATCHOUT will check for the license on a continuous basis. While the response to license removal is not immediate, you only have a minute or two to replace it. v1.0 was the only version that only checked at startup / online. When 1.0 user's reported they could start their backup system, move the keys to their primary system, and run all day with both systems - the next version corrected that nonsense. :wink:

Well kept secret until now I guess. Couple of details. As JJ describes, the -NoLogo command line switch is placed on the display computer shortcut(s). You must do this to every display computer in the group to eliminate all logo screens during update. It is a good idea to rename the shortcut with the -NoLogo switch to indicate the modification. I name mine "watchpoint no logo", but you may use any name you choose. > You will still see the logo screen until a show is loaded. Once a show is loaded, you should not see the logo screen again with that switch in place. Nov 2013 startup behavior is changed in v5.5.1+ On start up, before a show is loaded, you now get a black screen, there is no logo, but the informational text portions of the logo screen remain until a show is loaded. dded Oct-2016 Pic of -NoLogo startup screen (before a show is loaded only) > As always, with this switch since v2, once a show is loaded, as long as you maintain full screen mode, you will never see any of the logo screen again - update or go online, with this switch enabled, the show simply freezes where it is, instead of jumping to the logo screen With -NoLogo in effect, the show will freeze wherever it is during updates, it will not stay running.

It is possible that audio files in your v4 show are the cause of the load error in v5.Seems v5's new audio waveform display in the cue can cause this, for whatever reason WO fails rendering the waveform image and the lock-on-load results. Try removing the audio cues in v4 or move the audio files from their correct location so WO 5 fails to find them. This should get the v4 show open in v5. Once it is opened in v5, bring the audio cue(s) back and it will still fault, but not fatally, WO will then bring the audio into the show without the waveform display. If need be, use an audio proxy to get around the waveform render error.

I thought I might post a clarification here,as I spoke with someone today who may not have interpreted this correctly.WATCHOUT 5 only works with one graphics output card.That one graphics card may have up to six outputs provided the graphics card vendor includes driver support for multiple ouptuts under DirectX in 3D mode.The AMD/ATi Radeon with Eyefinity does support more than two outputs with WATCHOUT 5.Not all vendors do that.

Ignoring the economic issue, like the OP's request,for asset security management in some environments, there is value to remotely serving the licenses . There are both upsides and downsides to remote license service. If a license server goes down, all WATCHOUT computers will soon go offline. We have entertainment fixed installation live event customers who simply will not trust the operation of every display to a single computer / network, and in v2-3-4 that decision carried significant expense. From a marketing standpoint, ok, v5 erodes revenue per sale enough, I can see the disincentive for even further discounts on large volumes, and in the past cost saving was the primary reason to choose a site license.

With v4 - use VNC and a host computer to generate the clock image, crop, position and scale in WATCHOUT as needed. A simple Flash app running on v5's WATCHOUT Dynamic image Server would do the trick too.

That is more of a function of the movie decoding codec than WATCHOUT.WATCHOUT itself has no limits, it is bound by the limits of the codec chosen. The movie decoders do have limits, and different encoding (mpg, wmv, avi, etc) have different restrictions. It gets more confusing with QuickTime, as two .mov codecs (h.264 and animation codec at 32+) are decoded by non-Quicktime decoders, so their limits are dictated by their Windows native multi-threaded decoders instead of QuickTime.

Right, that was the distorted major use of the old feature, thanks for correcting me ;-) As I recall, it's original v1 purpose was to display a media object that entered the blend area only if it were in the non-blended areas too. It would not display at all / disappear when the object was only in the blend area. Useful if you have a capture card in less than all of the displays, as you can prevent the error that would occur if the live input touched a display without a capture in just its blend area. Was kind of the pre-cursor of pre-split proxy too as I recall, as the same would apply to movie files, if a movie from an adjacent screen entered a blend area but not the non-blended area, it would not play on the adjacent machine. Either of those old tricks would require tiers to pull off ;-)

The edge blend line went away with the introduction of stage tiers in 4.0.Depending on what you are trying to accomplish, there maybe a way to achieve an equivalent using the stage tiers.

Got it, thanks. That method still retains the same restrictions as with earlier versions. i.e. since you are spoofing WATCHOUT by using a single display object to output multiple displays, you lose blending, independent geometry, no compensation for mullions, tier functions are lost, etc. FYI That is different than Display Port 1.2 Display Port 1.2 essentially runs independent streams over one connection. So WATCHOUT will still see individual displays in the stage window. [strong]D[/strong]isplay [strong]P[/strong]ort 1.2 displays will be able to set an address, and will likely include a DP In and a DP Out. Multiple displays can then daisy chain the single connection, each extracting its stream and forwarding on the rest to the next display. Seems there are mechanisms to retain synch when doing this too. Also would be great for handling left eye / right eye 3d steams on a single connection. To accomodate existing DVI infrastructure, q4 this year, ATi/AMD plans to release a DP 1.2 MST hub, extracting and converting the DP 1.2 feed to three DVI outputs. That would allow a GPU card with two Display Port 1.2 outputs to drive six DVI displays and appear as six unique display object on the WATCHOUT stage.

Yes, that is a good idea.Unlike the main timeline, which has no stop state, Auxiliary timelines have three states - Stop, Pause, and Play. Stop is a dormant state, no media is pre-loaded. Pause is an active state, pre-loading media for immediate response. Play is an active state (obviously) and acts like a timeline play. As JJ notes, going directly from Stop to Play on an Auxiliary timeline takes some time to load up. So yes, pressing stop before pressing play will toggle the Auxiliary timeline to pause, essentially pre-cuing the timeline for more immediate response to Play. (When both Stop and Play buttons in the task window are not highlighted, the aux timeline is in pause).

I am not sure I understand the Matrox part of that correctly.WATCHOUT 5 only supports one graphics card per computer, with up to six outputs on that one card. There is no support for multiple graphics cards. (SLI / Crossfire acts as one card, so that could be a little confusing). If that Matrox thingy is working outside the computer on high res outputs and not in the machine, then I assume those can be fed from a single card with three outputs.

Actually, in WATCHOUT 5.0, you can not do that.v5.0 requires all outputs from a single multi-headed computer be the same resolution.

You can try the 23.98p, the display output is still 60p, so WATCHOUT has to do the 60p w/pulldown conversion on the fly, adding to the load. The 24 fps complaints are typically related to motion artifacts. Apple ProRes is a heavy processor load codec, you may find it will work, may not – computer has a big impact there. In general, Apple QuickTime makes poor use of Windows multi-threading, under-performing in comparison to codecs that are native to Windows. As for the conversion and Sorenson Squeeze, I hear both good and bad reports on Sorenson. I will leave it to others to assist you on that front. If ProRes won't run smoothly, try h.264 and covert to 30p w/ pulldown in the process. A leisure time conversion of frame rate during encoding is likely to provide better results than a real time conversion during playback. Also, h.264 is one of two Quicktime exception codecs in WATCHOUT. It is not decoded with Apple's Quicktime decoder, a Main Concept mpeg4 decoder (installed by WATCHOUT 4.2+) is used instead. The Main Concept decoder makes better use of Windows multi-threading, improving the performance of h.264 playback.

No it is not to large in terms of its storage size.The file size does not really matter, as it is streamed during playback. It will play, question is, will it play smoothly? The files output resolution matters very much, the files encoding matters very much, as both determine how much is streamed per frame, how hard the decoding processors must work, and how many frames per second. (Avoid 24 fps whenever possible, convert it to 29.97, 30, 59.94 or 60 fps before using it in WATCHOUT). If you are trying to output one 7680 x 1080 at 60p or 3840 x 2160 file at 60p, your computer choice and its proper tuning along with the software variables above will determine if it runs smoothy or not. Should be possible with extreme hardware like the sample system at the top of this forum.

Yes.This is documented in the WATCHOUT 5 User Guide There are two methods for controlling WATCHOUT playback. - Control of Production is IP only. reference Appendix D Off by default, must be enabled in Production Preferences. - Control of a Display Cluster is IP or Serial. reference Appendix E, Cluster control via IP is straigtforward, as it is always available. Cluster control via serial is off by default and must be turned on a by a script, etc, also covered in Appendix E. Either method supports SMPTE chase input, DMX output and IP output. Production is only needed when you must rely on WATCHOUT to support and process user / live [em]input[/em] (MIDI, DMX, MSC, live tweens). Cluster operation and its control language is the more robust and versatile control method. When you have a full blown control system like Crestron, AMX, Medialon, Mediamation, etc. it makes more sense to process user input in the control package and eliminate the production computer / license . You can do that more directly with cluster control, as direct triggering of auxiliary timelines is available without using the Task window. Let your control system do the input decision making. If you are going to go the production / MIDI input route, use MIDI notes for triggers. Of course, we demonstrate aux timelines triggered via MIDI notes in the WATCHOUT training system.We are teaching production, so we have to have the production computer there anyway. When we cover playback control, we turn production off. Not really, that all has to be done on the WATCHOUT side anyway.Setting up the single IP connection in the control system can't be any harder than setting up a MIDI connection. Also one less loose part (MIDI interface) to deal with as no extra interface is needed for IP.

Inquiring minds want to know? i.e. one of our customers is asking the same question. Can anyone provide direction on the non-WATCHOUT section of the motion tracking solution used at InfoComm? The WATCHOUT side we understand - bitmap media object set to "Optimize For: More Effects and Capabilities", Inputs, Tween formulas, etc But how was the motion tracking accomplished up to the point of the position data provided to the WATCHOUT input objects?