Jump to content

Mike Fahl

Member
  • Posts

    729
  • Joined

  • Last visited

3 Followers

Contact Methods

  • Website URL
    http://pixilab.se/

Profile Information

  • Gender
    Male
  • Location
    Linköping, Sweden

Recent Profile Visitors

2,690 profile views

Mike Fahl's Achievements

(3/3)

  1. That's a "missing codec" error. Re-installing may help, since doing so re-installs codecs shipped with WATCHOUT. Or you may be using codecs not natively supported by WATCHOUT (you don't say what's in your MOV files). Mike
  2. Updated to a more contemporary nvidia card, with its nvidia-specific driver (didn't work with the "recommended" Microsoft driver), and it now seems to work OK. Mike
  3. I ran into the error shown on the enclosed screenshot when trying to launch the current WO7 version (downloaded today) on a Win 10 PC that previously ran 7.1. It has a rather ancient graphics card (AMD FirePro W7100), which may very well be the culprit here. But the error message isn't particularly clear here. Mike
  4. The WO6-style protocol is partially implemented in WO7, as you can see in the manual. It's TCP based, and does not require HTTP, so perhaps that could be an option for you? Mike
  5. While WATCHOUT's timeline based structure makes it intuitive and easy to program for linear shows, it doesn't lend itself well to highly interactive use cases, as you've noticed. However, such solutions can be realized by combining WATCHOUT with another system that's more suitable for interaction, using WATCHOUT for the visual aspects that work well there. WATCHOUT can also be controlled from the outside using inputs/variables coming from the interactive system. It's also possible to feed content into WATCHOUT using live feeds or web pages (e.g., using vMix, as mentioned by Benoit above, piping it to WATCHOUT over NDI or other capture methods). You can see an example of a very effective integration between PIXILAB Blocks and WATCHOUT in this story: https://pixilab.se/stories/cue-the-music Here, Blocks handled all the game logic, score counting, etc, and generated some of the content (artists, songs, durations, etc coming from a separate database). This was then fed through WATCHOUT, driving all the LED screens. The graphics on the LED floor was animated through a combination of WATCHOUT and Blocks controlling some aspects using variables controlled directly by the game logic (as seen in the video a bit down in that story). Mike
  6. I believe so. But it was a while ago... Mike
  7. If I recall correctly, that error means that WATCHOUT was unable to connect to the TCP port on the targetIP address. Verify connecting to that IP and port by other means (e.g., using a telnet client) to determine if connection fails there too. If so, check the devices that are supposed to receive the data to make sure that accept the connection OK as well as the network path to get there. I doubt that "multiple NICs" can cause this error. That typically only affect broadcast and possibly multicast messages, which this one isn't. Mike
  8. Any "PC remote control" that can fire of arbitrary keypresses should do (or combined with some software that can map keys as desired). You may prefer to send the numpad Enter key instead, since that will always start playback of the timeline, while the spacebar is a start/stop toggle (unless that's what you desire). Mike
  9. If you attempt Eddys' suggestion, I believe you should terminate by $0D$0A$0D$0A (i.g., CR, LF, CR, LF): https://stackoverflow.com/questions/50447483/end-of-http-header#:~:text=Each header ends with CRLF,for the HTTP protocol spec. This may work for single commands spaced "far apart", since WO holds the connection open for a bit after sending the command. It will then send any following commands on that already open TCP connection, which I doubt the other end will like in this case. Also, the action may be deferred until WO closes the connection (depending a bit on how the device implemets the HTTP protocol). I don't recall how the line endings for the other header lines are terminated when you paste in multiple lines like this. Those would also need to be terminated each by a CR/LF pair. But perhaps that's the case already, or he device may not be too picky here. Mike
  10. I dubt you'll succeed in sending HTTP commands from WATCHOUT. It just has basic TCP and UDP support. HTTP is a more complex protocol. The camera also seems to have a serial control protocol:´ https://eww.pass.panasonic.co.jp/pro-av/support/content/guide/DEF/HE50_120_SERIAL/ConvertibleProtocol.pdf As far as I can recall (it's been a while), WO can do serial. Alternatively, using a TCP-to-serial bridge, such as a MOXA nPort. If you really need HTTP, you probably need something else to talk to the camera, such as PIXILAB Blocks or some other control solution. Mike
  11. I guess you could make a timeline that's always active that sets an input depending on enabled layer condition. I believe you can get the input value from WO. That's more of a work-around for obtaining this, and would really only work for a single layer condition being enabled at a time, but could get you out of a pinch if need be. Mike
  12. That's done on the "Output channel assignments" tab, as suggested by Jim above.
  13. The geometry correction available for the regular display can have any number of adjustment points. Should let you warp things to match, assuming this is a static warp. Mike
  14. Do you really mean "VPN", as in a remote Virtual Private Network connection between peoduction and display computer(s) over the internet? I get a feeling what you're referring to is VLAN, which would make sense "to separate different equipment and control traffic". Running WATCHOUT over a VLAN should not be a problem, assuming switches are configured to route all packets properly. The VLAN "bundling" and "unbundling" (applying the VLAN "tags") can be done by most professional grade managed switches, and once the packets leave the switch that "unbundles" the tagged VLAN packets, they should work the same as on a non-VLAN-subnet. Mike
×
×
  • Create New...