EOS - Wysiwyg's Auto Focus ?

Hi ! I found wysiwyg's autofocus an amazing feature and I wish I could use it on EOS. Do we have any chance to see such feature in the near future? 

Thank you in advance for you kind reply. 

Emiliano 

Parents
  • This would be really useful (as well as auto patch)!
  • I have been in contact with Cast light, the software developers for Wysiwyg. They say that the autofocus implementation requires minimal effort for the console manufacturers, but that they cannot do it from their side. It would be really great to investigate this and implement autofocus in the near future. It could improve my workflow for preparing shows tremendously and would be deeply appreciated.
  • Speaking with absolutely no inside knowledge here... my guess is that with Wyg's relatively small user base, it's unlikely that ETC will spend any time at all implementing the proprietary autofocus system.  It might be more fruitful for you to suggest to Cast Software that they implement an OSC integration for Eos consoles.  It would require minimal effort on their side to send OSC commands for both Autofocus and Autopatch.

  • It looks like there is a MIDI-based autofocus option for WYSIWYG? If so, I wonder if one could intercept this MIDI packet and convert it to OSC using puredata/Luminosis/other?
  • It certainly seems doable in theory... I'd love to know what info Wyg is sending over MIDI.

  • I think you are right in saying that Wysiwyg might not be very widely used, but here in the Netherlands you see it more and more and on high profile shows like the European Song Contest or the Bafta's it is the pre-viz software of choice. ETC has to do very little effort from their side to be in the game. Why let GrandMA and Hog have the advantage?

  • Can someone tell me what is the status of the autofocus connection to wysiwyg? Or is there another visualisation software package that ETC is implementing this feature for? In that case I might consider to switch as it is very useful. I've used the function on the good old Strand and it is strange that a more modern desk cannot support this feature.

    One way I really liked to use it for is this:

    On a performance with 32 movers, you obviously make several focus palettes or presets for at least, say 15 focus positions. With more then 30 movers it might not worth the time to record every focus position for each fixture. But then you (as lighting designer) decide you want to try the same position from a different angle (so you need to add the fixture to the palette). With autofocus, you select the fixture in wysiwyg, use autofocus and the fixture moves to the desired position right away.
    Or, you did make this particular focus palette for all your movers, but then the director decides to move the position.
    Now you'd have to change this position fixture by fixture. With autofocus you can have wysiwyg open on a connected computer, move the focus position in your plot to the desired position and update your palette from the desk. All you have to do afterwards (if your plot isn't accurate to the inch/centimeter) is touch-up the position palette after rehearsal. But at least you can go on with rehearsals without loosing too much time.
    Or, you are on a touring show and the rig is hung with the same spacing on the pipe, but much higher or lower then in the previous venue. You adapt the pipe height in wysiwyg, select the lights in your plot (using fixture groups) so they are automatically selected in the desk, choose a focus position in wyg, and update your position in EOS.

    Be aware that I used these exact functions already 8 years ago on much older hardware, and I am a bit frustrated that I cannot do this on a state-of-the-art lighting desk today. According to the manufacturers of wysiwyg at cast-light it is a very simple driver that needs to be developed by the manufacturer of the lighting desk, so I would be super thankful if anyone at ETC contacted the friendly people at CAST... Please?

    Thanks in advance!

    Floriaan
  • I also am a WYSIWYG user and think this would be helpful. Maybe since ETC is acquiring High End they could adapt the driver the Hog console is using.

    Just a thought. :)
  • This was the answer I received from the software developers at Cast light:

    "We, too, would like nothing more than to see ETC, and so many other manufacturers who are Registered WYSIWYG Developers (RWDs), develop console connectivity drivers which support AutoFocus--and AutoPatch too! This option is available to all RWDs (and ETC is an RWD). However, [...] CAST cannot tell a console manufacturer what to do, what to develop... so if ETC chooses not to write a proprietary connectivity driver, but instead to connect to WYSIWYG via the generic EDMX or Art-Net or sACN protocols, that is their choice. And it is simply impossible to make AutoFocus (and AutoPatch) work via a generic protocol, because these protocols require a driver which is able to pass information/data to the console--meaning that that driver has to be written for that, specific console.

    I am glad to see that there is a discussion about this over on ETC's Forum as well.. perhaps ETC will take notice and actually go ahead with driver development. As to the last comment in the thread you mentioned, good idea on the poster's part, but unfortunately things don't work that way: unfortunately, the Hog4 driver cannot be "adapted" to work with the EOS (because that driver was written for the Hog4 and a driver for the EOS would have to be written for it) but, of course, the principles are the same. If ETC was willing to go ahead with this though, they can probably use the knowledge that High End gathered back in 2015 when they revamped their driver. (The very unfortunate thing about that revamp was that High End was unwilling to expand AutoFocus functionality beyond what Flying Pig Systems originally implemented back in 2003.. this is why WYSIWYG users are only able to use AutoFocus for Intensity, Pan & Tilt, Iris and Colour Mixing when connected to the Hog4, but can use it for Colour Wheels, Gobo Wheels, Prism Wheels and Zoom (in addition to the previous parameters of course) when connected to consoles such as grandma/2, Vector and MagicQ, among others. But, as you can probably tell by now, there isn't much we at CAST can do about this, because, again, the manufacturer/RWD gets to decide how to implement the connectivity. I have personally written to them on a number of occasions, asking if they wouldn't be willing to help our mutual users out, but nothing was ever done.. and for the record, this is not something super-complex, that requires weeks or months of development: many of the RWDs who have implemented this functionality usually had a fully-working driver, with either just AutoFocus or with both AutoFocus and AutoPatch within a week of receiving our SDK... I know because I'm the one who sends out the SDK and I'm also the one who certifies the driver before its release.)"

    I hope this helps!
