< Back to IRCAM Forum

AppTranslocation + AS Command Line Tools

AudioSculpt
#1

Dear All —

D’abord, j’espère que vous allez bien pendant que tout commence à rouvrir ! …

If anybody can help, I am having trouble installing the Analysis/Synthesis Command Line Tools on a new Mac. That is, a 2017 Macbook Pro running Mojave 10.14.6. All other forum software installs fine on this machine. When I launch Install Commandline Tools.app from within the AS Kernels folder, AudioSculpt goes into AppTranslocation and is remounted on a volume whose path is given in the following window that appears:

Shell configuration updated to use /private/var/folders/z8/nmc2f03s1pn3r7p_k6n6z1xc0000gn/T/AppTranslocation/8B340365-C2F8-43BE-B521-57ABFE3D0514/d

Running supervp and pm2 commands in the shell continues to return “command not found” errors.

I tried a few possible solutions: First, following this post I removed the Current Settings.xml file, which worked for qcmv22 in a similar situation. This failed to solve my issue, so eventually I found other situations where users attempted to remove possible quarantines on their app contents by running xattr, as we’ve had to do often in Catalina. I used the following command:

xattr -dr com.apple.quarantine /Applications/AudioSculpt\ 3.4.6/AudioSculpt\ 3.4.6.app

but this did not solve it either.

I have another Mojave machine running these same command line tools successfully, but I cannot tell what causes the problem on my new machine. It was so long ago when I first installed them, so I don’t remember any alternate steps taken. I can use this older machine, but I would very much like to solve this for current and future situations as well.

Thanks so much for considering! —
Louis

#2

I think these supervp/pm2 commands are just links into the AS bundle, but relative ones. If you’re already trying to call these from a shell, I would try calling the target of the links directly (maybe an absolute path would be needed): pm2 and supervp are in the “AudioSculpt 3.4.6.app/Contents/MacOS” directory. If that works, you could add an alias in your shell, or even create a link somewhere in your path with a link to both executables. I can’t try it, I don’t have Mojave…
Another idea is that I ran into trouble several times with apps installed in /Applications. So I created a directory in my home were I install non-Apple stuff

1 Like
#3

Thank you as always, Fred! —

Yes I also found that these symlinks / aliases in the Kernels folder point to their originals inside of the MacOS folder you mentioned. Indeed an absolute path to them works great in the shell. I may have to continue in this way, but for some reason the symlinks aren’t working. I’ll explore a bit further.

I suppose I could also repair their integration with OpenMusic by providing the path to this MacOS folder instead of the default that appears (in the OM Externals preferences), or instead of a link to the AS Kernels folder. I’ll test this later.

After reading your comment I also tried creating folders outside of /Applications, but this didn’t seem to make much of a difference. I tried relocating the AS application folder into new folders in my Macintosh HD directory, also in my user directory. Was there a particular location that seemed to work best for you?

Thanks again! —
Louis

#4

My guess is that newer MacOS versions prohibit relative links into or out of an app or bundle from whatever was installed from a package. Also, maybe the “install commandline tools” thing triggers translocation so that the paths it tries to define point to a transient directory, or the links are themselves translocated and the relative path is broken (the links are in AudioSculpt/Kernels but point into AudioSculpt.app). Hard to say

With the way quarantine flags tend to be sticky, maybe reinstalling AS in a different place would work better than moving an existing install. Again, hard to tell.

I personally use an “opt” directory in my home, but that’s a Solaris thing that probably has no effect whatsoever (and I still got issues with AS/OM session directories, though not in a consistent way)

If you still have premium access, you might also try the raw AS command line tools downloads. These are almost the same as those in AS, without some packaging and communication niceties, but they’re 64bit. Maybe the restriction on 32bit applications worsens the situation, though I doubt it.

#5

Thanks, those are all very helpful ideas and I’ll try them.

I didn’t think there were any differences between the versions that came with AS versus the standalone, but I’ll try this too.

Yes, the “install” app definitely is what triggers the translocation; I’ve been observing the AppTranslocation folder and that is the only thing that creates a new volume inside. The app & its contents don’t seem to be translocated though; the original app remains in /Applications but seems to be “cloned” rather than moved into this new volume. I suppose the links are pointing towards this new volume, but I’m not entirely sure how to verify that.

Thanks again Fred! —

#6

I think the “install” app basically adds the Kernels directory to the PATH variable, so you can probably avoid it if it causes problems.

Instead of having a bunch of directories in that variable, I usually create a “bin” directory in my home, add just that to PATH, and then create symbolic links in there to executables I tend to use often. I find it reduces clutter and makes it easier to reset the PATH variable to a “clean” state when I want to test alternate versions

1 Like
#7

Using links in a single directory also allows me to disable/change a name resolution temporarily by renaming a file, and it applies everywhere without having to update the PATH variable in my (many) open shells

1 Like