New post
Avatar
0

Dear Finale Friends!

Is anyone else getting annoyed at Finale's Error Code: 7 (Finale's Audio Engine Failed To Load) message you get every time the computer wakes up from sleep?

It even forces Logic Pro to go into recovery mode. And it is a problem for years.

Finale support knows about it, FOR YEARS!

Did anybody find a way to make this error message go away for good?

Makemusic, PLEASE! My College student's use this as a great example for how buggy Finale is! You want that? An other reason for them not to buy it. COME ON GUYS! Maybe 2024 is the year?

23 comments

Date Votes
Avatar
2

Few of us experience this — in 35 years, I've never seen it on any of my Macs. It has been seen on this board over the years. You can search these pages for Code 7 and  -7. You'll see many issues and solutions. One or more may apply to you.

 

Code 7 is a macOS notification that something can't be found or that you don't have access to ???. What and why are not always specified. I can guess for a page or more but, without more information from you, that's all I am doing. .

https://makemusic.zendesk.com/hc/en-us/community/posts/215729367-General-Discussion-House-Rules 

 

Is everything installed in the default location on your System drive?

 

My College student's use this as a great example for how buggy Finale is!

 

Are you using a University site license? Are you accessing this from something akin to a Citrix Server? Again, we need more information.

 

You want that? 

 

We are a users group. None of us work for MakeMusic. Support for Finale 27 is accessed through the Submit a request link at the top of the page.

Comment actions Permalink
Avatar
0

Finale runs normal, no error messages, I am running the newest Finale, the newest Mac OS, on a PowerBook M1 14 inc. The Code 7 Error only appears after the Mac wakes up from sleep. I had this happen on my old iMac already years ago. The Finale guys also knows about this for years. Obviously they don’t care to fix it. I was just wondering how other people feel about it. Thanks for your responds. Happy New Year!

Comment actions Permalink
Avatar
1

I do not let my computer go to sleep with music software (or much of any software) running. I know some do and never have any trouble with it, but for me the risk is not worth it.

Comment actions Permalink
Avatar
0

You didn’t answer my questions.

Are you trying to get this solved or just complain?

Comment actions Permalink
Avatar
1

I do not let my computer go to sleep with music software (or much of any software) running. I know some do and never have any trouble with it, but for me the risk is not worth it.

 

That's a complicated issue on Macs and not possible on the portables. In any case, I have a number of Macs in use from 2012 to M1, M2 and M4 Apple Silicon MacBooks and Studio and have never experienced this. If he won't tell us what we need to know, then there's nothing we can do.

Comment actions Permalink
Avatar
1
Comment actions Permalink
Avatar
1

So I suspect it is hardwired into the Mac.

 

Huh?

 

Error 7 / -7 is an OS message saying that a resource or file cannot be found. That's what it is, David. It has nothing to do with any specific application and never has. A common cause is an external drive where you have files or libraries stored not waking up from sleep. The other common cause, especially with Windows, is that an installation or update will corrupt a path—the data is still there but your PC no longer finds it. Increasingly rare is when a file is loaded from an external where you have Read Only permissions or a CD where that's impossible—Finale always writes to the data drive and, when it can't, 7 may be generated.

 

Many of use do not use USB 2/3 external drives for this reason—they sometimes don't wake from sleep. My data drives are connected over Thunderbolt/USB 4 nowadays (SATA and eSATA before that and SCSI going back to my Mac Plus) and my backup drives are connected over WiFi and Ethernet.

Comment actions Permalink
Avatar
-2

Thanks to everyone chiming in.
The only application that has consistently produced this error code after waking up on any of my Macs is Finale. This issue has persisted for many years, even after reinstalling the software from scratch. I have also reported this to Support may times. Now it's all water under the bridge. Finale won't get an upgrade anymore, so I'm closing this discussion. By the way, I'm already using Dorico, and I'm quite happy with it, especially because after waking up, there is no error code! CHEERS!