Reply
  • This was the answer I received from the software developers at Cast light:

    "We, too, would like nothing more than to see ETC, and so many other manufacturers who are Registered WYSIWYG Developers (RWDs), develop console connectivity drivers which support AutoFocus--and AutoPatch too! This option is available to all RWDs (and ETC is an RWD). However, [...] CAST cannot tell a console manufacturer what to do, what to develop... so if ETC chooses not to write a proprietary connectivity driver, but instead to connect to WYSIWYG via the generic EDMX or Art-Net or sACN protocols, that is their choice. And it is simply impossible to make AutoFocus (and AutoPatch) work via a generic protocol, because these protocols require a driver which is able to pass information/data to the console--meaning that that driver has to be written for that, specific console.

    I am glad to see that there is a discussion about this over on ETC's Forum as well.. perhaps ETC will take notice and actually go ahead with driver development. As to the last comment in the thread you mentioned, good idea on the poster's part, but unfortunately things don't work that way: unfortunately, the Hog4 driver cannot be "adapted" to work with the EOS (because that driver was written for the Hog4 and a driver for the EOS would have to be written for it) but, of course, the principles are the same. If ETC was willing to go ahead with this though, they can probably use the knowledge that High End gathered back in 2015 when they revamped their driver. (The very unfortunate thing about that revamp was that High End was unwilling to expand AutoFocus functionality beyond what Flying Pig Systems originally implemented back in 2003.. this is why WYSIWYG users are only able to use AutoFocus for Intensity, Pan & Tilt, Iris and Colour Mixing when connected to the Hog4, but can use it for Colour Wheels, Gobo Wheels, Prism Wheels and Zoom (in addition to the previous parameters of course) when connected to consoles such as grandma/2, Vector and MagicQ, among others. But, as you can probably tell by now, there isn't much we at CAST can do about this, because, again, the manufacturer/RWD gets to decide how to implement the connectivity. I have personally written to them on a number of occasions, asking if they wouldn't be willing to help our mutual users out, but nothing was ever done.. and for the record, this is not something super-complex, that requires weeks or months of development: many of the RWDs who have implemented this functionality usually had a fully-working driver, with either just AutoFocus or with both AutoFocus and AutoPatch within a week of receiving our SDK... I know because I'm the one who sends out the SDK and I'm also the one who certifies the driver before its release.)"

    I hope this helps!
Children
  • I would have thought it would be simpler for Cast to implement one of the various open standards that achieves this and more? OSC comes to mind - that works great on ML Assistant for the same sort of purpose.

    github.com/.../EosSyncLib might be a good answer for them - that way Wyg could stay "connected" and both sides can update the show as needed. Wyg could even have access to the command line and other features that just couldn't be hoped for with AutoFocus. As a side benefit, an OSC solution would also allow Wyg to work with other consoles without proprietary drivers from Cast (no manufacturer likes to dump unknown code into their software).
  • A thousand times, yes. ETC already offers an open API via OSC (which is an industry standard). The current OSC implementation has all the tools Cast needs to implement AutoFocus on Eos, and since the OSC API is constantly improving, the opportunities for deeper integration are endless.

    I would much prefer ETC spend their energy improving OSC (which is available to all software developers for free), than spending their time on a proprietary integration for WYG that only serves their customers who also own a WYG visualization license.

Related