Mac OS X 10.11 El Capitan status update on compatibility

Cubase
#49

One option would be to create 2 partitions on your HD, a new one for 10.10 and (the existing HD) for 10.11.1. Run Cubase on 10.10 (of course). You may actually find that you end up with a better (faster and more stable) install since Cubase won’t be competing with all the other ‘junk’ you might normally use (Dropbox, OneDrive, etc…etc…)
You obviously have to have a big enough HD but I think that’s what I’m going to do.

Another option would be to use VMware Fusion to create an OS 10.10 on an Virtual Machine with Cubase on it… (although you’d need a pretty beefy Mac to run Cubase this way).

When the dust has settled and Steinberg sort it all out, just run the updates and delete your 2nd partition (making sure you copy any valuable data off it first!!)

Just my two-penneth.

#50

I take it you’re not a software developer? (I am). You have a confused notion of what testers and developers do. When you have a new beta developer release out for an OS, and an existing program, testers and QA engineers should (and do) test whether the program works with the new OS, create bug reports for any issues found, etc.

You seem to think that testing is only about making sure existing versions of a software work in the stable version of an OS. That’s not the case in any major software company. Some smaller shops might do it that way merely out of lack of available resources, but most competent small shops will too test their products with the developer betas to fix whatever needs to be fixed.

That’s how all those companies are able to launch updates to fit a new OS on day one or within a couple of weeks.

The number of changes doesn’t matter at all, since only the ones affecting your product are important. The total number of changes is across all subsystems and programs, including ones not touched by your product at all. E.g. thousands of them would be to the revamped Web engine, etc – and have nothing to with Cubase.

And of course there’s always the GM, released weeks before the new OS, that has few, and usually NONE at all, differences to the final version.

The reason SOME enterprises take “up to two years” to implement an OS upgrade is because enterprises are slow moving behemoths, with tons of legacy crappy code, even stuff depending on IE6, Active X and what have you.

#51

This naive assumption on the competence and benevolence of companies falls down when one has experience with the software industry, especially the professional one, where many companies are known for horrible release practices, disrespect for their users, complacence, money-milking, etc.

Steinberg, especially in early 00’s, was notorious for leaving known bugs unclosed for years on end, and then coming up with a new paid version to fix them (not unlike finally getting Retina support in another 8.5 or 9 paid release, 5 years after the feature has been introduced).

Not to mention companies like Quark and other such bad apples – with them the treatment of customers and releases was so bad that they managed to lose their #1 leading position in their industry, and most of their users, in just a few years.

I think that Steinberg is better post-Yamaha in those regards, but still this lack of transparency (and results) nearly 2 months after the GM is troubling.

For people who don’t have other needs to update to El Capitan of course it’s OK, they can always use older versions, especially if they only work in music.

Until then, this of course makes anybody buying a new macbook/iMac --that comes with El Capitan – to use it with Cubase to have to manually reinstall a previous version of the OS on it, perhaps one without the latest drivers for the screen and peripherals too.

#52

@hejazzman,

Your last two posts seem to paint opposite pictures of the software industry.

The first painted them as fastidious and enthusiastic, but the latter as slack a-holes. So which is it?

It is more that most are somewhere in between. Certainly in my work with rolling out a testing methodology to a major retail store chain, and improving the governance of projects to ensure testing and documentation were adequately funded at a major bank, testing was the poor relation in project budgets, and it was an uphill battle to get people onboard.

At the retail chain, I did a spreadsheet that could do ad-hoc reports directly from the Mercury testing database, and the test script steps numbers ranged from a couple up to 140+, when they should have a mean of 10-12 with a narrow standard deviation, so testing practice is still relatively immature in places.

Of course a software house will run up their stuff on a new OS preview to see where the land lies, but these later OSs have been going through several changes in functionality at the 11th hour, unlike previous ones, where the candidate release was fairly final more than a month before the official release to OEMs. With that sort of short timeframe, it doesn’t leave much time to fix anything that may be broken, especially if it requires a fix from the OS maker, as it did for Win 10 for Cubase to get the go ahead.

To a certain extent, it is a crap-shoot as to whether one makes it through without a holdup, as even if one’s program is ‘perfect’, it only takes something to change incorrectly on the OS side at the final release, and it may adversely affect yours, but the competition gets the Ok. Again, it all comes down to how its done under the hood in yours. And unless there is a complete rewrite from the ground up for each OS version, there is a tonne of legacy code that has managed to dodge bullets for years! And Cubase is the most full featured DAW out there, so has more possible failure vectors.

