Mike Fahl

Not that it helps you with your WATCHOUT issues here, but we've used those monster NUCs with PIXILAB Blocks for driving up to six displays in various configurations. Works suprisingly well. We're using our own player software here, which isn't based on Windows, so of course driver behavior may be different too. Mike

I would consider that a bug, to be dealt with separately. The method I suggest is the only one possible today, AFAIK. Although one could of course wish for a simpler method of doing this, Mike

You can get close by moving the cues into a Composition, which is then brought into an Aux timeline as a cue, to which you apply opacity and volume. These tweens will then affect everything in the Composition. Not as convenient as what you suggest, but doable. Mike

Nope.

I believe WO is still 32 bit only, so throwing more than 16GB of RAM at it shouldn't make much difference. Just make sure you have RAM installed in an optimal way for the motherboard (some mobos benefit from parallell channels if modules installed across all RAM lanes). Mike

Sounds like you have some video content that causes WO to lock up. To figure out which one, remove video one by one, and try to "update" between each, until you found the offending item, then forward that file to Dataton. Such problems are sometimes caused by rouge codecs, but since you've just installed the machine according to the guidelines, that shouldn't be the case.

The Instagram API I used back then is no longer available, so this function wouldn't work now anyway. PIXILAB Blocks has built-in support for Instagram feeds, but even that has been quite constrained by the latest round of Instagram API restrictions. Mike

As far as I recall, this can't be done in a WATCHNET script. In case you're not tied to WATCHNET for your application, PIXILAB Blocks provides similar control capabilities for WATCHOUT (plus a whole lot more), and provides more flexible programming, allowing for the kind of functionality you're asking for here. In Blocks, scripts are called "tasks". Tasks are organized into groups. Tasks in a group can be set to be mutually exclusive, in which case starting another task will automatically terminate any previous task in that group, which sounds exactly like what you ask for. More about Blocks here (with a link to the manual at the bottom of the page): http://pixilab.se/blocks Mike

The reason you can't create them in comps is that they can''t control the comp itself (since the comp is entirely governed by its enclosing timeline). Hence, to protect you from this potentilly confusing situation, I decided to not allow control cues to be created in comps. However, as you noticed, you can "cheat" by pasting control cues into the timeline. And if you're controlling another timeline (by name), then it can actually be useful, as in this special case, where you're telling timelines to STOP. It then also make sense that the control cue would NOT be applied to its enclosing timeline (since control cues in comps weren't allowed for this very reason). So control cues in this context targeting the governing timeline are therefor simply ignored, which can be quite useful in this way. If the behavior is still there, I doubt it will be removed (even though it is undocumented). And I did make it that way for a reason ;-). Mike

I velieve what I recalled was that you could make an aux timeline (or composition) with a bunch of control cues to kill timelines. This "bunch of control cues" can include the aux timeline that's firing the bunch (allowing you to use the same comp from all those timelines). If it DOES include the aux timeline that's firing the bunch, that one will be ignored in this context. However, it was quite some years since I put that in, and I doubt anyone have ever used it. I have no idea whether it still works that way. But that was my idea at the time. However, this is NOT a "shotgun" kill-all-but-me method. You still have to add an individual control cue for each target timeline in the bunch of timelines you need to deal with. This mechanism just saved you having to create a separate set of control cues for each timeline including all EXCEPT the firing timeline, which would makt the amount of duplication far worse. Mike

I made some tests with bumping the priority of WP.EXE way back, but came to the conclusion at that time that increasting the priority of WP.EXE actually made things WORSE. There are a lot of things going on under the hood, which all need to share the same CPU. Bumping the priority of some tasks usually have a detrimental effect on others, resulting in an "unbalanced" system. Also, keep in mind that there are ususally TWO processes related to the display computer. WATCHPOINT.EXE is really just the "watchdog" process (to restart the display software if it crashes), while WP.EXE is the actual player process. At least that was the case last I looked. Mike – http://pixilab.se

Quim, I doubt that will give good performance. The whole idea with HAP is to use the GPU to do the final decoding step. I don't think WO5 exposes what's needed for a DS or QT codec to do its job efficiently. Mike – http://pixilab.se

I don't believe "brain surgery" at that granularity is possible with WATCHNET (at least it wasn't when I wrote it). It is however possible in PIXILAB Blocks, which does what WATCHNET does and a whole lot more. Read more about Blocks on Dataton's website: https://www.dataton.com/press/dataton-appoints-pixilab-as-new-solution-provider or direct from the "horses mouth" at http://pixilab.se/blocks Mike

That seems correct. There are only 30 conditions, internally mapped to bits in a 32 bit word if I recall correctly, where 1073741824 dec corresonds 0x40000000 hex, which is all low 30 bits zero. Nifty trick to turn all conditions OFF, rather than reverting to the setting in Preferences (which a zero here would do). Another, somewhat less cryptic, option would of course be to leave the Preference settings all turned OFF and then setting to 0 would indeed turn them all off. But if you want to keep both options, your "hack" seems valid. Mike – http://pixilab.se

Kinect is no longger available AFAIK. When you say "motion sensor", perhaps you're just talking "someone moving in front of a sensor" in general, rather than tracking some motion? if so, you may want to look at standard PIR sensors (infrared motion detectors). Although you can't connect such a sensor directly to WATCHOUT, you can do so through some kind of control system, such as PIXILAB Blocks. Mike