Yosemite

[mikehalloran]

There are many possible reasons why DP 7.24 might not open on your machine. It can be anything to improper installation, not repairing permissions, not granting permission in Security for the installer to write where it needs to.

Anyway, works fine in Yosemite for me.

We need far more information before any of us can help you.

[Altauria]

I'd like to add a possible solution to some of the Emergency Stop errors. I had the same problem and through a series of narrowing down components, it appeared that there was a miscommunication between DP, Vienna Ensemble Pro 5, and my RME AIO (HDSPe) driver.

I opened up the Standalone Vienna Ensemble Pro software; NOT the server app, as the standalone features audio hardware in its Preferences. Upon opening it, it gave me a message that my audio driver had changed. I confirmed that everything was in order and VOILA - so far no errors/interruptions.

I hope this simple solution works for others. If you're not using VEPro, perhaps you can use this principle to other software/hardware in your chain.

[mhschmieder]

I upgraded my Late 2010 MacPro at work from Mavericks to Yosemite yesterday, and it was the smoothest transition ever. The only thing I had to do afterwards was update Xcode Tools so that Subversion SVN Client would work on the command line again, update my May 2014 build of Eclipse IDE to the September 2014 build, and install later updates to my Eclipse plug-ins.

All that remains is to update Oxygen XML Editor to a version that supports Oracle's Java 7 & 8 so I don't have to install Apple's Java 6 on Yosemite (it was a big surprise when they released that update anyway), and make sure AraxisMerge works or update it if not.

Most of my other development tools sit on my Windows 7 box.

Please note that this experience has no bearing on audio work; I just wanted to share, because I think it can still be informative to hear that a developer box transitioned so smoothly as usually this is NOT the case.

Yosemite seems snappier than Mavericks, somehow.

OTOH I truly hate the colour scheme and tried desperately to change it, to no avail. The best I could do was change the Finder Window background colour to semi-mute the aggressiveness of the Cobalt Blue folder colours. Cobalt Blue is the least relaxing, most stressful and distracting colourthat one could choose; it demands attention, which is why people complained about Kurzweil's blue LED on the PC3 series, and is why I always change my Windows computer background before anything else when I set up a new box.

The new Apple window decorators are similarly distracting, attention-grabbing, and ugly. I think the new shades of red, orange, and green may have had a practical goal though of being accessible (that is, distinguishable by colour-blind people).

