It’s not about blame but getting things reliably working.
VST’s are dynamically loaded libraries. (sorry, don’t mean to over ‘splain) but they are sort of the coding equivalent of inviting a bunch of strangers to come live in your home and share a bathroom. Maybe towels and toothbrushes - if you’ll allow the analogy that some of these DLL will likely then load and share other common libraries.
I’m not even saying one is dodgy. I’m saying it can matter the order in which they happen to be loaded - It can matter the order in which THEY load things - like which version of a shared lib gets used. So It’s not only about who else lives there but who gets up first in the morning, and I dunno maybe takes the last piece of toast. And when you have more of them living under the same roof than pieces on a chess board, the number of possible combinations and interactions IS problematic. From our own unique choices.
And we haven’t even gotten to the issue of putting the toilet seat down. One of the difficulties I remember with them is when certain errors occur it can be next to impossible to unwind the stack - to unload everything cleanly.
For the record I’ve broken more than one of version of Reaper, and right now VEP is apparently permanently locked up trying to yep scan VST.
I’ve never been so lucky, but I’m told some bigger studios pay someone to work out and tune these kinds of issues- when templates get truly big. One of those individuals , who appears well known and respected, claims that the cubase/ vst engine is one of the very best for that purpose, and while Reaper starts strong and is great to a certain point, it is essentially unworkable beyond what he would consider a medium-ish template.
I don’t mean to dismiss the suggestion of a bug.
The point is, someone is only torturing themselves by not heeding advice about moving and diagnosing VST such as Leo gave.
Hopefully these come across as the words of a friend, who takes a bit of risk in hitting send.
No need for apologies Ulf! I can tell you are working very hard to deal with the repercussions of how the audio engine has been scripted. I just think Dorico needs to hire a plumber here to deal with the leaky pipes.
This issues goes back to 2016 and has obviously caused many headaches in that time. I am positive there is a solution that Dorico can implement to keep this from occurring, and would save a lot of time for all of us.
In aggregate, I wonder how much time has been spent by users on just this issue alone. Dorico is not the only program that has to manage interoperability with other software, and in fact it is quite common now, but Dorico does stand out as being peculiarly problematic here.
I started on Finale in '99 and Cubase and Reason in '01, and in that time since I have not seen any other program that has to struggle this much just to open properly.
In terms of plugins, I only use 1 in Dorico: Noteperformer. The rest of time I am just sending all of the instrument playback to MIDI out ports. That’s it. No other VSTis or audio plugins are being used when I am working in Dorico. I think it is entirely reasonable to expect that Dorico can work in those conditions right out of the box without user troubleshooting.
This issue has been extant for 8 years now. It’s about time to fix it rather than deal with the hours upon hours of one-on-one support. It’s a matter of efficiency for everyone involved to save time and money in the long run. It also reflects pretty poorly on a software company when newbies can’t even get the program to open without opening a support ticket, which, judging by the amount of posts on this topic overall, is a relatively frequent occurrence.
I’m not dismissing it. Of course you can try to fix something that was broken when you bought it. You can sew up loose hem on a garment or attach a handle that came off. But the point is that as part of the service that is agreed upon when purchasing such a product is a reasonable basal expectation of fitness: i.e. that it “works”.
And this is not just about me. This is about taking note of just how many people have had this issue and how much time is being spent on something that has clearly been solved by many other software companies (a task such as scanning for and initializing VSTs). If it really were just me or just a handful, I would not be making a post like this.
I’m aware it’s not the only thing on his plate - but it’s undeniable that this error message gets posted about on the forums several times a week, enough to say, “hey, that seems like it’s happening frequently, for a lot of people…”
I see the point you are raising, but this does not explain why I have never had any audio engine initialization issues using the same VSTs on the same machine with my many other music applications which all connect to the same exact VSTs installed on the same machine (yes, I have a lot!):
VEPro, Cubase, Nuendo, Pro Tools, Logic (although this uses AUs), Ableton Live, MuseScore, Sibelius, Izotope RX (audio editor)
I also use several video applications in which I utilize VSTs for audio sweetening, including Adobe Premiere and After Effects
None of the above have ever given me this particular audio engine connection issue, not even once across years. Whereas Dorico gives me this issue a few times a week.
And again, you look around at the forums and see others mention the same issue, over and over. We can point to VSTs all day but if all other apps are handling them fine, it’s hard to deny that the onus might actually be on Dorico…
And I say this all in good faith and love for Dorico, as a devoted and happy user simply wishing for it to become even better than it already is, and for the sake of its reputation! Like I said, I don’t really experience issues crashing once it’s open, which I will honestly admit cannot be said about many of those apps listed above (Pro Tools loves a good crash!). So Dorico certainly has stability going for it in my opinion. Once it’s open, it’s solid for me, working all day and throwing a lot of things at it.
@VV1, have you actually generated and sent a diagnostic report?
It only takes a few seconds and will benefit not just you but possibly other users, too.
Sometimes it takes a couple of little steps to fix something.
Just want to add my voice to this discussion as a Dorico user and fan from the start - I’m on a fresh Mac OS install: Sonoma 14.6.1 with a fresh install of Dorico. I get this ‘Continue to Wait’ every single time I boot up Dorico for the first time each day - if I quit and then reboot Dorico for any reason later in the day, it tends to works perfectly, without this hiccup. I just live with it and simply hit ‘Yes - continue to wait’, and the hub appears a few seconds later.
As others have pointed out, no other audio program has this problem, (On my system that includes Pro Tools, Cubase, Audiofinder…They all scan the plugins folder) and if it is a VST, well, I don’t really want to forfeit one of my plugins just to stop this behavior. As I say, I can work with it like this, and I can report that Dorico is extremely stable once it’s up and running, but there must be some sort of underlying issue.
The Audio Engine might actually have the same problem with the same VST that VEP experienced. The difference is that VEP is telling me what was scanned and which one it is stuck on, whereas the Audio Engine sorta leaves Dorico in the dark I think.
I see your point. And I’m not dismissing the problem being reported at all. I might differ with you (strongly even) about what is reasonable to expect in this sort of ecosystem, But mostly I’m saying in a pragmatic way, that to get and keep things working…
I knew the change that I made earlier. (I didn’t really need VEP to tell me ) I keep my VST directories clean and limited to what I use. Not like the drawer from hell in my kitchen. I don’t have the sort of issues you describe . Could be luck, pretty sure it’s not my looks or clean living.
I remain utterly baffled by this approach. This is typically NOT how one solves software problems. It’s usually far more efficient to root cause the problem than firefight one user at a time.
This is a Steinberg technology on a Steinberg platform, that does not manifest on ALL other Steinberg products.
Until the team can actually find a fix for the various issues that happen on various machines, he is trying to help users as soon as he can with the limited time that he has.
Yes, and while correlation does not necessarily imply causation, it’s hard to ignore the fact that it comes up very frequently across these forums for many users, and on my own machine it happens with a frequency that I joke to myself that Dorico error, again! - because this error message is kind of a signature staple of Dorico, in ways I’ve never seen with any other software. So even if it’s technically incorrect, you can imagine it’s hard for users not to figure there must be some kind of correlation/causation going on, especially when Steinberg’s own Cubase on the same machine has no issues in this department.
Sorry, I speak of knowledge of 40 years in engineering. If one person is working inefficiently, then it drags everyone down. Further, if someone had been working full time on this problem, then we wouldn’t be 5 years down the line with no solution in sight.
Though given the public nature of this project, it’s often helpful for the vendor to keep doing what they’re doing, getting the same poor results they always get when fan boys from outside the organization cheer them from the rafters for reasons that defy logic. It really means they don’t have tov fix anything, because there’s always a ton of people here who confirm that they’re doing a simply incredible job, despite the evidence to the contrary.
In the meantime, the rest of us who are kindly beta testing this software for years at a time and providing hundreds of dollars for the privilege can go hang.
But yes, carry on. There’s really no point at all in coming up with a rational solution when they’re are just so many people on this forum willing to cheer on such gross ineptitude.
One of the big differences between Dorico (where you see this error) and Cubase and Nuendo (where you do not) is in Dorico, the audio engine (based on the Cubase audio engine) is a separate program that Dorico communicates with. In the case of Cubase and Nuendo, the audio engine is part of the main program itself.
I’m not entirely sure of the reasons why this is done, but I suspect this design has a disadvantage of making it harder to see error messages and warnings that Cubase or Nuendo would display on the startup screen and would normally pop up in front of the user. In Dorico, because the audio engine is a separate background application and separate from the Dorico main program in the foreground, these errors or warnings can show up behind other windows, or not display at all, and then Dorico is left hanging and is not sure why the audio engine hasn’t fully started yet and you get that message being displayed.
Additionally, it seems as though Dorico can’t really communicate with the audio engine at all until it has fully started. It launches it blindly, and sits there hoping it will start up, and has a preset timer to give the user the ability to kill the process if it is taking too long (without knowing whether there is an actual problem, or it is just taking longer for some reason). Cubase/Nuendo seem to be less in the dark about their audio engine status, perhaps it is easier to view the status when it is a single process instead of two different processes.
Except I think we’re too often like patients that my doctor talks about, too focused on what we read or heard and not enough on what the qualified person is saying who’s holding our chart and actually went to medical school . like we want to hold the scalpel ourselves, and I’m dying to watch the guy who tries to be his own anesthesiologist.
I include myself sometimes.
If anyone at Steinberg needed something more from us, they would ask. They have more than earned our trust IMO. So what I’m left with is - how can I help you for right now? What am I doing or not doing that’s different maybe? I know of some things posted here that helped others. That is where my head goes.
As I would hope you can agree, one can be grateful for an individual fellow human being’s efforts without necessarily being a mindless cheerleader for a product.
The trouble is, not all of us have “this” problem. As I’m sure you can appreciate as an experienced engineer, that makes diagnosis more challenging,
Please, shouting with exclamation marks and making demands to fix is not proper etiquette, and won’t get anything fixed. Have some respect for the forum, and the dedicated Steinberg engineers.
There are many capable people here who will willingly help. As suggested, supply a diagnostic report and things can be moved along.
Most likely a process of step by step elimination of VST’s will be very helpful. In this respect I am saying nothing new.
Full details of your current platforms, OS release, and so on would be helpful.
In an attempt to be of some small help, are you aware of System Informer, a free Windows tool for examining processes? It can be very useful in cases like this.
Interesting. That is a helpful explanation, and it does indeed elucidate why the behavior is different from other applications where it is not occuring. Thanks!
Like I said, I don’t really experience issues crashing once it’s open, which I will honestly admit cannot be said about many of those apps listed above (Pro Tools loves a good crash!). So Dorico certainly has stability going for it in my opinion. Once it’s open, it’s solid for me, working all day and throwing a lot of things at it. 
