Dorico Freezes when opening and closing VSTs, including Noteperformer

Hi all,

I’ve encountered what seems to be a persistent and reproducible problem regarding Dorico and Noteperformer. After noticing it in one of my projects, I managed to re-create it in a fresh file using the steps below:

  1. Using Noteperformer for playback, add some instruments and hit the play button to ensure that the sounds are loaded by Noteperformer.
  2. Delete some instruments and add some new ones. Press play to ensure that the new instruments are loaded by Noteperfomer.
  3. On the Playback page, press the “Edit Instruments” button to open the Noteperformer Mixer window. The deleted instruments will still be present in the Noteperformer Mixer window.
  4. Close the Noteperformer Mixer window. Dorico will now freeze.
    Trying to fiddle with anything involving the playback engine – changing the default playback engine, trying to change the playback engine to something else, etc. – also leads to Dorico hanging.

I’ve tried re-installing both Dorico and Noteperformer without success, and I don’t know what else I can do. Hopefully, this issue isn’t a local one.

I have attached both the diagnostic and the test file for reference. I am using Noteperformer 4.40; I can provide other software/hardware specifications as needed. Any help would be greatly appreciated.

Thank you.
Dorico Diagnostics.zip (430.1 KB)
Test Project.dorico (567.8 KB)

Have you tried reassigning the NP Playback Template?
(Sorry to see you are experiencing this difficulty.)

Yes, I believe that’s expected. Deleting a Player/instrument from Dorico doesn’t remove it from the VST. It’s not really a problem, but as said: re-applying the Playback Template will empty the VST and re-load the required instruments.

I see you’re on Sonoma 14.4.1. There is a known issue with this build of macOS that causes freezing and kernel panics when accessing VST plug-ins. It is fixed in Sonoma 14.5. I don’t know if that’s quite what you’re reporting, but I’d certainly recommend it.

Thank you for your suggestion. I have tried it on both the test file and the original, and while re-assigning Noteperformer seemed to work on the test file, the action caused Dorico to freeze on the original file.

Here is the diagnostics report for the original file for reference.
There might be a lot of crash reports, as I have manually restarted the file every time it froze.

Dorico Diagnostics.zip (2.9 MB)

Thank you for your input. One would expect the VST re-apply automatically every time instrument selection is changed, so I do not understand why this isn’t the case – but I digress.

Pre-update, trying to re-apply the Playback Template froze both the test file and the original file. I have now updated my Mac to Sonoma 14.5, and while re-assigning works on the test file without problems, this action nevertheless freezes the original file upon pressing the “Apply and Close” action.

The diagnostics report for the original file is also attached in the above message, for reference.

Edit:
Oddly enough, saving the file also freezes Dorico. The file is also indicating a warning sign on the bottom right (normally where the green circle would be); clicking on it brings up the message “Dorico cannot connect to the audio engine; Dorico will now quit,” or something to that effect.

I’ve tried to get the music off the corrupt file and onto a fresh one, but any action seems to freeze Dorico. Changing playback templates causes Dorico to freeze. Exporting MusicMXL causes Dorico to freeze. Heck, swapping between two Dorico sessions (with the corrupt session active) causes Dorico to freeze. At this point, if anyone could help me get the note data off of the corrupt file, I’d be grateful, as I would rather not re-input and re-format everything all over again.

Edit:
I managed to get the data off via .mxl export. Although the action caused Dorico to hang, it turns out it still exported it successfully? It might have completed the action when I force closed it, maybe. Still, I would like to know what the issue was with the original file (if any) to avoid taking actions like it in the future.

Ok, so it seems like regardless of the file, if I go to the Play menu, click on “Edit Instrument,” close the Noteperformer Mixer window, and try to perform another action (e.g. re-open the mixer, move to another edit window), it causes Dorico to freeze. I don’t know anymore at this point. The icon on the bottom right doesn’t even show up anymore. Any help would be appreciated.

Anyway, here’s the latest diagnostic file.

Sent via wetransfer because of the 4 MB file upload limit.

Sorry to hear about this problem. Your diagnostic report certainly does include a large number of hangs. It looks like Apple have helpfully changed some internal data in the way these reports are generated, as the tool I use to restore the debug symbols into them isn’t able to work with them. I’ll need some help from a colleague after the long holiday weekend to be able to provide some more insights here, unfortunately.

In the meantime, do you find that if you use one of Dorico’s default playback templates, i.e. not using NotePerformer, that the application still hangs if you e.g. show the HALion window and then close it again? (Be sure you only try this if you have definitely updated to Sonoma 14.5, as showing the HALion window in Sonoma 14.4 or 14.4.1 will cause your Mac to kernel panic and restart, due to an OS bug fixed by Apple in 14.5.)

Thank you for your response. No problem regarding the timeline; I appreciate the help all the same.

As for changing the default playback engine, it still results in a hang if I open the HALion window (via the ‘Edit Instrument’ button), close it, and try to perform another action. I tried this process twice with different HALion sound libraries, so the problem doesn’t seem to be something with Noteperformer, at least.

Anyway, here’s the latest diagnostic report:

Let me know if you or your team needs anything else, and I look forward to any insights you might find.

All the best.

Could you please reproduce the problem once more, then use Activity Monitor to create a spindump?

The spindump should allow us to see what the audio engine is doing as well as what Dorico itself is doing when it hangs. Please zip up and attach the spindump here.

Of course; I opened the Activity Monitor, opened Dorico, reproduced the problem, force-quit Dorico, and then generated the spindump. I hope I did it correctly. Let me know otherwise.

Here’s the Spindump:
Spindump 5-27.zip (632.9 KB)

Ulf and I have been discussing your case today, and we now at least understand what is happening. However, we don’t know why it’s happening, so we are going to need some more assistance from you.

Somehow, when close the VST plug-in window, you are managing to quit the audio engine process. It’s not crashing: it is acting as if you have managed to tell it to terminate cleanly, as if it were a regular application running on your computer and you have closed it by typing Command-Q or choosing File > Quit. Of course, the audio engine doesn’t respond to Command-Q, and nor can you quit it via its menus, but there must be something you’re doing that is causing the audio engine to quit.

So we need some more assistance from you to further dig into what’s happening here. How are you closing the VST instrument window? Can you perhaps make a screen recording that shows exactly what steps you’re taking?

Hi Daniel, I have made the screen recording of the process; hopefully, it is illuminative. Is there an email address I could send this to?

Hi Daniel, I have figured out the cause of the problem. I had previously installed a program called “RedQuits” that terminates any program—as if by typing Command-Q—when the red “x” button on the top-left of any application window is pressed. (This was to emulate the WindowsOS functionality—I installed it when I first switched from Windows to Mac.)

Since the VST plug-in window has those three window buttons, I can only assume the RedQuits program activated once the “x” button was pressed and proceeded to terminate the audio engine. Sure enough, once I had deactivated the RedQuits program, the problem ceased.

I feel a bit silly now for not having made this correlation until it was pointed out to me. Thank you all for your help, and I sincerely apologize to both you and Ulf for the trouble I have caused.

Hopefully, this thread will serve as a warning (albeit niche) to consider if a third-party program might be the cause of a performance issue.

1 Like

Great news – I’m glad we were between us able to get to the bottom of the problem.

1 Like