Applescript causing video to freeze during execution.

[micpool]

On a show I have just designed i have been using applescript to control the shutter in a panasonic projector by sending a command over the LAN to the web server running on the computer.

When the applescript is executing the video outputs freeze for about 2 seconds. Is there a way round this or do some scripts  just stop Qlab from processing while they run.

Mic

[Sam Kusnetz]

Unfortunately, AppleScript insists on being on the main thread of an application.

If your Script cue calls an external script, however, that script does its own thing. So you can get around it that way.

Not as elegant, but workable.

Cheerio

Sam

—

Sam Kusnetz
QLab Field Operative
s...@figure53.com

[micpool]

Would it be possible for Qlab to do this automatically. i.e compile any scripts entered into the script field as external scripts and reference them?. Would there be a downside to it doing this?

Mic

[Sam Kusnetz]

On April 16, 2014 at 4:21:43 PM, micpool (m...@micpool.com) wrote:

Would it be possible for Qlab to do this automatically. i.e compile any scripts entered into the script field as external scripts and reference them?. Would there be a downside to it doing this?

Are you asking for a feature addition, or are you asking if you can just copy the script out of a Script cue and paste into AppleScript Editor?

If the former, then I can put it on the list but I’ll be honest: it’s a long list, and this isn’t very pressing as compares to other items since this one has a known solution. But no harm in considering it, right?

If the latter, then you probably can copy/paste, but you need to be careful to review statements like “tell application X” and make sure they make sense from the context of a script running outside QLab.

[micpool]

I was asking for this as an additional feature as it would make the script cue included in Qlab function better, without the user having to worry about all the caveats you include in your post.

As the shutter control is a script I use frequently (and might be useful to others), and causes a total freeze on video output in its current form,  would you mind using this in an example of how this would be made into an external script, and how the external script would then be called from the script cue in Qlab.

Thanks

The script I am using basically just sends a string to the projector which includes the URL that would be sent if you clicked the shutter button on the web page remote in safari.

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

set theServer to "192.168.0.21"

set theUsername to "admin1"

set thePassword to "panasonic"

set theCommand to "/cgi-bin/proj_ctl.cgi?key=shutter_off&lang=e&osd=on" 

set theProtocol to "http" -- vs https

set theUserPass to theUsername & ":" & thePassword -- your Indigo remote access username/password

set theURL to theProtocol & "://" & theUserPass & "@" & theServer & theCommand

set theFinalURL to "\"" & theURL & "\""

with timeout of 1 second

do shell script "/usr/bin/curl" & " " & "--connect-timeout" & " " & "1" & " " & theFinalURL

end timeout

------

[Sam Kusnetz]

Mic

Gotcha. I’ll put the request on the list.

Also, re. your script, I believe it will work as is, but I’m sure Rich Walsh will correct me if I’m wrong.

[Rich Walsh]

Not having a Panasonic projector to hand I can't test anything, but it struck me as odd that you have an AppleScript timeout and a timeout within the curl parameters. I tried "ignoring application responses" instead of your timeout, but still had to wait 1s for the script to progress. Then I asked Google and for reasons I don't fully understand, appending "&> /dev/null &" to the end of your shell script seems to allow AppleScript to pass the shell script off without hanging around. I know that "> /dev/null" dumps the output of a shell command into a null file (eg: run "yes > /dev/null" in 8 Terminal windows to heat your MBP up) – but I've not yet come across the shell ampersand…

So, you can replace the last 3 lines with this, and AppleScript shouldn't hijack any threads:

do shell script "/usr/bin/curl" & " " & "--connect-timeout" & " " & "1" & " " & theFinalURL & "& > /dev/null &"

I'd be interested to know if that works. I think you should probably be dumping the output of curl to null anyway as otherwise you're going to keep downloading the website source code…

I'd also be interested to know why the AppleScript runner has to be implemented on a program's main thread. I've been reading recently about how things like Reaper (and now Soundminer) host plug-ins on separate threads so that plug-in crashes don't take down the whole app. Can the same principal apply here?