Comment actions Permalink
Avatar
-2

It also happens in Dorico, and the brainiacs in charge of Dorico acknowledge this as a known Mac problem - it also happens on Apple silicon not just Intel. And it happens to luminaries - Tim Davies has even written (music) about it. Connected devices may (or may not) be involved, according to posts on one DAW blog I frequent, and be hit by this as well. It seems to be idiopathic, and intermittent so I wonder whether it may be something on the chipset, not MacOS. Many (or most?) don't seem to have been hit by it. My best advice is quit all your music apps before closing shop for the day. This, I can aver, works. (Actually, I am amazed that any of this works at all, never mind as well as it does.)

https://www.timusic.net/debreved/error-code-7-a-deep-dive-part-1/

Comment actions Permalink
Avatar
0

I had this "Finale's Audio Engine Failed To Load" also frequently in the past months, especially since I bought a new M2 MacMini recently. The problem goes away after a while or after restarting the app, so this has probably to do indeed with USB drives involved although none of the "folders where Finale will look for or write " are on external drives.

Comment actions Permalink
Avatar
2

Are any of your libraries on external drives? Finale is looking for those, too, as is Dorico upon start up.

 

External NVMe drives connected via USB4(TB3/4) are the fastest available and do not have the wake from sleep issues that plague USB 2/3. The new Mini M4 Pro supports USB 4.2(TB5). External drives have been announced but I’ve not seen any shipping yet.

 

My keyboard and interfaces connect directly. Sleep issues only happen with drives and hubs.

 

My other USB 2 external is my iLok and it gives the “not found” error every few weeks, causing me to unplug/replug so that my Studio M2 Ultra can see it again.

 

As I posted last year, I have never seen -7 or 7 on any of my own Macs going back to my Plus in 1986. I have diagnosed it on over a hundred client machines over the decades and many, many apps. I also saw it a lot when I was supporting Windows between 1996–2009..

Comment actions Permalink
Avatar
-2

I suppose I could go out and spend a couple thousand on new gear just to get some ports or a larger internal drive. But I live in the real world and simply shut down my applications when I close the studio for the night. So much cheaper - and 100% reliable. Now back to writing music, not shopping for gear - that will come in due time.

Comment actions Permalink
Avatar
-1

New gear won't help.  This has nothing to do with files.  It's 100% reproducible on my M1 Max MBP with no external devices.

This specific bug appears to be caused by Apple removing hacks that used to hide audio device disappearance and reappearance during sleep-wake cycles and other state changes, and Finale not getting properly updated to handling disappearance of the audio device gracefully.  When Finale sees the order of input and output devices change unexpectedly, it explodes in flames.

IIRC, these bugs started happening when Apple changed their hardware and driver stack so that the internal speakers and headphone jack behave as multiple independent devices instead of as a single logical unit whose name changes from speakers to headphones when you plug in headphones.

This bug appears to be massively exacerbated by having virtual audio devices, because Finale seems to default to the first device it sees, and that *used* to always be the internal hardware, but when you have virtual audio devices such as Virtual Desktop Mic, ZoomAudioDevice, NDI Audio, etc., it ends up trying to switch to one of those, because they are there and the built-in hardware isn't.  And if those don't support the current sample rate or have a different number of channels or whatever, Finale gets very, very unhappy.

If I remove all virtual audio device plug-ins from /Library/Audio/Plug-Ins/HAL and reboot, I no longer get the error -7 on sleep/wake.  For now, I'm doing just that to avoid this bug, because I don't use those very often.

In an ideal world, Finale should handle these problems by waiting about two or three seconds and then reinitializing the audio engine, giving up and throwing an error only if that fails to work several times in a row, or better, mark its audio engine as being not ready, then try to reinitialize everything the next time you hit play or do something else that causes sound to be produced.