BTW, blue colour-blindness strikes 5% of the population (I'm doing this from memory), which is a lot less than red-green colour-blindness, but it only affects men (or maybe I have that relationship inverted -- no time to look it up again right now).

Other than that, the flat look takes some getting used to, as well as the new border shapes etc., and it also surprised me to launch my own application on Yosemite and see it look a bit different here and there, but I think probably overall it is an improvement on Mavericks.

I can't upgrade my Late 2010 MacPro at home until I am done with this album project. Too risky beforehand. Aside from that though, the last I checked (OCT/NOV 2014), RME didn't yet have Yosemite-compatible drivers (or at least, people were complaining on forums).

[mikehalloran]

All that remains is to update Oxygen XML Editor to a version that supports Oracle's Java 7 & 8 so I don't have to install Apple's Java 6 on Yosemite (it was a big surprise when they released that update anyway), and make sure AraxisMerge works or update it if not.

You may have to install it anyway if you use any 32bit applications as Java 7 & 8 are 64bit only.

MasterWriter 2 and Google Chrome require Java 6 in my world. A few web applications on government sites that I must use require it so that I can talk to their back end.

I've found nothing that requires Java 7 if Java 8 installed. Of course, that doesn't mean there isn't something out there somewhere...

[mhschmieder]

Java is my main livelihood. I just don't understand why anyone would still use it in a browser (I had to start this way initially, but that was back in 1999). This is the USUAL reason (e.g. Chrome) for needing Java 6, but of course, there are exceptions as well with desktop apps.

The thing is, Macs were always different; you had little control over which Java as it was pre-installed (this is an oversimplification, but I am talking from a developer's point of view). That is, you couldn't install a Java of your choice (especially not one that was 100% self-contained like a normal JVM on other systems). Oracle normalized things to be more similar across platforms, with traditional installations vs. OS-buried dependencies that couldn't be swapped or version-specified.

Unfortunately, Apple held back critical code (this bit me big time, and by surprise, with retina compatibility issues), and other than the usual cost of technology transfer and development time, several vendors have stayed with Java 6 on the Mac (whether or not intentionally related to Oracle having had a devil of a time reverse-engineering the stuff Apple didn't hand over).

I was at an Oxygen XML user's group meeting at Salesforce.com in SF a couple of months ago, and it was pretty clear their main thrust has been on dramatically expanding the scope of the product to be more of a general purpose authoring tool (a big surprise to me) in competition as well for web-based publishing vs. traditional tools from Adobe and others.

Anyway, the short of it is that the "old way" was to assume Java was on the system since it was supplied with OS X. So there are probably a number of desktop applications that don't do anything special in their installers or their app.info files to supply or specify a particular version of Java in its current location under /Library/Java (not to mention the bugaboo of the external dependency that often had to be copied from older versions of OS X). In some cases, this is just because those apps haven't done major updates or infrastructure work in some time.

I think this is why Apple finally did their own update of Java 6 for Yosemite a few months ago, even though they had long ago handed over most (unfortunately, not all) of their code to Oracle to manage as a standard distribution the way it is installed on Linux, Solaris, Windows, etc. There's no incompatibility with having both -- especially as they are installed in entirely different areas -- but certainly the Java 7 vs. Java 8 issue is less tricky (64 bits, same vendor and install area, etc.). This should be true even for WebStart and browser-hosted code.

The upcoming Java 8u40 update (planned for March 2015) fortunately seems to address all of the remaining retina issues on Macs, whether running Yosemite or Mavericks, along with other instability issues, so I would expect by the next Mac OS X release post-Yosemite (Sequoia? Carmel? Pacifica?) that it will become fairly rare for people to need to download and install Java 6 on a fresh Mac/OS X.

My apologies for not being as coherent past 2am as if I had written this earlier in the day.

[toodamnhip]

Somewhere in my upgrade to Yosemite and DP 8.07, I lost the ability to paste Waves plug in and Waves is broken in terms of snapshot automation

[mikehalloran]

Java is my main livelihood. I just don't understand why anyone would still use it in a browser (I had to start this way initially, but that was back in 1999). This is the USUAL reason (e.g. Chrome) for needing Java 6, but of course, there are exceptions as well with desktop apps.

The thing is, Macs were always different; you had little control over which Java as it was pre-installed (this is an oversimplification, but I am talking from a developer's point of view). That is, you couldn't install a Java of your choice (especially not one that was 100% self-contained like a normal JVM on other systems). Oracle normalized things to be more similar across platforms, with traditional installations vs. OS-buried dependencies that couldn't be swapped or version-specified.

Unfortunately, Apple held back critical code (this bit me big time, and by surprise, with retina compatibility issues), and other than the usual cost of technology transfer and development time, several vendors have stayed with Java 6 on the Mac (whether or not intentionally related to Oracle having had a devil of a time reverse-engineering the stuff Apple didn't hand over).

I was at an Oxygen XML user's group meeting at Salesforce.com in SF a couple of months ago, and it was pretty clear their main thrust has been on dramatically expanding the scope of the product to be more of a general purpose authoring tool (a big surprise to me) in competition as well for web-based publishing vs. traditional tools from Adobe and others.

Anyway, the short of it is that the "old way" was to assume Java was on the system since it was supplied with OS X. So there are probably a number of desktop applications that don't do anything special in their installers or their app.info files to supply or specify a particular version of Java in its current location under /Library/Java (not to mention the bugaboo of the external dependency that often had to be copied from older versions of OS X). In some cases, this is just because those apps haven't done major updates or infrastructure work in some time.

I think this is why Apple finally did their own update of Java 6 for Yosemite a few months ago, even though they had long ago handed over most (unfortunately, not all) of their code to Oracle to manage as a standard distribution the way it is installed on Linux, Solaris, Windows, etc. There's no incompatibility with having both -- especially as they are installed in entirely different areas -- but certainly the Java 7 vs. Java 8 issue is less tricky (64 bits, same vendor and install area, etc.). This should be true even for WebStart and browser-hosted code.

The upcoming Java 8u40 update (planned for March 2015) fortunately seems to address all of the remaining retina issues on Macs, whether running Yosemite or Mavericks, along with other instability issues, so I would expect by the next Mac OS X release post-Yosemite (Sequoia? Carmel? Pacifica?) that it will become fairly rare for people to need to download and install Java 6 on a fresh Mac/OS X.

My apologies for not being as coherent past 2am as if I had written this earlier in the day.

Interestingly, SalesForce works best on a Mac in Chrome which is still 32bit.

Finale still requires a Java 6 run time as does MasterWrier 2.

[MIDI Life Crisis]

I tried to get a little more info on Java stuff in this thread at the Finale forum but got poo-poo'ed by a few of the members for going o/t. I did't think it was o/t at all, frankly, but some of those guys are rabidly anal retentive about keeping "their" threads squarely clean and free of any diversion (even if it it's totally relevant). Butt I digress.

[mikehalloran]

I tried to get a little more info on Java stuff in this thread at the Finale forum but got poo-poo'ed by a few of the members for going o/t. I did't think it was o/t at all, frankly, but some of those guys are rabidly anal retentive about keeping "their" threads squarely clean and free of any diversion (even if it it's totally relevant). Butt I digress.

Well, they're really going to dislike my reply in that same thread. To heck with them - it's an open forum.

[mhschmieder]

I'm tired and am behind due to work/sessions/gigs these past few weeks, so I apologize if this is repetitive, but I figure it likely isn't based on the last two questions.

First off, I was able to quickly install the latest Apple Java 6 the other day, and Oxygen XML Editor now works fine with no configuration or update required.

Secondly, just to make clear the Java mystery on Macs to those who aren't developers, Apple packaged it as part of the OS, and thus desktop applications that were built on Java had to use whatever was installed on the computer (though they could specify which version, when available, and order of preference when not available). This often meant apps would have to do emergency updates to stay in sync with unexpected changes by Apple.

When Apple finally gave up control of Java on the Mac and handed to Oracle most (but unfortunately not all) of their code to maintain and move forward, Oracle decided to "normalize" distribution to be like Unix/Linux/Solaris/Windows/etc. by having Java install in a regular location with all of its dependencies contained (Apple's Java had a somewhat hidden dependency on a private file that was illegal to redistribute).

Unfortunately for many developers, this also meant one suddenly had to be responsible for packaging Java with their apps (to maintain control over version dependency), and many vendors haven't prioritized this yet so are still depending on the built-in Java 6 that now has to be specifically downloaded and installed on later versions of OS X. It can be a bit difficult to properly package an app on a Mac in a technology that isn't still fully supported by Xcode.

The advances under Oracle have been humongous, but many got bitten by the "incomplete" status of the handover; most particularly with retina display non-conformance. Only the upcoming Java 8u40 update scheduled for early March 2015 fully solves this problem (I am using a developer preview at the moment as we needed to feel confident of problem resolution).

Few people here need be concerned about these details, but hopefully this explanation diminishes the intimidation factor. Most people experience Java in browsers -- where it is an inappropriate technology in my view -- vs. in desktop apps. Nevertheless, requests to download an update to Java on OS X are generally triggered by the browser and generally cannot be ignored (for the most part) due to the never-ending battle against security concerns that now affects almost all software technologies (wouldn't we all love for GateKeeper to go away?).