If you want to go down the app route, save your script as an app and then "tell application "Mic's App" to run" in QLab. You may need to wrap that up in a "ignoring application responses" block to avoid an invalid connection, which I think is caused by the app quitting before the script feels that it's satisfied that the app has run. Trial and error rather than a proper understanding of what's going on here, I'm afraid!

Rich

--
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53

---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[micpool]

I've now left the show up and running so don't have a panasonic to hand either.

The script is from Stage Sound Services so I'll forward the dev/null thing to Huw to test.

For me this script is well worth perfecting as it means you don't have to mess around with serial servers and have a third cat 5 running to the projector.

Thanks

Mic

[Douglas Heriot]

but I've not yet come across the shell ampersand…

Adding ampersands to the very end of a line in shell tells the shell to run the command in the background, and not wait for it to complete.

The ampersand in the &> /dev/null bit is a shortcut for 2>&1 > /dev/null which means to redirect both errors and the standard output to /dev/null

A different solution to this – would it make sense to have an app separate to QLab that is solely responsible for handling external devices through scripts, TCP/UDP, etc. – and QLab could trigger this app through OSC? If nobody can think of an app like this that already exists, I’m tempted to make one.

Douglas

http://douglasheriot.com/

[Sam Kusnetz]

On April 17, 2014 at 11:55:18 AM, Douglas Heriot (dougla...@gmail.com) wrote:

A different solution to this – would it make sense to have an app separate to QLab that is solely responsible for handling external devices through scripts, TCP/UDP, etc. – and QLab could trigger this app through OSC? If nobody can think of an app like this that already exists, I’m tempted to make one.

I’ve never seen such an app, and I agree that it would be extremely useful!

[micpool]

On Thursday, April 17, 2014 4:53:42 PM UTC+1, Douglas Heriot wrote:

Adding ampersands to the very end of a line in shell tells the shell to run the command in the background, and not wait for it to complete.

The ampersand in the &> /dev/null bit is a shortcut for 2>&1 > /dev/null which means to redirect both errors and the standard output to /dev/null

Couldn't get this to work for some reason.

A different solution to this – would it make sense to have an app separate to QLab that is solely responsible for handling external devices through scripts, TCP/UDP, etc. – and QLab could trigger this app through OSC? If nobody can think of an app like this that already exists, I’m tempted to make one.

As an interim app we can use Qlab2 running alongside Qlab 3 fired with MIDI on an IAC bus (Thanks to Huw at SSS for suggesting this).  Using a second Qlab 3 workspace doesn't work as the script takes over both workspaces.

The applescript saved as an  app method suggested by Rich almost worked but there was still a small glitch while the tell application applescript ran, (just 1 or 2 frames). And for completeness Rich was correct in assuming that it would need to run in a ignoring application responses block.

So an app that Qlab communicates with through MIDI or OSC would seem to be the way to go if there is no way of incorporating an applescript execution method directly in Qlab which doesn't take over.

As Qlab 2 works perfectly in this role is there any merit in the suggestion that an app that was essentially a completely  stripped down version of Qlab with just enough functionality to accept MIDI and execute scripts might become  the app which Douglas suggests? 

And there is still sometimes  a frustration that  Qlab can't send serial commands. Perhaps that could be incorporated in any app. 

So, an app that receives MIDI and OSC and triggers applescripts or sends serial data would be ideal.

Mic

 

[Andy Lang]

On Wednesday, April 23, 2014, micpool <m...@micpool.com> wrote:

So, an app that receives MIDI and OSC and triggers applescripts or sends serial data would be ideal.

Try MidiPipe:

http://www.subtlesoft.square7.net/MidiPipe.html

-Andy

[micpool]

Thanks Andy

Thats a good workaround and solves my video glitch problem.

I've had that program on my computer since 2007 and had completely forgotten it would send applescript. No OSC or serial support though.

Mic

[Greg Rutledge]

I've had good results passing URLs to curl via the "do shell script" AppleScript command in a Qlab script cue. So far it's worked with every projector I've used that has a web interface to control power on/off, source select, show/no show, shutter open/close, etc. With a little digging through the source code (html and a little javascript), you can reconstruct the URL that's sent to the projector when any given button / link is clicked from the web browser.

