Beach Ball and Sluggish Performance

I started using the BBCSO Pro template (with lots of my own additions) yesterday, and I have endless performance issues on a Mac Studio Max 64GB. I am using about 48GB of RAM and the CPU is averaging about 60% during playback. But every short while, I am met with a beach ball, and often the playback shortcuts don’t work. While using the editors, I find that I sometimes have to try to grab ahold of the velocity bars or the CC points many times (10) before anything happens.

I am wondering if there is just something wrong or whether I need to move all of my instruments to VePro. I tried to attach a diagnostic file, but it exceeds the size limit.

Thank you.

Edit: Using the latest Ventura

Hi @hittjett , please send the diagnostics directly to u dot stoermer at steinberg dot de. Thanks

I just sent it. Thanks!

Hm, but nothing has arrived so far on my side. I also checked my spam folder, nothing.
Can you please check again?

I have sent another copy. I’m off to bed now, but I will check first thing in the morning.

Now, finally, thanks.

As far as the audio engine is concerned, well, you are driving the system really to the edge. Your project is using 116 BBCSO and 9 Kontakt instances plus a few others. For each BBCSO instance Dorico’s audio engine creates 16 instrument channels and for each Kontakt instance 60 channels, so already this amounts to a total of around 2400 channels. Of course, most of them are not used, however, they get loaded into memory and need to be managed by the software, so this creates quite a bit of an overhead. So yes, as you already mentioned, using VEPro under such heavy configuration is certainly a good idea.
What I also noticed in the logs, the audio engine is trying to load 60 other instances of BBCSO but it fails to load them. It seems the setup information is incomplete, but I wonder how this half baked data ended up in the project file.


The periodic hold-ups you’re experiencing are probably due to auto-save, which is taking around 9 seconds. Part of this will be the saving of all of the VST plug-in state, and if you have 125+ VST plug-ins that’s quite a bit of state that needs to be requested and serialised. You can speed up saving a little bit for big projects by switching off the option to save a thumbnail preview, which you’ll find at the bottom of the File > Project Info dialog, though this won’t speed up auto-save.

Dorico is also logging out an enormous amount of information for many of the plug-ins that are not loaded. It’s trying to route sounds to most of the slots in the rack from 128 through 188 and failing to do so. It would be well worth removing as many of the plug-ins as you can from your rack.

Certainly using VE Pro in decoupled mode will greatly reduce the weight of your Dorico project, reduce the time it takes to save, and reduce the load on the audio engine. For a project of this kind of scale, I think it would be well worth the time and trouble to set it up.

1 Like

Thank you, guys! That was a big help. I suspected that this might be related to autosave, as it seemed to have that behavior, but I wasn’t certain because the behavior persisted even after the beach ball disappeared. Somehow, I created a big mess by importing XML to a separate flow, and it reloaded a whole bunch of BBCSO instruments. I have deleted these now. I will move most of my VSTs to VEPro to alleviate the system stress as well. Ordinarily, I would have begun in VEPro, but Dorico wouldn’t recognize it. I beat my head on this for quite a while and gave up. Finally, I realized that VEPro still isn’t Apple Silicon compatible. (WTAF?)

Finally, I realized that VEPro still isn’t Apple Silicon compatible.

Their FAQ says it works, although not “supported” yet.

I am not sure what they mean, but it will not show up in Dorico unless you run Dorico in Rosetta. There is a thread on VI-Control wherein the VSL rep says that AS compatibility isn’t expected before the end of January.