Oh yeah. I still had a good old Motu UltraLite mk3 FW version at my cottage. A purchase from 2009. Found someone through Facebook to give it away to. Apple removed system-level support for FireWire in OS 26. At my main place, the Focusrite Clarett+ is still working fine. Wouldn’t strictly call it a problem though but you’ll never expect the Spanish inquisition.
Sorry, I originally posted this in the wrong thread:
Has anyone that still has an Intel-based (mine is 16” 2019) upgraded? Pros/Cons? It just appeared as an option for me so it must be compatible with my hardware.
You are right, and this is something we all should be aware of. I heard the same thing before from a software developer team. Beta could work for finding serious troubles during the macOS developing period, but it cant cover everything. There could be a change on the final release of macOS spec, that means we need to test again after the final macOS release.
I’m exporting to WAV 32 bit. It seems to happen with all playback templates. MacStudio M2Max with macOS Tahoe. Dorico 6 is current to known updates.
Could it be some sort of permissions issue or cloud-sharing issue with the folder you’re exporting to? If you export to, say, the Desktop, does the problem still occur?
I understand this and I’m not really complaining about Steinberg because they’re not the only group slow to make compatibility statements. Please accept my apologies if it sounded like that. Compatibility testing just seems to be delayed with smaller software companies and I am curious as to why. For example, do they wait until the beta version has been deemed a final version and then jump in with every possible resource, do they engage “civilian” testers for the beta versions from the onset of the OS beta process, or…?
I think many endusers would be happy to know that “[whatever] function does not seem to work as expected” type of compatibility statements as soon as the final version of the OS is available rather than wait for a fully compatibility statement and/or update to the software. Use feedback at this point could help Steinberg prioritize any “fixes” based on what seems to be most important to users.
Just some thoughts…no judgment.
No but good idea to consider this. It’s the same location I always use and I verified both my user permissions to the drive location and Dorico has full access to the drive. Not using cloud or sharing. Thanks, though.
Interesting that you shared this. I had not noticed until some extensive editing work on a piece that sometimes playback cannot be heard when using the Scrub playback feature, halting the “scrub,” making edits and then using regular playback from the point of the edit. If I reactivate playback, the issue goes away for quite a while returning only with extensive editing. I’ve not really been able to clearly replicate the steps that causes it to occur, though. It doesn’t occur all the time but sporadically.
I didn’t see this post of yours until today, 9/26. Thank you! So, I rescind my “observation” of it taking Steinberg so long to comment on compatibility. Interestingly, I checked the Steinberg support site on 9/15 for a compatibility statement and the statement appeared on 9/16. Oh well, kudos to Steinberg for being on top!
NB: I’m wondering how difficult it would be to send out an email regarding compatibility to all registered users when new OSes enter the picture…whatever that statement needs to be (compatible, not, somewhere in between…, etc.). Maybe that happened and I just missed it…
Steinberg can only send emails to people who opt-in and allow marketing communications.
There’s a new Mac OS every year, so most Mac users are used to the annual routine of following the tech press, watching companies’ websites and hanging out on forums before upgrading.
3 Likes
Are you by any chance trying to export with “funny” characters in the filename that might cause the problem, @kasky1? I’ve run into that problem before.
I recently dug out my old Ultralight mk3 Hybrid to use with Sequoia/Cubase 14 , as it has a handy Spdif out. I had to lower security for it to run the drivers.
With Hybrid you are still good to go with USB2. Mine had only FW. My main location has Focusrite Clarett+ and @ my cottage I switched to the optical S/Pdif output of my thunderbolt dock.
True. The hybrid mk3 is very handy unit. I use it’s Spdif output to my Bryston DAC, and it sounds great. Much better than the mk3’s audio outs fed to my preamp.
If only the Mac Studio had an AES/ABU audio out - then I’d be really happy.
2 Likes
Oh, if it were only that simple. Unfortunately, not. I’m not encountering this as much with the last update to Dorico. Nothing was mentioned about audio files in the update’s release, though. Of course, there has also been an update to macOS Tahoe. 
Thanks for the comment and sorry for the late reply. Please don’t mind what I said, there is no need for apology. I was just trying to state that macOS compatibility is always a big issue for software developers.
My experience and knowledge is very limited but as far as I know, start to test intensively just once right after the final macOS release is the most reasonable way given there is always budget and schedule matters. They don’t want to consume their time to start testing in early stage where there are more uncertain variables and you would most likely end up with testing the same thing several times, this is more true for smaller developers.
On the other hand, I suppose macOS developer has a similar problem, probably they are struggling to find and eliminate bugs to the last minute, maybe that’s why the released macOS could change from the final beta.
This is a difficult problem but you are right, I think it need to be solved somehow in the future, for the sake of endusers.
When I think back to my MS DOS, Unix and Fortran days back in the early 1980s, the goal with OS development was to improve its existing actions, add key improvements and then make sure the code was succinct. Once Windows and OS X came on the scene, object-oriented programming mostly eliminated clean, clear, succinct code. The bloated code from hundreds of programmers melded together to create a new OS version that left a lot of open ended code and variables. It’s my opinion that this lack of creating succinct coding is what created an environment for malware of all types. It’s interesting that a Macintosh computer in the 80s could run, for example, detailed word processing using only a portion of 3.5" floppy disk yet today my macOS is over 3 GB in its dowloaded compressed form. My system sets aside about 20 GB just for the OS.
My point is if we had cleaner, smaller operating systems that went through the same rigors before being published as DOS did back in the day, we could probably begin validating software compatibility to updates/upgrades of the OS much, much quicker than what occurs these days. This laziness with coding an OS (my opinion) has, in the past, been laughed at simply because we have more disk storage and RAM for person computing than was even thought possible or practical back in the 80s. So, “we got more, let’s fill 'er up!” and “bigger is better” seems to be the modern approach.
Where would all the eye-candy come from? 
I think that would even be possible with cleaner code…
Has anyone tried Noteperformer 4.5 and NPPE on Tahoe?