Unfortunately, CoreAudio is a low-level C API, and all of the Finale code that works with it seems to be C++, so there's also no good way to swizzle this.  It *might* be possible to do some sort of dyld interposing between Finale and the CoreAudio or AudioUnit code to fix this, returning a fixed set of devices and mapping them onto the real devices on the fly, stopping the AudioUnit graph on sleep and restarting it on wake, and all the other stuff Finale should be doing but probably isn't.

Comment actions Permalink
Avatar
-1

Spoke too soon.  With headphones plugged in, the error -7 happens on sleep/wake.  It did not occur for me when using the internal speakers.  😂

 

Comment actions Permalink
Avatar
-1

David, you really know your stuff. Here’s my conclusion: MakeMusic has been aware of this problem for many years. Instead of taking it as a sign that it was time to modernize Finale—updating the outdated code, improving the interface, and making Finale the flagship of music notation once again—they chose to continue as they were, trying to extract as much money as they could until the very end. This reflects poor management, greed, and incompetence. On top of that, it feels like a slap in the face to all of us loyal users who stuck with the software despite everything. It's a pity.

Comment actions Permalink
Avatar
-2

No question about it.  My suspicion is that MakeMusic had no senior Mac programmers on their staff — only a few coders who knew enough Objective-C and C and maybe C++ to mess with the existing code as long as it was just feature work that didn't require deep understanding of the way the operating system worked.

There's also a nasty crash that for some people occurs with alarming regularity in their view management code.  I could trigger it just by opening certain files, clicking in a note in the right spot, and hitting the delete key.  I managed to fix it with a custom plug-in that swizzles their Objective-C code:

https://github.com/dgatwood/finalehacks

The error in their architecture was instantly obvious to me the second I read through the backtrace.  I literally didn't even need to see their code to know what they did wrong.  It was obvious just from the symbol names in the backtrace.  But to a junior engineer who doesn't understand how macOS does view management, it would seem like an absolutely impenetrable bug in the operating system, rather than illegal reentrancy.

And Robert Patterson just contributed another workaround to that code base for a longstanding bug related to view management.

At some point, I hope to figure out a way to work around the annoying -7 errors, too, but that will be a lot harder without access to the source code, and I'm not 100% sure it is even possible, but I *think* it can be done with linker interposing tricks.

Either way, this one is in the territory where I'll actually have to learn a lot of details about the low-level guts of Apple's linker as I go, because fixing this goes beyond the level of hackery that I've ever even considered employing in production code.

What bugs me the most is that I could probably have fixed the -7 bug in minutes if MakeMusic had just released their source code.  Instead, I'm wasting hours trying to figure out how to interpose the CoreAudio libraries, and *if* I can even pull that much off, then I'll end up creating wrapper libraries to fake CoreAudio object stability, so Finale thinks that it has exactly one audio device that just happens to map onto the system audio device (by default, maybe with some configurability eventually, assuming it works) and suspends the audio queue callbacks during sleep/wake correctly, etc.

So I'm not going to mince words and say anything even slightly positive about the way the company treated Finale.  Some of these bugs have been around since Finale 25, MakeMusic told people to do things that maybe occasionally helped, rather than hiring engineers or contractors with the skills to fix it correctly.  These workarounds are just crude hacks.  If I'm able to put together a workaround for the -7 bug, I'll have a lot more confidence in the ability to work around future Apple changes and keep the software running in future macOS versions without source code access.  If not, then the best we can hope for is getting it robust enough to reliably work in a VM that exposes only a single audio pass-through device, which I guess is better than nothing, but seriously annoying.

Either way, this is just another shining example of why private equity is almost always a bad thing.

Comment actions Permalink
Avatar
2

It's 100% reproducible on my M1 Max MBP with no external devices.

 

If you can reproduce it on demand, then set up a Support call with Apple. They will screen share, observe 7 and then show you where the log is and how to upload it. Then you can tell us what it is really.

 

"App Nap" is not a thing with regards to Error 7 and never has been. A senior Apple engineer could tell you that but at least one has and you don't believe it. Per Apple:

