Error with osascript in `Execute Shell Command` node

As a non coder, I tried a small applescript, but got an error.

Code :

tell application "iTunes"
get name of current track
end tell

When tried in the script editor it works, but in Vuo I get :

/private/tmp/vuo-app-shell-FjNhOt:30:34: execution error: iTunes got an error: Application isn’t running. (-600)

Is this permission related too ? Any coder would get a similar fix for this ?

Applescript Test.vuo (1.11 KB)

Yes, we’ve checked and this is a permissions issue. It will require iTunes-specific nodes, such as requested for Read iTunes playlist.

Thank you for checking @jmcc

Ok sad to hear it’s permission related. As a non-coder, why is it so restrictive ? Is it due to macOS restrictions, or the way the node is built ? Doesn’t it take a lot away from this node it being so restrictive ? I would prefer it to be able to access and communicate with the iTunes & Spotify applescript libraries and ask for user permission on first launch if needed ?

I mean I wanted to retrieve song info played by either iTunes or Spotify, having to request & build specific nodes for each app is so much longer :(
Right now I’m able to do this by using a 3-rd party app (named TuneOut, Github link) that writes a little text file containing song info and album artwork, and load that data into a Vuo app, but it’s longer a process (asks for Safari support, needs to write a file etc).
It’s based on Applescript if I’m right, so it’s technically possible to access Applescript libraries, why is this node not able to ?

In the hope to retrieve Spotify & iTunes played songs I’ve also been voting for OSX Notifications Center Subscribe Patch but a less restrictive shell command node would allow much more custom / powerful things …


Yes, “a less restrictive shell command node would allow much more custom / powerful things …”, but that may not be good in all cases. For example, an unrestricted shell command node could delete all files in the user’s home folder, or remove, copy, or scramble user data. It would also be more user-friendly to have a node specific to iTunes than for people to have to use the shell node with osascript.

You can get around this to some extent having an AppleScript file run outside of Vuo and pass the info by writing info to a text file, .info file or perhaps using OSC if you can find an Applescript way to write to OSC (I’ve never googled that option, text file is fine for my needs). Given that Vuo can export screensavers now, a few iTunes peak and poke nodes could be worthwhile, at least to pull track and playlist data.

I’m not sure if it’s possible to bundle an Applescript in with a VUO app in a Contents sub-folder and somehow trigger that script to run (inside Vuo or externally)?

@useful_design thank you for the input. Yes, an applescript based app that writes a text file is what I’m using now. It’s ok-ish, but you have to have the script or app manually check for changes every second, write a text file etc, so that causes a delay.
Also, for personal use it’s ok, but for deployment, people have to give permission for that app to run too (unless you sign it and have it authenticate by Apple if possible).
I guess that’s where the Vuo team is right, people with bad intentions could bundle a script in an app, but running that app requires permissions, where a non-sandboxed script node with access could run a script with bad intentions as a Vuo composition inside Vuo, or as a Final Cut Plugin without the need for permissions ?!

Also, not a coder, so may be wrong, but I remember I read iTunification Github the best way is still through the macOS notification system, I guess it automatically sends like a push with info when a track changes or something.

The SQL database node requests may perhaps be useful too, since the notification system is based on a database file, but since recent macOS versions there localisation change a lot.

For now I’ll vote for the macOS notification node, to be able to also grab Spotify info, and for your edit nodes in Vuo request, which would allow faster node creation by tweaking node code.