Here are the commands from my shutter cues for the Panasonic PT-EX16KU:

Shutter Open:  do shell script "curl http://ql...@172.16.4.206/act.htm?SET=shut_off > /dev/null 2> /dev/null"

Shutter Close:  do shell script "curl http://ql...@172.16.4.206/act.htm?SET=shut_on > /dev/null 2> /dev/null"

Note that the "qlab" before the IP address is a non-admin user I created on the projector with no password. I believe the projector can be configured to accept commands without a user name as well but I think that might be dangerous. A non-admin user can only mess up so much through errant scripting. :-)

Command syntax for this projector is: do shell script "curl http://USER@PROJECTOR-IP/COMMAND > /dev/null 2> /dev/null"  If I recall correctly, the full URL appears in the browser when you execute a command from the web control page so it's just a simple copy / paste job, no digging through code.

I've also used the same script with a handful of NEC MT1075's. It actually passes a hex encoded version of the serial control strings through the URL but unfortunately it doesn't show up in the address bar of the browser so some source code digging and javascript parsing was necessary.

Power On:  do shell script "curl http://10.1.1.213/cgi-bin/consoleON.cgi?D=%05%02%00%00%00%00 > /dev/null 2> /dev/null"

Power Off:  do shell script "curl http://10.1.1.213/cgi-bin/consoleR15.cgi?D=%05%02%01%00%00%00 > /dev/null 2> /dev/null"

No shutter on this baby, but at least we can mute (no-show) the image, built-in speaker, and OSD for safety:

Mute All:  do shell script "curl http://10.1.1.213/cgi-bin/consoleM.cgi?D=ON > /dev/null 2> /dev/null"

Unmute All:  do shell script "curl http://10.1.1.213/cgi-bin/consoleM.cgi?D=OFF > /dev/null 2> /dev/null"

Hope this helps.

___________________________________________________________________

[micpool]

I think this is broadly the same as we have been doing. In the thread we have discussed a do shell script command similar to yours.

The main differences are you start with curl where we were using usr/bin/curl which I think would be functionally identical. Your line ending is slightly different to ours we had > /dev/null &"  while you use > /dev/null 2> /dev/null" I don't know applescript well enough to tell if these are functionally identical or not.

We included a timeout in the command because otherwise Qlab just totally hangs waiting for a response if the projector isn't present which makes offline editing difficult and is potentially dangerous in a show situation. I haven't found a way to get the timeout to happen in the background so currently if the projector is not present the video playback in Qlab freezes for the timeout duration. I don't fully understand why this is if the processing of the applescript is being run in the background by virtue of the > /dev/null 2> /dev/null" but I am happy to admit I'm pretty much stabbing around in the dark at this level of scripting.

The problem I have been having is that whatever script I have tried in Qlab, even if it is just calling an external applescript app results in a momentary video freeze. With a single projector this doesn't matter because generally the shutter will be opened or closed at the beginning or end of the video, but with multiple projectors closing the shutter on a projector while others are still displaying video results in a visible glitch.

By triggering the applescript in another application through a MIDI command (or OSC) we avoid the glitch.

Are you saying that you haven't noticed any dropped frames in the video when executing your script?

Mic

[Rich Walsh]

Everything inside "do shell script" isn't AppleScript: it's Unix – or whatever the collective term for what the Terminal speaks is!

You're essentially comparing

/usr/bin/curl --connect-timeout 1 {someurl} & > /dev/null &

with

curl {someurl} > /dev/null 2> /dev/null

/usr/bin/curl IS curl, just with the full path to the executable spelt out.

As Douglas Heriot explained, "& > /dev/null" is the same as "2>&1 > /dev/null", which is the same as "> /dev/null 2> /dev/null", which means to direct both the standard output (1) and errors (2) to the null file.

The only difference is the final & which should mean that Mic's version allows AppleScript to move on without waiting for the result while Greg's doesn't – although Mic's version also includes the 1s timeout.

Corrections gratefully received. I have the 700-page bash cookbook still sat safely waiting to be read from 5 years ago!

Rich