a power-saving feature in macOS that puts inactive applications into a paused state to help conserve battery life

  • To turn off App Nap for an individual application, you can:
     
  • Find the app in Finder 
     
  • Right-click on the app 
     
  • Select Get Info 
     
  • Check the box that says Prevent App Nap 
     
  • You can also turn Power Nap on or off for a Mac desktop computer by going to Apple menu > System Settings, then clicking Energy in the sidebar

 

Apple's standard response is correct. Not believing this doesn't change the fact that it is true.

On macOS, "error 7" generally indicates a problem with disk access or a corrupted file system, often stemming from a damaged hard drive or issues with file permissions, though the exact cause can vary depending on the context where the error appears; sometimes it can even be related to incorrect system time settings in certain applications

Comment actions Permalink
Avatar
0

Yeah, it's trivially reproducible.  Add some virtual audio interfaces, set audio output to any interface, launch Finale, put your computer to sleep, and wake it up.  Or unplug your headphones while Finale is running.  Or create a new aggregate audio device.  There are probably lots of other fun ways to trigger it, but those are the easy ones.

I'm not sure where you found that information about corrupted filesystems, but I'm 99.99999% sure that's not at all correct (though apparently that code might be plausible for a filesystem issue on Windows).

To the best of my knowledge, neither error 7 nor error -7 occurs in any standard macOS error code list except in two very narrow contexts:

7: E2BIG — the UNIX error code for argument list too long, which can only occur when launching an external tool.

-7: dsPrivErr — the legacy Carbon API error code for permission denied.  Note that all APIs that returned this value should no longer exist in 10.15 and later.

These are not the droids you're looking for.

Error codes for I/O Kit (including most disk errors) are much larger numbers and should always be presented in hex, because the subsystem identifier is encoded as part of the error code number.  For example, USB error codes look like 0xe0004xxx, where xxx is the three-digit hexadecimal error code.  This can't even be the result of stripping the I/O Kit family code off of an I/O Kit error message unless the error is kIOFireWireChannelActive, which obviously isn't the case unless you're using some really OLD audio hardware.  So it isn't a driver-level error code, period.

Error code 7 also isn't any error code returned by any audio-related subsystem in macOS, nor is -7.  (I even tried two's complement in hex.)

In other words, this error code 7/-7 is almost certainly an internal Finale error code that means nothing to anyone other than the MakeMusic engineers who wrote the code.

Here are your logs, FYI:

default 20:19:43.450454-0600 Finale  HALC_ProxyIOContext.cpp:3069   HALC_IOContext_ResumeIO(1616)

default 20:19:43.457000-0600 Finale  HALC_ProxyIOContext.cpp:3035   HALC_IOContext_PauseIO(1616)

default 20:19:43.457001-0600 Finale  HALC_ProxyIOContext.cpp:1002   HALC_ProxyIOContext::ResumeIO: -> 0 0 0 id:1616 called from <private>

default 20:19:43.457055-0600 Finale  HALC_ProxyIOContext.cpp:1019   HALC_ProxyIOContext::ResumeIO: <- 0 0 0 id:1616 called from <private>

default 20:19:43.457077-0600 Finale  HALC_ProxyIOContext.cpp:955    HALC_ProxyIOContext::PauseIO: -> 0 0 0, id:1616 called from <private>

default 20:19:43.457094-0600 Finale  HALC_ProxyIOContext.cpp:968    HALC_ProxyIOContext::PauseIO: <- 0 1 1, id:1616 called from <private>

default 20:19:43.464329-0600 Finale  HALC_ProxyIOContext.cpp:3069   HALC_IOContext_ResumeIO(1616)

default 20:19:43.464390-0600 Finale  HALC_ProxyIOContext.cpp:1002   HALC_ProxyIOContext::ResumeIO: -> 0 1 1 id:1616 called from <private>

default 20:19:43.464416-0600 Finale  HALC_ProxyIOContext.cpp:1019   HALC_ProxyIOContext::ResumeIO: <- 0 0 0 id:1616 called from <private>

