RBeddig
-
Posts
627 -
Joined
-
Last visited
Posts posted by RBeddig
-
-
Are you using some kind of control gear to interact with your show, e.g. a MIDI fader box, Streamdeck, DMX,...?
Basically fading the new timeline over the existing loop is very easy since only the new timeline needs a fade-up at the beginning. Just make sure that the timeline sits above the one you want to fade-out or is set to "always on top" in the timeline settings. If you want to fade the audio of the loop you can add a tween and connect the tween to an input. If you don't use DMX in your show you could use a DMX channel and connect this to your tween. "Tween Value * DMXvalue"
Since you can also control DMX as an output you can do this at the beginning of your new timeline. If you run a production computer in your show, you could also use a string output and a generic input sending the command "setInput xyz 0 1000" where xyz would be the name of your input, 0 the target value for your tween and 1000 a 1 second fade.
As I said, there are various ways to do it and it depends on your whole setup and how you're controlling your show.
Actually you might consider to enroll in one of our Certified User training sessions where we also explain a lot about controlling WATCHOUT in and out.
The training sessions are hosted by various premium partners around the globe in English and local languages. More on this on the Dataton website.
0 -
There are various ways to do this. Depends a bit on your scenario and how you want to tell the sound to fade out and to start the next timeline.
Look at "volume" tweens, task triggers and inputs.
0 -
Thanks for this input. Can you specify which version of .net caused the problems for you?
0 -
Well, we have done this years ago with WATCHOUT 4 when the promised show control system never arrived in time. We had to power up 60 players in the morning and put them to sleep in the evening.
Our work-around was to use a looping auxiliary timeline with a length of 23:59:59. The timeline was aligned to the current real time when started.
Of course, the accuracy is not good enough if you need to start things at a certain second of the day but if it is not that critical it can work.
0 -
Yes, you can return the broken key and buy a replacement key which will cost you something around 100 EUR. The best is probably to contact your local Premium Partner.
0 -
I don't know where you're based. We keep track of stolen licenses (have not learned of a stolen server yet) in our part of the market. Ask your premium partner to take a note of the serial number and maybe send an email about this to business@dataton.com to prevent the illegal user from updating the license once the next major update of WATCHOUT gets released.
0 -
Hi Michael,
Have never seen or heard of this product and maybe it's not available in Germany at all. What I'm missing in the description is the word "active". If you want to use it with AMD graphic cards it should be an active adaptor.
0 -
Thanks,
We’re now in event mode but I’ll test it tomorrow evening.
0 -
Hi Benoit,
Thanks for your input. I tried to send the NDI signal from a Birddog Studio NDI and the Newtek Scan Converter. Both worked on the production computer and a third PC but not on the server. Since the same happens on a traditional capture card, it feels as if some core component used for rendering the live feeds is broken or missing on this machine.
/Rainer0 -
Hi,
Maybe someone has experienced this as well and found a solution.
I'm on a show with a server set up by my client running WATCHOUT 6.5.5 and Windows 10. It works fine except that a live image captured into a Datapath VisionAV SDI card or through NDI stutters badly on this server. It looks as if the first 10 seconds or so are fine and then the stuttering starts. I deleted the NDI driver and WATCHOUT and made a fresh installation of WATCHOUT 6.7 but this didn't cure the problems. I've used both capture solutions very often before with my own servers but never had this experience.
On the production computer the NDI signal looks smooth in the stage window. We could rule out network issues too since also with a dumb switch in between it didn't change. Since the capture card shows the same problem I assume that something in the server is configured wrongly. Any idea what to check or look for?
We also tested the NDI signal with the NDI monitor tool on a third computer and this looked fine too.Maybe someone has come across this issue and was able to solve it.
0 -
The loading command is something which takes a moment on each computer. The master has to analyze how many other computers are involved in this show and inform those to also load the show file. They then all load and report back to the master. On "normal" controls, like run, halt,... the master just fires it off to the rest of the then already established cluster. If it is only one computer, the master is on it's own and doesn't have to wait for responses.
0 -
Yes, it works but be aware that you can't frame lock displays with a sync board when you use different resolutions. This would only work if all outputs see the exactly same EDID.
0 -
If you want to control the display cluster over IP, the display computers should run under an IP address.
Step one: upload the show from the production computer to the display computers and test from the production computer that everything works as expected.
Step two: go OFFLINE !!!!
Step three: open a connection to one of the display computers on port 3039 (I would actually rather use PuTTY, which does not need to be installed, just run the exe).
The benefit is that you have to type the strings one after the other which will give the cluster enough time to process and answer
You can also use PacketSender but I would first isolate the various bits a bit. When you send the "authenticate 1", WATCHOUT will open the connection and confirm.
When you then send "load "YOURSHOWNAME"", the cluster primary will connect to the other members and wait for their confirmation before giving you an ok.Your string looks a bit strange too. It should be: (<ENTER> depends on which software you use, for PuTTY it is just pressing the enter key, for PacketSender it is \r)
authenticate 1 <ENTER>
load "YOURSHOWNAME" <ENTER> - no ending like .watch or so!
I'm using this feature very often and it works almost the same since WATCHOUT 1, only that you can run auxiliary timlines today with "run "YOURTIMELINE"". Those didn't exist 20 years back.
If the communication doesn't work with PuTTY, then check your firewall settings or other network issues which might block the communication.
Important: turn all NICs off on your production computer except the one you're using to control the cluster.
0 -
I would temporarily connect the computers with an unmanaged switch still. If you then see less lagging you can ask the IT guys to look into the switch settings.
0 -
Then it looks like a configuration problem somewhere. We're using small computers with Intel graphics and even there we do not see this behavior. The only other reason I can imagine could be some issues with UDP network traffic. WATCHOUT uses TCP and UDP and sends out a heartbeat signal. Have you tried the connection without a switch? Can you check a different NIC?
0 -
It actually sounds a bit odd to me.
Small PNG files should start immediately. If you want to make it easier for WATCHOUT to pre-load files, you set a manual pre-roll. If you then wait inside the pre-roll, WATCHOUT will load the file and just wait for you to fire it off.
On the other hand, I would first try to rule out any other issue here.
My test would be to run a straight and tested network cable from your control computer to the server (no switches) and then use PuTTY or PacketSender to fire off the commands. Does it also lag this way?
0 -
Could depend on how much data you have to read from the disk at this moment.
WATCHOUT usually pre-loads media a moment before rendering it. If you just start an aux timeline with a heavy video sitting at 0.000 in the timeline, a small hick-up can happen. A way to avoid this would be to pre-load the aux timeline and keep it at 0.000 until you actually fire it off.
0 -
Elgato Streamdeck and the Companion software could also be a good option to control a sole display server (cluster). Have done this for clients to operate WATCHOUT on trade shows without access to the programming interface.
0 -
Take a new empty show, create an input "x" and send your command to this new show. I'm sure that there is a typo somewhere since the command setInput (capital I) definitely works. We're doing this very often and it never failed.
When in doubt I usually use PuTTY to test my commands first before using a "real" show control system.
0 -
It's true, load "" won't work.
But if the aim is to reload the show for whatever reason, I'd probably create a second empty show and then just toggle between both using the load command.
0 -
I haven't tried it myself but you might be able to send
load "" (to unload the current show, might send an error that there is no show with an empty name)
and then
load "yourShowName" to reload the show again.
It would of course not restart WATCHPOINT but the actual show file.
0 -
Those rather cryptic errors are usually seen when you add bigger files and then e.g. click into a timeline while being in LIVE mode. The reason is usually that the file is still traveling to the display computer but since you clicked somewhere, the production software wants to see the result of your action on the screen immediately.
Since the display computer can't load the new file before it is fully copied to the display computer and analyzed, it will throw those strange messages which can be ignored in this case. Since the display computer might as well be really busy copying at this moment, it might feel to the production computer as if it is temporarily lost. Red X.
Try to set the preview to thumbnail only to reduce the load on your production computer and maybe try to turn off the LIVE mode.
0 -
Where is the command
load "yourShowNameHere" ?
Do you have an input defined with the name CVol ?
Watchout is case sensitive!
0 -
Have you tried to read the signal with a second computer running the timecode reader software which comes with WATCHOUT? This could give you some indication on the signal quality. I have seen one situation many, many years ago where a lighting console had problems to read a timecode from a file in WATCHOUT. The reason was a very small timing detection window on the receiver side which normally is a bit wider in most devices. The solution back then was to use a Rosendahl MIF3 which was able to read and re-clock the signal.
Since WATCHOUT is constantly re-syncing all player instances of a WATCHOUT cluster you will probably see some tiny jittering in the timing of the timecode signal.
Another option would be to check the signal shape using an oscilloscope. If it looks more or less like rectangles it should be fine. If it doesn't, it will probably fail. The reason here is often some (audio) device in the signal flow which doesn't forward a clean rectangular wave. I have seen isolation transformers destroying the rectangular signal.
0
Fade to sound
in WATCHOUT FORUM
Posted
Then you should be able to do all this using the control API which is described on page 175 in the manual.