--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
Follow Figure 53 on Twitter: http://twitter.com/Figure53
http://www.theblacky.net/technology.htm
Salvador Bettencourt Avila // +44 7876 453 668 // m...@salvadoravila.co.uk
Find an old CDROM drive with a working tray, land two wires on the tray
open / close button & extend to control location. Add an old PC 12vdc /
5vdc(not sure which one) PSU (found at any thrift store) to power the
drive. Press the remote button to open & close the tray. Tray open =
blocked.
For more Qlab friendly control, add a MIDI to contact closure option like
one of these,
http://highlyliquid.com/midi-decoders/
Cheaper & less complicated:
One fellow at a local theater has a rope @ FOH, pulleys along the ceiling
& a weighted & guided block in front of the projector on the ceiling. When
there is about to be
projections, he just pulls the rope up & hooks it on the wall behind him.
When done, he lowers it. It works fine.
Different DIY for different budgets.
ra byn
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
Follow Figure 53 on Twitter: http://twitter.com/Figure53
Another +1 for the ProDowser. We use this all the time. As our lens is fairly big, we had to extend the flap with blackwrap. But it still works great.
The biggest gotcha with DMX controlled shutters is cooperation with lighting. It gets accidentally programmed into cues (or not) which can make for some interesting run throughs. Submasters (and inhibitive submasters) are your friends in this regard. Thankfully, lighting and I get along great. They don't mind that I turn on the board so I can open the shutter to check the video long before they show up.
> You can trigger the internal shutters via ethernet from QLab with a little applescript and your web-browser. Works fine, except that every time you trigger the shutter, it brings your web-browser to the front before you can get back to QLab.
You don't have to use a browser to visit a url via AppleScript. You should read this thread:
http://groups.google.com/group/qlab/browse_thread/thread/d882f2a86a51fcd2
Or, you could add "tell me to activate" to the end of your script…
Rich
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
Follow Figure 53 on Twitter: http://twitter.com/Figure53
However, Apple removed the URL Access Scripting from Lion.the only way to do this now is through CURL scripting...
set userAction to item 1 of {"pow_on", "pow_off", "shutter_on", "shutter_off"} -- Use this to pick an actionset userAddress to "192.168.10.201" -- Use this to set the projector's addressset downloadedFile to quoted form of ((POSIX path of (path to temporary items)) & "Projector control.html")trydo shell script "curl --connect-timeout 5 'http://user1:panasonic@" & userAddress & "/cgi-bin/proj_ctl.cgi?key=" & userAction & "&lang=e&osd=on' -o " & downloadedFileend try
It's possibly slightly more elegant than url access scripting, but I don't fully understand all curl's options…I can't work out a way of getting the script not to wait for the response from the "do shell script", so I've tried to give it a 5s timeout.Rich
> I have done the IP controlled dowser several times, and each time I end up going back to using and appleScript cue to trigger it through safari with a delayed appleScript to bring qlab back to the front. The issue i had with the URL access scripting was that if the IP of the projector wasn’t found Qlab will hang until it either times out, or you force quit. When the show I programmed transferred from my theatre to another, and they swapped a spare projector in mid run the show appeared to crash and the engineer had no idea why. Using safari makes it a little more obvious what is going on, and when things are going wrong. I've never had any problems running safari in the background. Maybe your 5s timeout will fix that issue, i'll have to try that next time I need to program our shutters.
Just for clarity, "URL access scripting" is the method that was available pre-Lion; I posted a proposal that uses a shell script instead. It was easy to protect the URL access scripting from missing projectors and timeouts by adding "ignoring application responses" and "with timeout" clauses; it wouldn't be too hard to add error reporting too so that you knew if/why the script had failed. By contrast, I can't work out how to prevent AppleScript from waiting for a shell script to complete…
Rich