Jump to content

jfk

Moderator
  • Posts

    1,810
  • Joined

  • Last visited

Posts posted by jfk

  1. Has anyone used a touch screen as user input to trigger WATCH OUT timelines?

    The device you choose as a TouchScreen has more to do with the answer than anything else.

    Lots of customers use smartphones, tablet / pads, etc to just that.

     

    I'm looking to use Watchout as a media server for multiple touch screens. I know that a dedicate computer may be the best approach but there are other factors here that warrant putting everything on a Watchout network...

    You need to clarify that, can't tell if you want the control on the network or not,

    sounds like you do want it on the network.

     

    I suspect I will need an intermediate device to convert touch screen input to MIDI or DMX values.

     

    First use case: Simple trigger to move timeline forward. (mouse up event)

     

    second use case: Take multiple touch screen inputs from multiple touch screens to trigger timeline forward for each specific display... (mouse up event )

     

    third use case: Take multiple inputs to trigger timeline forward for specific displays... (mouse up event - mouse location)

     

    Feasible? Any thoughts?

     

    Thx,

     

    Curtis

    WATCHOUT Remote will do all of what you ask, but maybe with a mouse event or two more.

     

    If you prefer a custom interface,

    WATCHOUT Remote is written in Java and is open source,

    so it makes a great jump start for any custom development.

    The Java develepment is about the same level of difficulty as adding Java functions to a web page.

    All communication is via IP network, whether it is a PC, Mac, Android, Blackberry, etc.

    no need for an intermediate device to convert touch screen input to MIDI or DMX values.

     

    There is also an iOS version of WATCHOUT Remote,

    it runs as a web app on iOS,

    so anyone developing for iOS should have the skill set to create a custom app

    to do what you want on that platform.

     

    Or develop on any platform you choose, WATCHOUT in cluster mode has an extensive IP control set

    that can do anything you ask, and much more.

  2. Is there a reason you used a 32bit OS here?

    Wouldn't a 64bit system be better?

     

    Yes, there is a reason to use 32 bit, and no 64 bit would not be better.

    The reason is most movie decoders available today are 32 bit.

    Since key components remain 32 bit, WATCHOUT remains 32 bit as well.

    WATCHOUT is efficiently coded and is not memory constrained in any way.

    So while WATCHOUT will run in 64 bit, it is 32 bit native,

    and 64 bit offers absolutely no advantage as a result.

  3. Lawrence's comments about FirePro cards are valid for the FirePro V5900.

     

    The AMD / ATi FirePro GPU series become interesting higher up the model range.

    The v7800 (3), v7900 (4), v8750 (3), v8800 (4) or v9800 (6)

    when combined with the ATI FirePro S400 Synchronization Module option card.

    All those models provide both Eyefinity and enhanced synch support

    and as single card solutions, are compatible with WATCHOUT.

     

    Compared to any other offering, the compatible FirePro / s400 combination

    provides greatly enhanced synchronization of the outputs,

    even when it is just one multi-headed computer.

    Very pricey, but when you are feeding processors instead of displays,

    specially with 0 pixel butts and demanding content,

    the difference may make or break the results.

  4. HDCP has nothing to do with this. ...

    Of course that is correct.

    HDCP (High-bandwidth Digital Content Protection aka High-Definition Copy(right) Protection)

    is data that comes from the video source (in this case the WATCHOUT display computer's graphics card).

    WATCHOUT does not generate HDCP and therefore it should not be an issue.

     

    Now if you were feeding a digital input signal that includes HDCP to a capture card to be displayed in WATCHOUT

    (Blu-Ray players or cable TV converter boxes are common exampes of digital signal sources

    that may pass HDCP data integrated with the copyright protected video content)

    the capture card receiving the digital signal will honor the HDCP data

    and refuse to provide the signal to WATCHOUT.

    This is native to the input capture card hardware and its driver and

    WATCHOUT can not alter that behavior.

     

    -----

     

    But a different issue may cause bad behavior with extenders - EDID (Extended display identification data).

    The graphics card and the display must exchange information on the capabilities of the display.

    If the display EDID is not available to the graphics card's output connection,

    the graphics card will literally shut down that output and refuse to provide a signal.

    If the EDID data from the display is distorted or incorrect,

    the graphcis card may output, but may refuse to provide the correct resolution.

    (WATCHOUT would report that as a resolution mismatch or resolution not available).

     

    This EDID handshake behavior between the display and the graphics card output

    is native to the graphics card and its Windows driver,

    there is nothing WATCHOUT can due to override that function.

     

    That said, EDID data distortion is such a common issue,

    that third party devices to manage the EDID data independent of the display and its connection

    are available from a wide variety of vendors.

    An EDID managment device essentially isolates the data from the display,

    and instead provides the data to the graphics card directly from the EDID manager,

    even if the display is powered off!

    The EDID manager is commonly connected directly to the output of the graphics card,

    before it is extended / connected to the display.

    This provides a much more stable environment to the graphics card, making it far more reliable.

     

    We have seen EDID failures occur often with digital display connection extenders.

     

    We have even seen it occur with simple digital short copper cable display connections

    where the display's native EDID is corrupted or just plain wrong.

    Was far more common issue "back in the day",

    even display / projector manufacturers notorious for this problem in the past

    have pretty much cleaned up there act with current offerings.

     

    If I were shopping for a display extender, I would strongly consider

    combination extender / EDID managers.

    Barring a combo solution, I would always add an independent EDID manager

    when using a dedicated digital display signal extender.

  5. A time elapsed / time remaining counter for media elements and tasks.

    (useful when you want to tell the show director how many seconds left before the end of a video / task)

    ...

    BTW Something like that is available today in WATCHOUT Remote.

    While the timeline is running, WATCHOUT Remote

    automatically generates a countdown to the next timeline pause.

  6. Announcement: WATCHOUT 5.1 now available

     

    ENHANCEMENTS

    ...

    Control of Inputs (DMX, MIDI and Generic) is now managed by the display software when production computer isn’t online.

    MIDI Show Control is now handled by the display software when production computer isn’t online.

    ...

     

    Had a chance to use these two new enhancements under fire last week

    in Show Sage's WATCHOUT trade show exhibit at LDI.

    BTW LDI awarded WATCHOUT 5.1 best new product release - Projection category.

     

    During the show, we ran a single screen / single Win 7, WATCHOUT 5.1 display computer -

    no production computer (cluster mode).

    We could have just as easily played back six output channels from one computer / one WATCHOUT License,

    with the same independent control of the outputs, in groups or standlaone.

    Or controlled a group of WATCHOUT Display computers in the same manner,

    still with a single point conneciton to the controller.

     

    A simple command file (ref: WATCHOUT 5 User guide, pg 247-249, File-based Control)

    was used to automatically load the show on power up of the display computer.

     

    From there, all actions were triggered via an external controller.

     

    A Highend Systems Road Hog Full Boar lighting console was used as the controller.

     

    The Road Hog Full Boar was programmed with three cue lists.

    MIDI Show Control was used to trigger three independent auxiliary timelines using the list parameter

    and “Map to Auxiliary Timelines” setting.

    i.e. each independent cue list in the Hog Full Boar was

    locked to its own independent auxiliary timeline in WATCHOUT.

    There is no limit on auxiliary timelines, three were adequate to demonstrate the function.

     

    Connection was via a simple MIDI cable from the lighting console's MIDI jack

    to a MOTU FastLane MIDI–USB interface on the display computer.

     

    During programming / testing / rehearsal, the MIDI interface was connected to the production computer.

    MIDI Show Control was enabled and the device ID entered in the WATCHOUT Production's Preferences - Control Tab.

    This setting enables the same function on the display when it is run in cluster mode via the startup command file.

    No specific command is needed in the command file to enable MSC, enabling it in production’s preferences is all that is needed.

     

    For playback, the MIDI-USB interface was moved to the display computer and the production computer removed.

    Once production is complete and removed, operation was - turn it on, wait to the show loads,

    and control all function from the lighting console. Posted Image

    The show is locked down without a production station and

    can not be changed during performance - solid, repeatable, reliable.

    Show elements we had designated as live control during production,

    retain interactive control from the lighting console in standalone playback (cluster mode).

     

    This really worked great - from the lighting console - we jumped cues, backed up cues,

    and triggered cues randomly from the available lighting console cue lists.

    WATCHOUT was quick to respond and tracked flawlessly. Posted Image

     

    We also connected the Full Boar console's ethernet/ArtNet output to the WATCHOUT network

    to provide an ArtNet (DMX) connection.

    The DMX universe was entered into Production’s Preferences Control Tab to enable this signal.

    We used faders on the console and WATCHOUT’s DMX input function with tween formulas

    to live control aspects of graphic objects called up from two of the auxiliary timelines.

    As with MSC, the ArtNet production setting is saved to the display and

    no additional commands are needed to enable it when functioning in standalone playback (cluster mode).

    i.e. the setting is stored to the display with the show.

    The ArtNet / DMX input for live control also worked solid as a rock too. :D

     

    Great work Dataton!

    And a public ‘thank you’ for adding this enhancment.

     

    Jim Kellner

  7. I am not going to try and answer all of those, but one I could clarify is ...

     

    ... There's a note in the Users Guide that mixing different kinds of graphics cards is not recommended. Those this mean that if we select a four output card like the v7900 for the display computer we would also need one for the production machine, or could we use a less beefy card for the production machine as long as it is still in the FirePro family?

    That note refers to synchronization between display computers only.

    Production computer could be anything really, even a different vendors graphics card.

     

    The note typically means that all the cards within a group of displays should be from the same manufacturer.

    Have not tried mixing the FirePro and Radeon families among displays,

    but have mixed various generations and processors within the Radeon family and no synch issues arose.

  8. Hello,We would like to know some more in-depth information about how that presentation was made- For example how the iPad was controlled, what App it was running

    The iPad was using an app custom written for the presentation.Dataton offers a generic iOS WATCHOUT Remote app. That was used as a starting point for the custom app written specifically for the presentation.

    -How the images were transported to the iPad screen for manipulation and vice versa pictures from the iPad to the Display PC

    The custom app was written to copy the images to the Dynamic Image Server via WiFi.From there, the WATCHOUT program was written to display the image from the Dynamic Image Server .Dynamic Image Server accepts new images while the show is running and updates them to the displays as soon as the transfer is complete.

    - What system specs were the Display PCsThanks!

    Posted in this forum.WATCHOUT version 5 - Specifications on InfoComm 2011 SHOW-computers
  9. Hello all,

     

    What are the plans to develop a WATCHOUT Android app?

     

     

    Dataton has addressed that with WATCHOUT Systems Manager,

    a set of software applications and components, allowing you to manage one or several

    WATCHOUT systems. It provides capabilities to control and monitor their

    operations in a predetermined, or interactive, manner.

     

    The utilities include WATCHOUT Remote, WATCHOUT Scheduler and The WATCHOUT Management API.

    All the applications included come with source code, allowing you to use them

    as starting points should you choose to customize for your own applications.

     

    Documentation is included in the WATCHOUT Systems Manager download package.

     

    The WATCHOUT Systems Manager collection runs under Adobe Air.

     

    Adobe Air runtime is available for the Android OS.

    Adobe AIR 2.6 for Android smartphones and tablets.

    AIR 2.6 for Android adds support for Android 3.0 and the

    latest Android tablet devices – including the Motorola Xoom –

    as well as improvements to performance and GPU-based rendering,

    updated Android gesture support, and improved handling of HTML content within AIR apps.

     

    [strong]AIR 2.6 for Android can be downloaded from the Android Marketplace[/strong] and is available on devices running:

     

    Android 2.2 (FroYo)

    Android 2.3 (Gingerbread)

    Android 3.0 (Honeycomb)

     

    System requirements

    [strong]Android[/strong]

    ARMv7 processor with vector FPU, minimum 550MHz, OpenGL ES 2.0, H.264 and AAC HW decoders

    Android™ 2.2, 2.3, 3.0, 3.1, and 3.2

    256MB of RAM

     

  10. Greetings.

     

    I am a sound engineer, and I occasionally work with the leading AV contractor here. I know absolutely nothing about 'Watchout' other than that those guys are sitting in the adjacent table to me and generating the largest visuals I have worked with. There has never been any talk of sync between audio and video, they give me a stereo output for the promos and stuff they are playing, and when the event starts (musicals, in my case), they are manually triggering off cues under the guidance of an assistant director...

     

    Now a situation has come up where the client wants multichannel audio for an event, and it has to be synced with the visuals. I have already read on this forum about compatibility issues with multichannel audio, and the complication of a compatible sound card et al. Right now the contractor's Watchout guy is away for a few days... We are to meet for a discussion as soon as he comes back, but in the mean while, I want to ask this:

     

    I can generate discrete 6 channel files (L, C, R, Ls, Rs, Sub). Can I make them three stereo files, and have them played back over the three Watchout machines, in perfect sync with the visuals? ...

    I hesitate to use the word "perfect" as that leaves no wiggle room ;-)

     

    With the visuals yes, three independent stereo audio files will play with very good visual lip-synch.

     

    "Perfect" synch to each other - no. i.e.

    While WATCHOUT is frame accurate, when playing multiple audio files, it is not phase accurate

    when spread across multiple displays.

    In very critical applications, you may observe small amounts of sub-frame drift over a long time.

    When this occurs, the display will vari-speed back to synch.

    The drift is not enough to affect lip-synch, but it will disrupt audio multi-channel phase.

     

    I am very wall acquainted with the audio aspect of what I have described, I wish to use no encoding/decoding. ...

    And that is preferred, uncompressed .wav is the audio playback format of choice for WATCHOUT.

     

    Once again... will the three stereo files play in perfect sync with the video from the three computers?

    I am unaware of the version of Watchout they are using... but I suppose that if what I'm thinking is possible, it'd probably be so across the last few versions?

    yes
  11. I've got a show on the road right now with a time code/lighting issue. Using time code to call up cues on a Hog 3. We've done this before with a similar setup, but I haven't been onsite so I'm not sure what the board used then was. In this instance, we're using wo 5, and the audio playback is coming out of the production laptop. According to Jim Kellner, this should work. I've got them rustling up enough XLR cable to try getting the display pc's signal sent over to the control room. The board just isn't hearing the timecode. Lighting guy got it to work once, but thinks it was just a fluke. Output from the laptop and the display pc is Mini RTS, so using a mini RTS to XLR cable. Same as we've done in the past.

     

    Looking for insight into other ways that you've accomplished this

    Version of WATCHOUT?

    There is a malfunction in 5.0 with audio from production that [em]may[/em] explain your issue.

    It will cause production to cease audio output if the audio file's speaker icon is not visible on the stage.

    Fixed in 5.1.

     

    Since its a laptop, as a troubleshooting step,

    have you tried moving it to the connection point and using a short simple connection cable?

    Anytime I hear mini RTS to XLR cable I am always concerned about level mis-match too (-10 dB vs + 4 dB, etc.)

  12. Hello All,

     

    I see that I can jump to a specific cue in an Auxiliary Timeline, but is it also possible to run or halt said timeline?

     

    The manual seems to indicate no way to do this.

     

    Thanks,

     

    Michael

    Yes, you can.

    Not sure what manual you are looking at, but it is documented in the v5 user guide.

    It is not in the v4.0 user guide because those commands were added in 4.0.1 afte the user guide was published,

    so it appears in the Help > What's New section of the production Software for v4.

    Commands are the same for both versions.

     

    run [] Start running, optionally specifying an auxiliary timeline name.

    halt [] Stop running, optionally specifying an auxiliary timeline name.

  13. I have loaded about 6 shows into Watchout yet the remote can't listg any of them.....

     

    When logged in via terminal you can request the list of shows and receive them.

     

    I have been forced to install and uninstall wathcout a couple of times on this machine. Is it possible there is something junked up in the registry?

     

    Any suggestions greatly appreciated.

     

    Squid

    An uninstall and reinstall should clean the registry.

     

    If the OP is Sid, then I can add that it is possible to Telnet into his display clsuter

    and properly extract a list of the shows.

    (Sid had his single cpu display cluster on a public IP and I was able to do this remotely).

     

     

    Again, if this is the person I spoke with last night,

    the remote referred to is the yodesign iOS WATCHOUT remote.

    OP did you modify any of the iOS code?

     

    At the same time I was able to Telnet in and retrieve a show List,

    Sid was still unable to get iOS WATCHOUT Remote to do the same.

    BTW For anyone interested, the Cluster protocol commands to do this are:

    authenticate 2

    list Shows 1

     

    So possibly we need to look at iOS version on your iPad in the troubleshooting?

    Possibly your wireless segment is affecting some communication?

     

    Dataton AB support,

    does the iOS app use the same port (3039) as a Telnet session?

     

  14. Still hoping someone will reply to Neil's question about which network switch (brand and model number) works perfectly right out of the box with WO5, using Windows 7, 32 bit.

     

    Anyone?

    Just about any switch meets that requirement.

     

    The real question should be ...

     

    Still hoping someone will reply to Neil's question about which network switch (brand and model number) works perfectly right out of the box with Windows 7, using Windows 7, 32 bit default NIC settings, with my onboard

     

    Anyone?

    This is NOT a WATCHOUT issue, it is a Windows 7 / hardware interaction issue.

    Just because a switch works fine for someone else with their hardware and Windows configuration,

    does not guarantee the same will be true for you.

    I must be lucky, my seven year old dLink DGS-1005D Gigabit switch has worked fine with Win7 without any adjustments on my part.

  15. I'm looking to control two projectors with serial commands from WO 4.3. probably using the Keyspan (Tripplite) USB 4 port adapter.

    Can WO do this? Anything to look for in setting it up?

     

    Thanks for the words of wisdom.

    WATCHOUT only supports one serial port per display computer, hard coded to COM1.

    Provided COM1 is fully Windows compliant, it should work, ymmv.

  16. Id like to use an external show control program to power down all my display computers at the end of the day. I cannot use cluster mode because we are in a situation where the systems are being controlled via midi from a lighting console.

     

    Is there a TCP command I can use to do this?

     

    Thanks!

    No, there is no external control method to power down the production computer.

    But, there will likely be an alternative solution to your requirement in WATCHOUT 5.1 when it finally arrives,

    so if you can hang in there for a few more weeks ....

     

  17. ...

    I have a suspicion that W7's behaviour in seeing the network as unidentified and treating it as public is a factor....

    I think you are "barking up the wrong tree" there.

    That is related to Microsoft networking and sharing.

    WATCHOUT does not use Microsoft networking and sharing.

    Best to turn those things off.

    All WATCHOUT communications are TCP/IP, which is independent of Microsoft networking and sharing.

    In the NIC properties, the only setting that matters is TCP/IP v4.

    You can uncheck everything else in the NIC settings and it should work.

     

    I did see one very good suggestion in one of your links - disable any network device that is not being used.

    Windows likes to default setup Firewire, WiFi and Bluetooth ports (when present) as potential network interfaces.

    I have seen that cause issues in the past.

    I always disable all network interfaces except the Ethernet NIC we are using,

    and that NIC is only enabled for TCP/IP v4.

     

  18. ... From memory the racks all have Cisco Switches. ...

    Reminds of the system installed in Cisco Systems San Jose, CA world headquarters Executive Briefing Center.

    It was initially setup with a managed Cisco switch and it would not work properly.

    I was hoping they would bring in one of their experts to address it and we could then learn what to do,

    but there solution was to go to a local computer supply house and buy an unmanaged Linksys switch to deal with it.

    (Yes, Cisco owns Linksys too).

     

    Configuring managed switches is beyond the scope of WATCHOUT support of course.

     

    That said, we do have a dealer in Virginia who has a large site licensed system running on managed switches.

    They initially had problems, but the dealer's IT guy figured it out and it has been running for about six years now.

     

     

  19. We are experiencing what appears to be a periodic crash and restart of the display app occasionally. The biggest problem is that when the display app comes back, the mouse cursor is right in the middle of the screen, and it no longer responds to the Dynamic image server to allow it to get new images on screen dynamically. I have attached excerpts of some log files below.

     

    Has anyone experienced anything like this? Are there any workarounds or stability updates?

     

    Yes, when the update is very long, this has been known to occur.

    It has been identified and corrected in the next release.

    Note: a network issue that causes slow transfers can exacerbate this issue.

    There is also a workaround that can be used with 5.0,

    but I suspect I should not post that here, so call your WATCHOUT vendor driectly or email support

    for enlightenment on that.

     

    As for the mouse cursor issue, that is something a bit different.

    Once that occurs, watchpoint is not going to be very stable.

    Quit and restart WATCHOUT Display to eliminate that.

  20. continued ....

     

    ….

    When this occurs, a potential fix is to:

    go to the Advanced tab for the network adapter,

    change IPv4 Checksum Offload to Disabled

     

    But I see other settings being offered as a fix,

    so it would appear there are multiple issues

    that can affect the interaction of Win 7 and the network switch.

     

    I found that [strong]the thing which fixed it for me was "flow control"[/strong]

    ===========

    reference: Windows 7 Forums -> Windows 7 - Extremely slow file transfers and network access...

     

    Start Run --> ncpa.cpl

    right click on adapter ... select properties

    click on "configure"

    click on "advanced"

    highlight the property "Flow Control" and change it to "disabled".

     

    This stopped the rate limiting and let my adapter run at full speed.

     

    and there seems to be some issues unique to nVidia GPUs

    Windows 7 Forums -> Windows 7 - More detailed answer for Nvidia boards and W7 x64

    Thanks!

     

    This worked for me but it wasn't the whole solution.

     

    I had an Nvidia board and needed the latest driver. The built in Windows 7 driver was not good enough.

    Next, I had to disable all the silly Microsoft "improvements:

    C:\Windows\System32>netsh int tcp show global

    Querying active state...

     

    TCP Global Parameters

    ----------------------------------------------

    Receive-Side Scaling State : disabled

    Chimney Offload State : disabled

    NetDMA State : disabled

    Direct Cache Acess (DCA) : disabled

    Receive Window Auto-Tuning Level : disabled

    Add-On Congestion Control Provider : none

    ECN Capability : disabled

    RFC 1323 Timestamps : disabled

    ** The above autotuninglevel setting is the result of Windows Scaling heuristics

    overriding any local/policy configuration on at least one profile.

     

    Then, once that was done, I had to make sure that Flow Control was Receive Enabled.

     

    Then once that was done, I could change your setting regarding IPv4 Checksum Offloading Enabled to DISABLED.

     

    Oh, and I'm not sure it matters but I've got IPv6 disabled across the board.

     

    What a PITA! But thanks for the last piece to the puzzle!

    ... and this can go on and on, you really need to research your specific system,

    or find a hardware vendor who will certify your system with your switch, etc.

  21. seems there is a maximum post length and my response is to long,

    so it is broken up among the next few posts here …

     

    PPS. IS there a way to quantify what the uplaod speed is during an update? As we are having very slow updates it would be useful to know what speed the network was working at so that we could apportion the blame. i.e is it Watchout? or the network transfer speed?
    Its not WATCHOUT, its the Windows settings and the network infrastructure.

    And it sure looks like there is more than one issue at stake.

    Point is, if your network is running slow, there is no single "do this and you are fixed" answer.

    You need to identify what is amiss in your system.

    -------

     

    Periodically we hear reports of very slow online / update times

    with WATCHOUT under Windows 7.

    XP machines in the same cluster do not exhibit speed issues.

     

    Research has shown this is not unique to WATCHOUT,

    the general Windows population has many similar reports.

     

    Apparently there are some subtle changes in Win7

    in the way Windows IP networking is implemented.

    The change creates slowdowns with some network switches.

     

    It seems Win 7 offloads some network duties to the network switch.

    I see mention of Win7 certified switches.

    But even switches that were not Win7 certified

    could be accommodated with changes to adaptor settings in the

    Advanced tab for the network adapter.

     

    reference: Windows 7 Forums -> Windows 7 - Extremely slow file transfers and network access...

     

     

    I posted this issue to Microsoft (after some further research) and they solved it for me! They asked if my router was on the Windows 7 compatibility list, and that seemed really strange since 802.3 (Ethernet) has been around a long time and why would that suddenly change with the O/S? But I unplugged my PC from the Trendnet Gb router and plugged it into the old Linksys 100Mb and BAM - full network speed! On the Gb router, I couldn't get above 2% in the monitor on a file transfer - on this "compatible" one, I get 100% and file transfers are screaming.

     

    Then there is Remote Differential Compression

    reference: Slow Network File Copy issues in Windows 7 caused by Remote Differential Compression

     

    You may experience poor file copy performance over the network in Windows 7 PCs. This could be caused by the Wndows “Remote Differential Compression” engine. Remote Differential Compression is a Windows feature introduced in Windows Server 2003 and is available on all later versions of Windows. This Windows feature is enabled by default in Windows 7.

     

    Remote Differential Compression (RDC) allows data to be synchronized with a remote source using compression techniques to minimize the amount of data sent across the network. RDC is different from patching-oriented differencing mechanisms, such as Binary Delta Compression (BDC), that are designed to operate only on known versions of a single file. BDC requires the server to have copies of all versions of the file, and differences between each pair of versions are precomputed so that they can be distributed efficiently from a server to multiple clients.

    There seems to be a problem with this Windows 7 and disabling this feature resolves the problem with slow file copy performance.

    To disable Remote Differential Compression,

    1. Click Start – Control Panel – Programs – Trun Windows features on or off

    2. Uncheck “Remote Differential Compression” and click OK.

    3. Restart the computer and you should see an improved performance with copying files.

    If there is a similar problem in your Windows Vista PC, you may try this and check if this helps.

    There are other references to the Remote Differential Compression (RDC) fix with comments like:
  22. Hi Jim,

     

    Could you recommended on some simple TCP/iP "Input Device" (sensors) for easily controlling the AUX TLs?

    The short answer is - no.

     

    TCP/IP Generic input is not the way to approach that, you have to connect and obtain permission,

    most simple sensors are not that smart

    and would require an intermediate device (Medialon, Mediamation, Crestron, AMX etc.)

    to interpret the input to the IP format and manage the IP connection.

     

    I would think sensors that transmit MIDI notes or MIDI continuous controllers would be the easiest way,

    that should be straight plug and play.

     

    Once you know what you want the "sensor" to do,

    post on the The Show Control Mailing List,

    you should find some good input there.

     

     

  23. Version 5:Who can tell me how to use generic input?

    Pretty generic question.

    How to set one up in the WATCHOUT input window?

    How to use one that is already setup?

    The format for the command sent from a controller?

     

    Generic input is only available when commanding a Production Computer via Production Computer Protocol

    (ref: WATCHOUT 5 User Guide - Appendix D - pg 241)

    No Display Cluster Protocol equivalent.

     

    The generic input accepts an unsigned floating point value to WATCHOUT Production via IP command from a controller supplied by others.

    So it only accepts a value.

     

    Use a generic Input when you want to control its value using the network

    control protocol of the WATCHOUT production computer. The default range of

    a generic input is 0 through 1, although you may set the upper limit to any

    positive value using the Limit field in the Generic Input’s dialog box.

    To control a generic input, use the setInput command (see “setInput” on page

    245).

     

    setInput Sets the value of a named input (see “Inputs” on page 187):

    setInput "uno" 0.5

     

    The value is generally in the range 0 through 1, but may be extended to cover

    a wider range using the Limit setting of the Generic Input (see “Generic Input”

    on page 187).

    NOTE: While you would typically use this command to set the value of a

    Generic Input, you may use it to set the value for any input. If data is also

    provided by a MIDI or DMX-512 source, the latest data will take precedence.

    I like the ability to override a DMX or MIDI controller input if need be. :thumbsup:

     

    From there you use the name you assigned when you made the input

    as a value in the expression string of live tweens or in the task window condition field.

  24. Hi Jim,

     

    i think that i don't really understand the process of all that.

     

    I plug the SMPTE code to the production machine (via line In) then the timeline of this machine sincs to the SMPTE code and simultaneously as usual, the Watchout sincs the Displays.

    That is one way to do it, yes.

    But if you do it that way, then no, you can not use command files with that method.

    You enable timecode chase in the production computer preferences, save the file,

    and it will remember that preference when the file is reopened.

    You can automate show load on Production from a third party control system via IP, but not a command file.

     

    I think we are mixing our metaphors here.

     

    There are two chapters in the User Guide related to control -

    Appendix D Production Computer Protocol and

    Appendix E Display Cluster Protocol.

    [strong]The two are mutually exclusive.[/strong]

    Display Cluster Protocol only works when the

    WATCHOUT Production system if offline, better yet,

    with no WATCHOUT Production system at all.

     

    The only time the script you posted would work

    is when there is no production computer online,

    and the WATCHOUT Display group defined in

    the orignal show file's stage are acting as a single playback entity,

    i.e. Display Cluster Protocol

    So the load command needs to store inside the path of the exe file of the Watchout production.

     

    This is how I know it works.

    You have got a command script file working on WATCHOUT Production (watchmaker.exe)?

    I did not catch that new feature, can not find it in Appendix D Production Computer Protocol.

    No timecodeMode command in Production Computer Protocol either,

    timecodeMode is unique to Display Cluster Protocol.

     

    Maybe I misunderstand.

    If you [em]meant[/em] this is how you [strong]think[/strong] it works - you are wrong.

    If you meant you really do know how that works with Production, then I am wrong - please "school me".

    In WATCHOUT 5, for the first time since version 1, new commands were added to Production Computer Protocol,

    so maybe there is more new there than I am aware of :iono:

     

    But according to your reply I should put the script in the Display Machine? Not in the Production one. So I have to plug the SMPTE code to all the display machines?

    Thanks in advance

    No, if you re using a script in a file that is executed on the start of WATCHOUT Display,

    you do not feed the SMPTE to Production, since by definition Production is not online,

    you feed it to the one member of the group that contains the command script.

     

    You put the script file and modify the shortcut to reference the script file on just one display machine.

    You feed SMPTE timecode to the audio input of that same machine (with the command script),

    and it syncs all the others over the network.

    Pick any display machine, does not matter which one, but choose just one.

    WATCHOUT Display with the script file learns who all the others are from the definition of your stage

    in your original .watch show made on production.

    Production transfers and stores that info to the displays when you go online or update.

     

    The display cluster load command executed on one display from a script file

    loads the show on all displays in the cluster

    by using the stored list of cluster members for that show

    placed on every display during the show transfer process.

    So even though the info needed is stored on every display,

    you only need to execute it on one display,

    it will manage all the others.

     

     

     

     

×
×
  • Create New...