[Drew Schmidt]

Hey All

I've seen this keep popping up, so wrote some quick (and messy) python code to solve this issue (attached). It 

• Creates an OSC server on Port 7000
  
• Listens for OSC Address "/runScript/path" which runs a script file if given the path in an OSC Custom Message Cue:
  /runScript/path "~/Desktop/ProjectorPower.scpt"
  
• Or listens for OSC Address "/runScript/code" which runs a single line of code from an OSC Custom Message Cue:
  /runScript/code "tell application 'Terminal' to do script 'telnet 10.3.12.66 23'"
  

This if course does *not* cause QLab to freeze since a different thread is actually calling the script.

The Python code requires PyOSC. Interested? Helpful? I'll try to make this a distributable app with dependencies. Never done that though. Not quite sure how.

Here's the code. I've also attached the Py file:

from OSC import *

import socket

import time, threading

from subprocess import Popen, PIPE

import os

def ScriptPath_Handler(addr, tags, data, source):

    print data[0]

    os.system("osascript " + data[0].replace("'", "\""))

def ScriptCode_Handler(addr, tags, data, source):

    print data[0]

    p = Popen(['osascript', '-'], stdin=PIPE, stdout=PIPE, stderr=PIPE)

    stdout, stderr = p.communicate(data[0].replace("'", "\""))

    print (p.returncode, stdout, stderr)

srvr = OSCServer( ('0.0.0.0', 7000) )

srvr.addDefaultHandlers()

srvr.addMsgHandler("/runScript/path", ScriptPath_Handler)

srvr.addMsgHandler("/runScript/code", ScriptCode_Handler)

# Start OSCServer

print "\nStarting OSCServer. Use ctrl-C to quit."

st = threading.Thread( target = srvr.serve_forever )

st.start()

try :

    while 1 :

        time.sleep(5)

 

except KeyboardInterrupt :

    print "\nClosing OSCServer."

    srvr.close()

    print "Waiting for Server-thread to finish"

    st.join() ##!!!

    print "Done"

[Drew Schmidt]

Happy Saturday morning everyone!

Sitting with a bowl of cereal and a mug of coffee. Sounds like a good time to finish up some fun coding. 

Here is a link to an executable app to handle this as well as an example workspace.

Just run the app and it will ...

• Create an OSC server on Port 7000 (you'll need to make a localhost patch with post 7000 in QLab)
• Listen for OSC Address "/runScript/path" which runs a script file if given the path in an OSC Custom Message Cue:
  /runScript/path "~/Desktop/ProjectorPower.scpt"
• Or listen for OSC Address "/runScript/code" which runs a single line of code from an OSC Custom Message Cue:

• 
  /runScript/code "tell application 'Terminal' to do script 'telnet 10.3.12.66 23'"

• You can send the command /quit via OSC to exit the application

[Chris Ashworth]

Very cool Drew!

Through some strangeness, I am not seeing anything in the folder that is unzipped — even though the zip itself is 8 megs… weird. Corrupted file, maybe?

A Saturday morning with coffee and cereal and code == one kind of heaven :-)

-C

[Drew Schmidt]

That's weird. The link above works for me in Chrome Incognito

Try this one?

https://onedrive.live.com/redir?resid=90EE873A1A70C526!4090&authkey=!AEhq4n9T44mTt5U&ithint=file%2c.zip

[micpool]

Looking forward to trying this.. but unfortunately OSC Apple Script crashes on my system when launched.

I'm on 10.8.5

Mic

[Drew Schmidt]

Shucks. I'll have to look at this later today. I've never Packaged python to an app. Not sure if its just not including the extra OSC libraries? I don't have another Mac handy to test it out today.

Does it bounce then close? Or is there an actual crash report?

If anyone is interested, the code comes from another project I built on a RaspberryPi to ready light and pressure sensors, then send OSC commands to QLab. I would be glad to post that info too.

[Douglas Heriot]

At first it didn’t work for me either – I ran it in a terminal and got "socket.error: [Errno 48] Address already in use"

$ /Users/douglas/Downloads/OSC\ Apple\ Script/OSC\ Apple\ Script.app/Contents/MacOS/OSC\ Apple\ Script

