AppleScript ensuring compatibility for a program with multiple versions

Hi friends.


I am working on some scripts for a DAW, specifically Ableton live. This program has multiple versions e.g. "Standard" and "Suite."


On my machine, here is a basic tell


tell application "Ableton Live 10 Suite"

activate

end tell


When I first wrote this script it allowed me to type "Live" and auto corrected on run to "Ableton Live 10 Suite" (in automator) as seen above. I am planning on giving these away to other music makers that may or may not have the "Suite" version. These scripts will work regardless of the version of the app one has, so if I distribute them like this:


tell application "Live"

activate

end tell


Can I assume that it will work the same way it did on my machine? In the same area... I believe the process name is typically always just "Live" ...not the full app name. Would it be better to approach making sure the app is running and top that way?



Here's a little snippet to maybe give you a better idea of how I'm using that basic tell block I mentioned earlier. This part is an ending dialog after a batch action is done with a bunch of keystokes in Ableton that allows the user to undo said batch action.


Thanks in advance for any help.




set undoTask to (text returned of theNumber) as integer

if button returned of opType = "Rename" then

set endMsg to display dialog "All done!" with icon file rxIcon buttons {"Undo", "Thanks!"} default button "Thanks!"

if button returned of endMsg = "Undo" then


tell application "Ableton Live 10 Suite"

activate

end tell

tell application "System Events"

repeat undoTask * 2 times

delay 0.2

keystroke "z" using command down

end repeat

end tell

end if


else if button returned of opType = "Consolidate" then

set endMsg to display dialog "All done!" with icon file rxIcon buttons {"Undo", "Thanks!"} default button "Thanks!"

if button returned of endMsg = "Undo" then


tell application "Ableton Live 10 Suite"

activate

end tell

tell application "System Events"

repeat undoTask * 2 times

delay 0.2

keystroke "z" using command down

end repeat

end tell

end if


else if button returned of opType = "Both" then

set endMsg to display dialog "All done!" with icon file rxIcon buttons {"Undo", "Thanks!"} default button "Thanks!"

if button returned of endMsg = "Undo" then


tell application "Ableton Live 10 Suite"

activate

end tell

tell application "System Events"

repeat undoTask * 2 times

delay 0.2

keystroke "z" using command down

end repeat

end tell

end if

Answered by hhas01 in 422144022

This is nonsense. AppleScript is perfectly appropriate to OP’s task, and the only supported option that speaks Apple events right. Anything else is an unnecessary exercise in pain. (Yes, there are lower-level Accessibility APIs, but those aren’t any easier to use than GUI Scripting.)



OP has two problems. First, using GUI Scripting to automate another application is notoriously fragile, not very portable, and subject to macOS security blocks. But I’m going to assume the Ableton Live app does not provide any sort of API making this unavoidable. Second, OP needs to activate the Ableton Live Intro/Standard/Suite app so that it receives the key events sent via GUI Scripting. If all versions of the app have the same CFBundleIdentifier then just use that, e.g.:



tell application id "com.example.foo" to activate



If they have different bundle identifiers then I’d suggest something like the following handler, which attempts to launch each app in turn:



on launchApp()
    repeat with aRef in {"com.example.foo.suite", "com.example.foo.standard", "com.example.foo.intro"}
        try
            activate application id aRef
            return
        on error number -1728 -- app not found
        end try
    end repeat
    error number -1728 -- fail if none of the supported apps were found
end launchApp


launchApp()


Since the only command used here is `activate`, there’s no need to worry about compiling application-specific terminology. Dealing with all the other pitfalls of GUI Scripting is left as an exercise to OP and their users, natch.

Just so you know, AppleScript is designed for end users. If you are distributing software, I strongly recommend a lower-level interface. You could use the scripting bridge from native code. Or you could construct AppleEvents manually. That would give you more flexibility to target multiple variants of an app and handle the inevitable errors.

Accepted Answer

This is nonsense. AppleScript is perfectly appropriate to OP’s task, and the only supported option that speaks Apple events right. Anything else is an unnecessary exercise in pain. (Yes, there are lower-level Accessibility APIs, but those aren’t any easier to use than GUI Scripting.)



OP has two problems. First, using GUI Scripting to automate another application is notoriously fragile, not very portable, and subject to macOS security blocks. But I’m going to assume the Ableton Live app does not provide any sort of API making this unavoidable. Second, OP needs to activate the Ableton Live Intro/Standard/Suite app so that it receives the key events sent via GUI Scripting. If all versions of the app have the same CFBundleIdentifier then just use that, e.g.:



tell application id "com.example.foo" to activate



If they have different bundle identifiers then I’d suggest something like the following handler, which attempts to launch each app in turn:



on launchApp()
    repeat with aRef in {"com.example.foo.suite", "com.example.foo.standard", "com.example.foo.intro"}
        try
            activate application id aRef
            return
        on error number -1728 -- app not found
        end try
    end repeat
    error number -1728 -- fail if none of the supported apps were found
end launchApp


launchApp()


Since the only command used here is `activate`, there’s no need to worry about compiling application-specific terminology. Dealing with all the other pitfalls of GUI Scripting is left as an exercise to OP and their users, natch.

LOL!


nonsense...perfectly appropriate...but...


an unnecessary exercise in pain...notoriously fragile... not very portable.. and subject to macOS security blocks.

The absolute awfulness of GUI Scripting as a solution is orthogonal to the choice of language used to write it. I’m pretty sure if Ableton Live provided a proper Apple event interface the OP would be using that to control it; as they aren’t, it’s fair to assume they’re using GUI Scripting not because it’s the best or the worst solution available to them but because it’s the ONLY solution there is.

Correct. This is an app that doesn't have any TouchBar controls... (yet). Thanks for the help. I am utilzing the Quick Actions option that was added in 10.14. I just use an Automator workflow to run an AppleScript/shell script combo. They work without using Automator as well... that's just the easy way to make a button on the TouchBar. I would love for it to be "lower level" John but at the same time it works really well honestly, and it has been very portable thus far... but before I release it into the wild I wanted to double check on the problem that has now been solved. I fully expect my utility to be replaced by something from the actual vendor at some point. Or maybe not.



Thanks again for the help here.

It may work well on your machine, but I would never recommend releasing anything using AppleScript. Sometimes I've done it myself when I have absolutely no other option, but that's a warning, not a recommendation.


AppleScript is always going to be the flakiest, most fragile part of any system. And you are using UI scripting, completely with hard-coded delays and keystrokes. Good luck with that!


I did check the software in question. It is built using Qt, so the Mac software is really a least-effort port. What you have is all you will ever get. Before releasing it, make sure it runs on the new operating system to be released next month. You might need to find a new project really fast.

Absolutely right. This isn't really a whole "project" just a utiltiy that I use, and am letting people have for free alongside some music "sample packs" and other things. Also, a funny note, but a lot of recording studios actually avoid updating to the latest OS. If they're only using a machine for that purpose of recording/mixing music and it works fine with all the plug-ins/capabilities they need, there's no reason to update. So luckily it will all probably work fine for most, if not all the people that have a desire to download my tools.


Thanks again for the advice.

Kvy

I think you'll be fine then. In this context, you actually are acting as an end user. It is fine to distribute scripts as an end user, with end user expectations of reliability. All too often I see people trying to start businesses or release apps using some really marginal technology. That just doesn't scale.

AppleScript ensuring compatibility for a program with multiple versions
 
 
Q