jfk

No, should not matter. The fact that it runs correctly sometimes and acts up at others brings another possibility to mind. I have encountered network switches with automatic UDP storm / UDP flood / denial of service (DOS) protections. In those cases the switch interprets watchout's continuous UDP traffic as an attack and kicks in those protections (so it works for a while until the switch takes protective action). But that should not occur on a simple unmanaged local switch, although I did once encounter a D-Link unmanaged "secure" switch that included those types of protection.

Simple way would be to use the Solid media object to create a rectangle larger then the live input and then place the live input object on a higher layer, covering all but the outer portion - voila - border.

Yes, it will work in cluster mode providing the TCP output object is set to port 3039 as it is done in my examples. The cluster master handles the DMX communication. The online comment only relates to Production mode.

Using two DMX channels, one for mute on and one for mute off makes this way more complicated than it needs to be. Additional programming is required to support both cluster mode and production mode, using conditional layers to switch between modes (otherwise if you left both active, there would always be errors). In production mode, you must be online for this to work. ... (damn forum system shrinks this image, original image) for cluster mode ... Use the set condition option on the cluster mode load command , like load Sample_DMX_audio_mute_control True True 2 On the other hand, using a single channel, it is super simple, no special programming for production mode / cluster mode, works either way. No need to set external TCP control of production. No need to use conditions. No need to use Tasks. Works in production mode online or offline. It as simple as this ... (damn forum system shrinks this image, original image) The two shows above (without the audio file, substitute your audio file in the media window) can be downloaded from http://dataton.net/watchout/DMX_mute_stuff/SampleDMXcontrol-audio_mute.zip

Hi Lucas, I had hoped to do this last night, show opens soon and I will not be able to get to it until tonight (US time zone).

It is not a built in function, you build a custom set of functions using the available tools in WATCHOUT. Yes, I can explain it, but before I go through that exercise, need specifics so I do not have to do it multiple times. • WATCHOUT version you are using? • DMX universe and channel for engage mute. Value that will be sent to trigger (easiest way is if 0 value is not active, any non-zero value is trigger, but if you need something else, please describe) • DMX universe and channel for release mute. Value that will be sent to trigger (easiest way is if 0 value is not active, any non-zero value is trigger, but if you need something else, please describe) Keep in mind that you must reset to an inactive value after each trigger / before next trigger. i.e. if 0 is inactive, then after setting a non-zero value to trigger a state change, you must return to 0 before attempting the next trigger. Understood, not needed. WATCHPAX will be sending TCP to localhost to trigger itself, no other TCP needed. I am working at Infocomm 2019 (USA) this week, so it will take some time before I can provide that (have it by tomorrow morning).

Are you saying it is not possible? If it is possible, then the solution is quite simple. Otherwise, the solution using two channels is quite complex - you will need a TCP string output, a generic input, two auxiliary timelines and the two DMX inputs. Either single channel or two channels you need to multiply all audio tweens by the designated input value. And how do you propose to change the mute channel and un-mute channel? There has to be a state change from false (DMX set to a predetermined value or range of values) to true (DMX set to a different predetermined value or range of values) to trigger a mute change event.

Sure sounds like you have a network problem. Is there more than one NIC in your display servers?

I am curious why you would not control master audio mute at the audio system? "What i know you can is with DMX controlling the complete audio volume but that is not ideal. " ??? Why? Do not set audio volume with the DMX input, simply multiply all audio tweens by the input value. "I need one channel to mute the audio and one channel to unmute the audio." That seems unnecessarily complicated. One channel at 0% for off/mute and 100% for on / unmute would make more sense would it not?

I know English is not your strength, but there is a bit that is unclear ... Maybe, what is the exact string you are sending and the exact message you are receiving in response? A null is a valid response to some commands. Use command ID tagging to force a response. I can not answer that question, that is the builders responsibility to solve through testing. Does not sound like it though. Possibly. Could just as easily be related to hardware performance, codec choice / encoding settings,- movie resolution and frame rate, etc. Depends, did you build from a blank disc and than accurately follow the win 10 tweaking guide already - if so, no. Are you starting from machines that were purchased with Windows 10 on them, if so, yes. But I would not do that until other areas are eliminated. That is twice you have mentioned "remain paused". what does that mean? Does it remain at the startup logo screen? Does it load the show but does not run with the other server? Starting out of synch may be related to how you are starting them. Please provide the exact command you are sending that results in " ... videos starts slightly out of sync ...". Are you triggering auxiliary timelines? and if so, are you managing their state changes? At may be as simple as adjusting how you start things.

Q. The last time I upgraded some keys, I did physical key swaps. I presume this is the way we'd go for this one? A. In some cases, rental houses will opt to hold on to the old style WATCHOUT v5 key and electronically upgrade them. Why? Because … The Microkeys, while not impervious, tend to see lower damage rates than the older larger keys when used on external USB ports. If you have working MicroKeys now (yes, there were v5 MicroKeys before v6). it makes no sense to swap them for less capable v6 only new MicroKeys. Working or damaged v5 keys are accepted for v6 upgrade swap, bypassing the damaged key replacement fee if your key was not working. First generation keys (two types) Original WATCHOUT 5 key – includes 2 Gb nonvolatile storage these were more delicate than later offerings and some distributors refuse to upgrade the "black keys" electronically and insist they be swapped. The first metal case v5 replacements remained first generation compatibility – includes 2 Gb nonvolatile storage Second generation silver metal keys no non-volatile shortage There are silver metal cased keys with no storage that are second generation compatibility. They look a bit like the ones pictured above, typically a bit shorter. <picture not found> Second generation key / third generation key - MicroKey no non-volatile shortage Microkeys all look alike, both the second and third generation MicroKeys can not be distinguished visually. Use WATCHOUT Production License Manager to confirm if they are either

i may be misinterpreting what you are saying, but it sounds like you are sending IP commands to BOTH servers? If so, that is incorrect usage if those two servers appear in the stage window of a single show. (A cluster is defined as all displays in the stage window of a single show.) When operating in cluster mode all IP commands for load, transport (play, pause, goTo, etc that typically require authenticate 1), input (timecode, MIDI, ArtNet), output (ArtNet, string-TCP/IP, etc), are only sent to the cluster master. The cluster master is defined as the last display station to receive and successfully execute a load command. When a load command is requested, the cluster master looks in the show file for a list of all display stations in the stage window, and sets up communications with all of them. i.e. establishing cluster. Most communication between cluster master and its members are UDP. The only time you communicate individually with a display server is for administrative functions, the ones typically requiring authenticate 2. (getMACAddr, powerDown, invoke VNC, etc)

Of course. Instead of just placing only the MIDI controller name in the tween, place a formula. For example, if your combined screen width in a three screen blended show is 5,247pixels, your MIDI controller is named Xposition and you want to tween the x axis of the position tween, use the formula Xposition * 5247 if your leftmost screen starts at 100 pixels, then use the formula Xposition * 5247 + 100 At the end of the day, a single MIDI controller input only has 127 steps, so setting an x position across a 5247 pixel space results in 41 pixel jumps for each minimum step in MIDI controller value.

Not exactly. It is similar to jumping on the timeline. From the time you activate a condition, some time is required to load any active content on conditional layers before it can be displayed.

The WATCHOUT version is significant in answering this question. There has been anomalies observed related to hardware assisted synchronization in some older versions and they have been addressed.