Traceback (most recent call last):
File "<string>", line 30, in <module>
File "/Users/drewschmidt/Desktop/Python Test/build/OSC Apple Script/out00-PYZ.pyz/OSC", line 1765, in __init__
File "/Users/drewschmidt/Desktop/Python Test/build/OSC Apple Script/out00-PYZ.pyz/SocketServer", line 419, in __init__
File "/Users/drewschmidt/Desktop/Python Test/build/OSC Apple Script/out00-PYZ.pyz/SocketServer", line 430, in server_bind
File "/Users/drewschmidt/Desktop/Python Test/build/OSC Apple Script/out00-PYZ.pyz/socket", line 224, in meth
socket.error: [Errno 48] Address already in use

So, I found I had another app already listening for OSC on port 7000. After stopping that, OSC Apple Script.app now works great!

If you want to find what error you might have, drag & drop the app into terminal (it’ll write in the path), then add "/Contents/MacOS/OSC\ Apple\ Script" on the end and hit enter to run (like in my example above) – you might get interesting output.

Also be aware, allowing arbitrary OSC strings to run as Applescript can have security implications. Make sure nobody untrusted gets access to your network – in theory someone could run a command that deletes all your files! Don’t run this:

/runScript/code "tell application 'Terminal' to do script 'rm -rf …'"

[micpool]

On Sunday, April 27, 2014 4:18:01 AM UTC+1, Douglas Heriot wrote:

If you want to find what error you might have, drag & drop the app into terminal (it’ll write in the path), then add "/Contents/MacOS/OSC\ Apple\ Script" on the end and hit enter to run (like in my example above) – you might get interesting output.

I get segmentation fault:11. which frankly, doesn't leave me any the wiser.

 

Also be aware, allowing arbitrary OSC strings to run as Applescript can have security implications. Make sure nobody untrusted gets access to your network – in theory someone could run a command that deletes all your files! Don’t run this:

/runScript/code "tell application 'Terminal' to do script 'rm -rf …'"

Presumably requiring a passcode for the app and perhaps an obscure OSC port might improve the security of the app.

Mic 

[Pierre-Luc Brunet]

Of course you guys are very busy but if at one point in time of the life of Qlab, the network command cue (UDP/TCP) could be created, that would be lovely.

Then we wouldn't need applescript or RS232 to control our external hardware and software. So many things can be controlled via network nowadays. I think it would be very useful.

Pierre-Luc

On Thursday, April 17, 2014 3:25:06 AM UTC+7, sam kusnetz wrote:

On April 16, 2014 at 4:21:43 PM, micpool (m...@micpool.com) wrote:

If the former, then I can put it on the list but I’ll be honest: it’s a long list, and this isn’t very pressing as compares to other items since this one has a known solution. But no harm in considering it, right?

[Sebastian Frost]

Pierre, I'm totally with you on that! Day after day I get requests from IT bods asking if they can send simple network commands to Qlab. It's something that would bring Qlab firmly into play with some of my slightly more complex installations...

Seb

[Pierre-Luc Brunet]

Actually you CAN send simple network commands to control Qlab but you just don't know it! 

Chris added the functionality back in a beta of version 3.0.8. Have a look at these two link:

https://groups.google.com/forum/#!searchin/qlab/John$20Huntington/qlab/pRsTprqBm-o/Kzc9_pXevJwJ

http://controlgeek.net/blog/2013/7/29/controlling-qlab-v3-via-osc-like-ascii-commands-from-medialon-manager

It's soo cool! I just control Qlab from the Terminal!! (Yes that makes me a geek, but aren't we all!?)

What you cannot do right (as far I as I know) is SEND custom network commands. But you can receive them. As long as they look like an OSC message.

If this discussion is to continue we should start a new post.

[Drew Schmidt]

Hey All

Here's an updated version of the app

Problem: I can only get the app to run on Mavericks. Not sure what's going on. Need it now? I can always send you the python code and instructions on how to start the application. It's not terribly difficult. The code itself runs on Mountain Lion, just not the application's bootstrapper. I'll keep messing around with this, but for now I need to get back to grading.