Oh, and I do do software, and am presently up to my neck in PHP, javascript, regular expressions, XSL and some VBA, which can be a pain if I lose track of which format test condition syntax I am supposed to be using at any particular instant.

#53

With respect, you guys are wandering down a blind alley.

Regardless of what Steinberg have / haven’t done what they are ‘guilty’ of is woeful communication.

To wit, we STILL don’t know what the hell is going on.

#54

Obviously both. Some companies are fastidious and enthusiastic, others as slack a-holes only in it for the money. And there are even degrees in between.

An issue is that Steinberg insinuated that they don’t do tests at all before release, even with the GM. And of course we’re now a month past the official release too – actually we’re already at 10.11.1 stable.

Hear you bro…

#55

Yeah, and to think I left Logic (which I’ve used for 5-6 years, after I’ve started out mid-nineties with Cubase until up to a couple of SX releases), because Apple was too opaque and uncertain on issues and future developments.

#56

This time, I have to blame Apple. I’ve not seen a release of OSX break this many things - Cubase, Office 2016 and many others have been bricked. I’m not in a position to say no to these upgrades because they bring security updates. So as soon as 10.11.1 came out and tested solid with Office 2016, my company forces it on us. I don’t use the Cubase for my work, so not a huge deal.

But I’m late now on an important volunteer/non-profit job because Cubase won’t work. I will be firing up my previous Macbook and going through the install process this weekend just so I can finish the project.

Steinberg can’t continue like this much longer - people are getting new Macs every day and those macs come with El Capitan. That means every new Mac buyer will not be able to use Cubase.

Ed - it’s been nearly a week. Nothing new?

#57

They may not really know either, as they might be waiting on Apple for some feedback.

There is the Win 10 precedent, where some symptoms of the problems were mentioned, but after a few weeks, some details were released about the problem being with MCSS, at a depth that only MS could know about from actually doing the investigation and discovering what was actually going on. And the problem was on their side.

MS is a little more transparent these days, and their audio team lead engages with the public too, as evidenced by their handling of an SD card issue recently, where the problem was purely on the device maker for using reserved bit fields in the file directory, but MS still implemented an extra check, and blogged about progress on the way, as well as on a GearSlutz thread. That still took a few weeks to come to fruition, just because some things take the time they take.

Now, if this one requires some investigation on Apple’s end, we have no idea how transparent they will really be to SB, let alone us.

I suppose it comes down to whether you just want to be told any old stuff when there is nothing to tell, or wait until something of consequence comes forth.

#58

If history is any indication. It takes about 3-4 months for an update. After a new OS release.

#59

We have collected all test results and are currently preparing the needed steps to offer full El Capitan compatibility. As soon as I have received the final list to be published, we’ll set up a knowledge base article to keep you updated on the progress for each product.

#60

Hi
I have the actually Mac O 10.11 installed. Now i read this warning. For me it is to late.
Please give me an information, what shall i do to use the software for my yamaha pr7.
Maybe in German?
Thank you.

#61

Learning from history is usually a good idea. When OS X 10.10 (Yosemite) was released in October 2014, it “broke” Cubase 7. Cubase 7.5 was released in December and Yosemite compatible version of Cubase 7 was released at the end of January 2015.

So learning by history, we’ll probably see the following timetable:
Cubase 8.5 will be released, early or middle, December and an El Capitan compatible version of Cubase 8 will appear late January, next year.

At least that’s what history suggests. :wink:

#62

Nothing like a month+ head start of an El Capitan-compatible 8.5 to force users to the paid upgrade if they want to use Cubase on their El Capitan Macs…

As for the Cubase users who need to be on El Capitan because they use their laptops for other things too (e.g. company they work for mandates latest versions for security reasons, they develop for iOS/Mac, they need some fix for hw problems, etc) let them wait…

And of course anybody buying a new Mac between now and December or whenever the fix is released will have to jump through hoops, un-install the OS, install Yosemite, etc to be able to work with Cubase…

#63

Nothing like a month+ head start of an El Capitan-compatible 8.5 to force users to the paid upgrade if they want to use Cubase on their El Capitan Macs…

