MOTUnation.com

I've tried and failed to get this bug to occur, but seeing this video, back whenever it was first posted, has made me not invest too heavily in VCA mixes for fear the bug might creep in and mess with things. It's possible MOTU just can't recreate it, but it would be nice to hear from them on the subject.

mikehalloran wrote:If a shared resource is overwritten in 10, it might break the functionality in 9. The workaround is to reinstall 9xx — that will cripple some functionality in 10 which can't be restored till it's reinstalled and so forth...

I gotta say that I've been screamin' about this for 7-8 years now.
What I'm talking about are all of the folks who, when queried about whether or not is was possible - - or even advisable - - to install more than one version of DP on a system drive, would seemingly ignore the likelihood that "if a shared resource is overwritten by the newer version, it might break the functionality in the older version."(Italics are my edits).
I've always maintained that the only positive-proof way to run multiple versions of DP on a system, was to run multiple partitions - - each with it's own OS and it's own DP install. In my case, that's been as many as 4 versions in the old day - - now, just two....my "functioning" DP install and my "test" DP install.
In any event, it used to kill me to see some folks advocating, "sure!...sure!...go ahead and install the newest DP right there, along side of your current, rock-solid install! can't hurt a thing!"
....or can it....

williemyers wrote:In any event, it used to kill me to see some folks advocating, "sure!...sure!...go ahead and install the newest DP right there, along side of your current, rock-solid install! can't hurt a thing!"
....or can it....

Agreed. If you read read the whole threads on this subject at each DP update, there is always a handful of things that don't work properly when you have two versions installed on the same startup partition.

I always have a test partition, and not just because of DP. OS X updates can be as dodgy as DP updates. Some plugins stop working at OS X or DAW updates. Some of us actually use computers for more than DP, and all that stuff has to keep working too. It's good that DP keeps working on older OS versions. It's a major PITA for Logic users who have to stay close to the most recent OS X version to get the latest version of Logic, only to find other critical apps are not ready for the new OS X version.

williemyers wrote:I've always maintained that the only positive-proof way to run multiple versions of DP on a system, was to run multiple partitions - - each with it's own OS and it's own DP install. In my case, that's been as many as 4 versions in the old day - - now, just two....my "functioning" DP install and my "test" DP install.

This.

Working great over here, love it!

Freddy Bloggs wrote:Working great over here, love it!

Glad to hear it! What system are you running Freddy?

It always seems that many are able to run the latest version of DP without issue, but others encounter challenges that take some significant effort to overcome. I prefer to let the dust settle before diving into a new release, but that's just me. Right now, I just can't complain about 9.52.

I’m the only one who if the latest DP run well, I delete the previous version? Anyway I have the installers

mikehalloran wrote:

Shared resources are always overwritten by the most recent installation.

This kind of thing really bothers me. I have never understood why an app needs to install a bunch of crap into the subfolders of /Library/.

Even when Apple added sandboxing and containers to macOS, a sandboxed app still gets to put stuff wherever it wants in /Library/. As it stands, containerization in macOS only applies to the user-level ~/Library/.

Apple's current sandboxing policy requires sandboxed apps (like anything from the Mac App Store) to store all its user-specific stuff inside a container in subdirectories of ~/Library/Containers/com.appDeveloperName.appName/. That way, an app can't surreptitiously access preference files and caches from other apps, like your browser, email app, etc. This is obviously good for privacy and security.

However, wouldn't it be even better if everything non-user-specific for a given app was contained within the .app itself? I can understand why hardware drivers need to be in a specific folder, but what is the point in having all these folders in /Library/Application Support/?

I don't know what the point is, but I can tell you one of the several disadvantages of it, which is that it can make it very problematic to have several different versions of an application installed at the same time.

Apple's own developers must have known about that disadvantage, because at a certain point, they started making XCode (their software development app for writing apps for Apple platforms) contain everything it needs within the .app itself, because they knew developers would typically need to have several versions of XCode installed simultaneously without any conflicts.

So if XCode can contain everything it needs within the .app itself, then why can't everything else? Seriously!

The only files that an app like DP might need to have outside of itself would be Audio Units or VST3 plugins that someone might want to use in a different audio application. In that case, when you install DP, in the subfolders of /Library/Audio/Plug-Ins/, DP's installer could simply make aliases to the files inside the subdirectories of /Applications/Digital Performer.app/, and make sure their names include the version. That way, installing a different version of DP wouldn't cause any conflicts.

I would love it if, someday, Microsoft Office, Photoshop, DP, and everything else could be installed without ANYTHING being put ANYWHERE on my hard drive except just the app itself. That's the way the Mac was supposed to be, but somewhere along the way, people became idiots.