Alright. Here's what we've got. This guy will respond to QLab via OSC over port 54000. I've attached an example workspace to help you test it out. The application responds to the following addresses only

• /runScript/code "code string"
  This will simply run a line of AppleScript code
  
  
• /runScript/path "path to applescript.scpt"
  This will run a pre-written AppleScript file
  
  
• /runScript/Terminal "terminal command"
  Send a terminal command
  
  
• /runScript/UDP  "IPAddress"   Port#   "UDP String"
  This will send a command via UDP. I was just using this to control our ETC Gio Light Board. Pretty slick. I'm sure you could use this to do serial stuff if needed.
  
  
• /runScript/Telnet  "IPAddress Port"   "Telnet string"  (Not, IP and Port are in the same string)  or
  /runScript/Telnet  "IPAddress"  "Telnet string" (this will assume port 23)
  Sends a telnet command to the specified IP. I just used this to adjust the settings on a projector as well as turn it on / off
  
  
• /quit   or    /exit
  This will close the application. If this isn't done, the server / port will stay open until you restart your computer

As stated before, I've now tested this on a number of mavericks machines (including a brand new installation with no added python libraries). Worked like a charm. Open the app and run with it. Hopefully you all have some success too? 

[S!mon-R]

Wow, very interesting indeed!  But I'm still running a Mountain Lion and the app crash at load…  (Segfault…  :S)

I'va attached the log in case you are interested…. Anyway, I'm interested in the python code and I already have xCode if needed.

[Chris Ashworth]

Drew,

Wow, this is awesome.  I wonder: if we made a section on the site to highlight this and other software the community has made that works alongside QLab, would you be interested in putting up some kind of page about it?  e.g. if you’re interested in open sourcing it, a GitHub page, or something like that?

-C

From: Drew Schmidt drew.s...@nwciowa.edu
Reply: ql...@googlegroups.com ql...@googlegroups.com
Date: April 28, 2014 at 2:49:22 PM
To: ql...@googlegroups.com ql...@googlegroups.com
Subject:  [QLab] Re: Applescript causing video to freeze during execution.

[Pierre-Luc Brunet]

Very very cool Drew!!

This is gonna be so useful! (especially the UDP and Telnet commands) All the commands I've tried work, the only thing is that the app hangs (not responding) but it works anyway!

I've got a macbook pro retina 11.1 with Mavericks 10.9.2.

Here are also my logs if you are interested.

[Drew Schmidt]

Chris,

Absolutely! The community is why I made it. 

Just let me know what you want that to look like, what information you need, if you want to host it on GitHub or I ought to put it on mine. 

I'll also thumb through some other stuff. I'm planning on writing up something about my RaspberryPi and how it can facilitate physical sensors interacting with QLab. 

[Drew Schmidt]

Mic

Here's a link to another version. I tried bundling this using a different application. Hopefully it works better across OSs. I won't have a Mountain Lion machine handy to try it out today. 

-Drew

[micpool]

Thanks Drew

That's running in 10.8  and seems to be working.

I'll give it a thorough testing later today.

Great Work

Mic

[Chris Ashworth]

I suppose I was imagining a part of our site that would highlight and link out to open source projects people have made wherever they might be?

If you do go with GitHub, you can use their pages feature to make a nice looking front page for the project:

https://pages.github.com

At any rate, if anyone else has projects they’ve worked on that fall in this category we can take a look at creating a place to collect and direct people to them.

Cheers,

C

[Drew Schmidt]

Hey everyone

I made an app to go alongside QLab and posted it on GitHub with some instructions. So if you need to do ...
Apple Script
Terminal Commands
Telnet
UDP
... outside of QLab, here's an app that will respond to OSC cues from QLab. And of course, it's open source, free free to grab the code and bend it for your usage.

http://archiedestructo.github.io/OSC-Script/

Enjoy!

-Drew

[Chris Ashworth]

Drew, this is fantastic! I’m going to share it from our Twitter account (probably a few times) and see if I can find a place to link to it from the website.

Very cool stuff.

-C