That would be so messed up if they require us to pay for El Capitan compatibility. It brings back memories of when Antares charged AT7 owners for a 64bit update.

Cubase will always have a special place in my heart, but in the meantime I’m considering using Logic X for awhile until Steinberg can figure out how to get this thing OSX stable for the long term. I just want to make some music without having to deal with frequent crashes, freezes, missing media from the bay, etc. :sunglasses:

#64

Just purchased Logic X Pro, its cost was less than 50% of mine Cubase Artist, it’s working great on 10.11.1 with all my AUs and I have found it really intuitive and easy to use with great native sounds and instruments.
I will sell Cubase Artist license… :slight_smile: cheers!

#65

After updating all my software and drivers and doing careful research into compatibility, I bumped one of my studio machines up to El Capitan and spent a few days writing with Cubase. So far it’s been working almost the same as Yosemite, beside the splash screen being a little funky when first starting up Cubase.

Obviously everyone’s experience will be different (I know there are plugs and drivers out there that are definitely NOT ready for primetime) but I was fearing for a much worse situation than what I got. Lucky me, I guess. Looking forward to an official Cubase update.

#66

After updating all my software and drivers and doing careful research into compatibility, I bumped one of my studio machines up to El Capitan and spent a few days writing with Cubase. So far it’s been working almost the same as Yosemite, beside the splash screen being a little funky when first starting up Cubase.

Obviously everyone’s experience will be different (I know there are plugs and drivers out there that are definitely NOT ready for primetime) but I was fearing for a much worse situation than what I got. Lucky me, I guess. Looking forward to an official Cubase update.

That’s cool @orchetect. Did you have a chance to try C8 Pro on OSX 10.11 with any third party plugs? If so, how was it?

#67

Don’t know who you are talking to @paaltio, but I disagree. I’ve had to do iOS dev against beta iOS and Xcode releases. Yes, there are issues, as there are with anything beta. By the time they drop a beta release, they don’t change a whole lot. It’s usually fielding and addressing radars around issues with the APIs as they are within that beta.

I have found that the iOS/OSX beta builds_are good indicators of what final builds will look like. I can’t think of a time I had to make any significant code changes to accommodate a GM build at the last minute, after having done dev against a beta, put it that way. I have had to wait for them to fix issues that affect my code, but if there is change in the API, there are typically options that allow me to stick with the code I have to some degree.

I would argue that It is healthy software development - when you are building against a platform that you_know is going to change significantly once a year - to proactively develop against the next release of the platform you are developing for. Not doing so leaves you with a pile of very upset long-standing, dedicated customers. If what you are saying is true, the iOS app store should be brought to its knees with broken apps every time they rolled out a new release.

The Apple media outlets had already put out the message that this was a fairly innocuous maintenance release, which is what prompted me to upgrade, at a time I usually don’t. I feel like the messaging from Steinberg was clear enough, pervasive enough and early enough to stop me. Not good business.

As for resources, it takes a Dev or QA person half a day to spin up a beta build, load an Application in development onto it with some array of known common setups, and start reporting the things that are going to be problematic, and another hour or two after that to upgrade and perform some cursory checks again. It doesn’t take a big Dev team to do that much, and they could have put the message out sooner based on findings at the minimum. That little bit of effort would have better informed my decision making, and kept me working.

#68

Couple of hardware updates that I discovered:

  • Focusrite reports that a number of their products will work if both the interface and C8 are set to 44.1 or 48k at launch time:

http://us.focusrite.com/answerbase/are-focusrite-products-compatible-with-el-capitan

I tried the same things they are reporting with my Duet 2. Here’s the deal:

  • Many of the Focusrite products will_work with C8 if you set both C8 and the Focusrite device affected by the no audio problem (the Scarlett series and one or two others) to 44.1k or 48k prior to launching it. The wording on their site seems to imply that once launched, you can then flip to 88.2 or 96 if you have a project running at that rate, but I can’t confirm that.

  • I have been able to confirm that the Duet 2 will work with C8 on El Capitan at 44.1k and 48k. However, if I try to launch C8 into a 44.1 or 48k project verify that the audio is working, then try to flip that project to anything above 48 or open another project above that rate and adjust the rates in my Duet 2 and C8 accordingly, I lose audio again. So in a nutshell, you can still work at 44.1 or 48 on the Duet until Steinberg sorts this out.