default 20:19:43.464504-0600 Finale  HALC_ProxyIOContext.cpp:3069   HALC_IOContext_ResumeIO(1632)

default 20:19:43.464580-0600 Finale  HALC_ProxyIOContext.cpp:1002   HALC_ProxyIOContext::ResumeIO: -> 0 0 0 id:1632 called from <private>

default 20:19:43.464605-0600 Finale  HALC_ProxyIOContext.cpp:1019   HALC_ProxyIOContext::ResumeIO: <- 0 0 0 id:1632 called from <private>

As I said before, the proxy I/O object in the Core Audio HAL (hardware abstraction layer) is failing to restart, which means the proxy is no longer valid, likely because the device went away and came back (or didn't), so the other end of whatever USB device interface or other user-kernel RPC mechanism no longer exists.

It's unclear whether this is a bug in Finale or in macOS or both, but my money is on Finale, because I haven't seen any other audio-related apps behave this way.

Finale does something very buggy with respect to trying to force settings like sample rate back to their original values when they get changed externally, so this could be related.

The really annoying thing is that I can't find any way to force Finale to try again once it fails.  It is like the AU graph stops working, but still issues errors, and even menu items that should tear it down and recreating it still end up referencing the stale audio device reference.

So I'm thinking the right fix is to add code between Finale and the AudioToolbox framework that lies to Finale, deleting and adding new output units into the Audio Unit graph under its nose to mask changes in interface availability, substituting a null output unit when no output unit is available, and silently stopping and starting the graph whenever interface availability changes.  Or maybe even do something more radical, like replacing the audio output unit with an AUNetSend instance and having an external binary that handles CoreAudio correctly and plumbs the AUNetReceive to a user-selected output device.

Either way, the key is going to be interposing those C and C++ calls.  More when I get it working (or don't).

 

Comment actions Permalink
Avatar
0

It's unclear whether this is a bug in Finale or in macOS or both, but my money is on Finale, because I haven't seen any other audio-related apps behave this way.

 

I'll take that bet.

 

My daughter stopped by for a few days on her way to teach some classes at Cal Arts tomorrow — if the fires don't close the campus. She had a Finale project on her laptop—it went to sleep as we were talking and when she woke it up, there it was:

 

"Error 7

Finale's Audio Engine Failed To Load"

 

First time I've seen it in person (with Finale, Adobe, MOTU, Logic and a few others over the years, yes). After dinner, I took a look and had it fixed—took me five minutes.

 

Here's what I found: When in Finale, her Audio Output was either her internal speakers or BT earbuds. However, when her M3 MacBook Pro woke from sleep, her Audio Out had changed to Microsoft Teams Audio. So, Error 7 was right that the app was looking for a resource it couldn't find, in this case, the expected Audio Out. In fact, conflicts with Microsoft Teams Audio drivers, Mac & Win causing problems with audio are very well known. Do a Google search on "microsoft teams crashes audio driver". Not a Finale bug. No doubt the macOS should handle this better but I'm not sure it's an Apple bug either.

 

The Mac's Finder/File and Spotlight often do not find what one is looking for. I downloaded a shareware utility, Find Any File, asked it to find teams audio and it pulled up the drivers. Moved them to the Trash, deleted the rest of Microsoft Teams and emptied the Trash. Spent hours testing and the problem is gone. When an Office app is purged from the system, Microsoft updaters will not attempt to reinstall.

 

Find Any File is $6 from the developer; $8 in the App Store. Like any real shareware app, it is fully functional but registering makes the nag screen go away. If purchased from the App Store, one is notified automatically of any updates—worth the extra $2 IMO.

https://findanyfile.app/ 

There are similar utilities out there but this is the one that I prefer.

 

I've little doubt that there are other audio drivers that can cause this but I have ten–eleven output devices without the problem while my daughter had only three—only one was not built into her Mac and it's gone now. I probably should have grabbed some screen shots but I didn't expect to find and fix this so easily. I am not reinstalling Teams just to get a picture.

 

Again, Error 7 is an oldie that I first spotted on my Mac+ 39 years ago. It does not have to do with the Audio Engine at all.

 

 

Comment actions Permalink
Avatar
0

I am impressed with how knowledgeable you all are about the intricacies of coding. However, to me, only one thing matters: Finale is the only audio program that has ever produced Error Code 7 on my Mac. For instance, when Logic Pro can't find the previously connected interface, it clearly shows a dialog box that states: "Previous audio interface is no longer available." There, I am given two options: a) Open audio settings, or b) Cancel. That is how error handling should be done.

An error code like Code 7 is outdated—it's reminiscent of systems from 1995. This indicates that the developers at Finale have not made an effort to modernize their code in years. Additionally, I've never encountered this message in Dorico, which leads me to believe that the issue is not with Apple.

Comment actions Permalink
Avatar
1

I've never encountered this message in Dorico,

 

If you read the whole thread, you’ll see that others have.

 

As to what needs to be fixed in Finale, that will never happen. It’s dead and done. But since this is an Apple issue caused by conflicts, there’s nothing for MM to fix.

Comment actions Permalink
Avatar
0

Depends on what's wrong.  There's a decent chance that there's an Apple bug under the hood, but if as I suspect, it was an intentional power management decision, they may not be willing to change it.

 

What I seem to recall is that macOS no longer does magic tricks to mask the disappearance and reappearance of devices during sleep-wake cycles, and apps are expected to recognize when this happens and rebuild the audio graph from scratch when they get errors indicating that the device has gone away, waiting for the correct device to come back into existence if necessary.

 

When the computer wakes from sleep, CoreAudio outputs start to reappear, but because USB devices that are non-critical (i.e. everything but storage devices) are not kept powered during sleep and because macOS does not have any notion of deterministic ordering of device enumeration, they come back in a different order.

 

If Finale is expecting the index returned by iterating the possible audio devices to be the same, or the order to remain the same, things will go very wrong, and it will end up talking to the wrong device.  The only way to robustly identify a device is with a UUID.

 

My strong suspicion is that Finale is not using the UUID.

 

Unfortunately, without access to the Plogue Engine plug-in code (all of Finale's CoreAudio integration is actually in a plug-in written by an outside company), a lot of this is speculation.  If Plogue Art et Technologie, Inc. would be willing to release the source code for that plug-in, we could fix the bug in minutes, in all likelihood, or at the very least, work around it creatively.

 

Or it would theoretically be possible to reverse-engineer the API boundaries between the plug-in and Finale and write a new plug-in from scratch that matches the API.

 

Or we could do what I was planning to do, which is work around it by adding a wrapper layer between the OS and Finale that keeps the interface order and count stable, using a proxy object that changes what underlying OS object it points to, and silently swapping out the audio device object under Finale's nose, discarding or delaying messages while the underlying OS object is unavailable, etc.

 

I should probably reach out to Plogue.  Now that I see that it all lives in a plug-in, that might be a simpler approach, if they are willing to do it (and if they don't have licensing agreements with MakeMusic that prevent them from doing so).

 

Comment actions Permalink
Avatar
0

My daughter’s Mac did not have any peripherals connected when I observed, diagnosed and fixed her problem.

 

I have up to six USB and TB devices connected, all of which can receive Audio Out and have never encountered this on any of my Macs. I can post screen shots if needed. There are some virtual devices in addition. Finale has never been confused — if it was a bug, I should have seen it at least once in the last 35 years.

 

The Dorico and Digital Performer boards complain about this now and then. Again, though I have had both apps for many years (Dorico since v.2 and DP since v.2.7), I have yet to experience it on any of my machines. Error 7, many years ago going to my Mac+ and hard drive problems, yes but with Audio Engine…, not once not ever.

Comment actions Permalink

Please sign in to leave a comment.