zackboyd

I've not been under the impression prores was EVER recommended for watchout. Jonas posted a Media format guide ages ago that I thought was a sticky, but cant find it. I always thought the order was: MPEG2, H264, quicktime animation for transparency. Watching the forum, it seems people are having great success with HAP, though I haven't ventured into that world yet.

I've never had much luck with audio looping - especially free running. When I've installed even clips that loop endlessly (think museum displays) I've found it more reliable to tie audio to video (even though it's not recommended), and then actually have the aux timeline loop rather than free run/loop. I've tried to stay away from doing anything like a seamless loop (or anything audio intensive) with watchout because I've never had great success. I'd love to know if anyone has any good tips/tricks.

Try using masks rather than blend.

I missed this in the release notes! Hope it's still a thing... sounds like fun

I'm not sure what the expected behavior should be, but I would expect what you're seeing to happen. Typically I've done this with stills of the last frame on another layer.

He's right though, this is a limitation... It could be a feature add if the 'mask' function was added to virtual displays.... The tracking doesn't fix when the object is larger than the projector's raster. When there's a blend on a surface, if the object moves the physics of the rasters change and need to be accounted for.

Great info! Thank you

Check the stacking order of the actual live input media items in the task. Under advanced they have their own stacking properties. Z

If you need to leave the SLESA in because it's doing other things(playing back the rest of the show, etc). You could get any IP relay box and send that commands via watchout to trigger contact closure on the SLESA. If ALL you need to do is control those moving heads, I would take the SLESA out and output DMX via an Artnet gateway.

I've actually used(against recommendations) mpeg2 Transport stream for years(.m2t). I've found it performs better when layering lots of clips/playing back multiple clips simultaneously. I have no empirical data for this, just what I've experienced. I find I have to pre-load cues/handle clips more 'carefully' when dealing with program stream.

I'm honestly blown away by that. Is there something strange with the LED product? Seems like they're making it harder on themselves to run the LED data.... Assuming this is typical LED, the thing you have to remember is the LED sending unit looks for rectangle chunks of video. So with that in mind(if I was providing your LED), I would want your '5x2' blocks just like you have them, laid into the far top-left corner. But with the '6x2', I would want to split them in half and have 2 sections of '3x2' or 1 '3x4', which would be the smallest 'rectangle of video' that the LED could occupy. Same theory for the '7x2' - one chunk of '3x2; and one chunk of '4x2'. Hope that helps. It sounds like the LED team your working with is a little difficult - I'm not sure what they're using hippo for. Drink caffeine. Stay calm. Best of luck. Z

Hi Neil - The whole idea of virtual displays is to ambiguize this process so it can be accomplished however is best for the LED hardware/transport. I would suggest continuing to approach this as 9 virtual displays, then allow the LED provider to determine what is the best physical transport to send that content to the wall. You can carry on programming with the virtual displays, and can adjust if the LED provider needs to change something. Hope that helps.

Hi all - Posting this in hopes that it helps someone later. I had major playback issues on my most recent build. Symptoms appeared once I had more than two displays connected. Playback was stuttered and broken between displays. Intel Xeon, Radeon Pro WX7100. Problem occurred on WO 6.1,6.2, and 6.3. Driver that was causing this was 18.Q3 - I rolled back to 18.5.1(last known working driver) and all is well. Hope someone doesnt get tripped up like I did. Z

I'm using IP address on 6.2.2 just fine. I have a Radeon pro rather than NVidea and I also do not install quicktime. I've had boot sequencing issues with machines running quicktime since v5. Try wiping that and doing a clean install of watchout without quicktime. I'd be curious if that fixes it.

Is the official recommendation a different layer or an entirely different timeline? I didn't know this. I just thought you had to separate it out.

That seems awfully short-sighted... AV integration on largescale network infrastructures is becoming more and more commonplace everyday. You're going to begin forcing people's hands.

I'm not a big fan of the BMD capture cards. I will say I'm using Datapath cards on the newest version just fine. The remote access piece is a flavor of VNC built into watchout. The downside of that is if watchout itself isn't running, no remote support. I've been playing with varying levels of other workarounds for this - adding remote relays to the power/reset buttons on the motherboard, remote KVM systems, but most prominently I've been running Teamviewer. Teamviewer DEFINITELY is NOT recommended, but it's sort of my best worst option right now. I'm having good results on machines that are on very segmented networks. Again, its definitely not recommended though.

Have you remoted into the display computer and selected the BMD driver in the 'Video In' menu for Input 1? While in stage - ctrl-shift-a with an output selected. When complete I usually do a file-relaunch, especially after changing settings.

This just plays into media/cue organization. I don't often find a reason to have a piece of media in the same show twice...... Timecoded shows would be the exception but then we're only doing this in the main timeline for that instance.

You're making this too hard on yourself. The content you create should be on the flattened uv map of the model, which will then be mapped to the model in watchout.

This sounds like something in the media, rather than the hardware. Can you share your encoding specs?

Hi Wilson - Wake-On-Lan is not a Watchout thing, it's a standard. It must be enabled on the bios of your machine. The WOL packet or 'Magic Packet' is 6 bytes of 255 followed by 16 instances of the machine's MAC address, UDP broadcast to port 9.

I prefer AMX, but this can be done many many ways with many different platforms. Watchnet can also probably get you where you need as well.

Did you try adding a 0.1 jump-to-run delay?

Just checking - do you have anything in the auto-start script?