That’s interesting!
Mind you, on my video I’m not even inserting the notes via midi keyboard, but rather using the computer keyboard.
The crashes are an OpenGL driver problem in an older version of NotePerformer, which I believe is fixed in the current version.
Thanks for chiming in, that’s good to know! (even though I thought the playback instance is separate from Dorico itself).
Is this also the cause for the unbearably laggy behavior? Because it seems to be laggy even when playback is off.
“Silence” is my default setting and it’s extremely rare that I ever load a vst in dorico, so I doubt it.
Looks like a cool piece! I notice in the original file that the System Track is turned on, as well as condensing. I usually turn off both of those when I’m editing a piece; I know that condensing slows things down, and I think the System Track can slow things down as well. FWIW I tried a few simple edits on my 2019 MacBook Pro and they worked just fine.
2 Likes
Thanks for your suggestions. When I turn off condensing, hide the system track, and turn playback off, there definitely is some improvement, and yet, still everything feels heavy.
It’s looking more and more like the issue is the interaction between the project and my computer rather than my computer or the project independently.
In any case, good to hear from you Stephen, we should catch up soon
1 Like
Echoing Paolo’s post, I have tried several edits in your file for about ten minutes and they were all near instantaneous - with condensing still on to boot. I have a Ryzen 3700 with 32 gigs of Ram. I realize it’s of very little help, but I would feel remiss if I didn’t at least report it.
Great piece!
My computer (with 2 cpus and 32 cores) is not likely the issue, and it seems that the project itself is not the issue.
So maybe it’s the installation? I’ll try to uninstall / reinstall and see what happens.
Update:
I uninstalled and re-installed Dorico and Note Performer
This has not fixed the issue 
All I can hope is that this issue is not something that will infect any of my other projects. Other projects seem to be doing much better in terms of speed
What I wanted to try was to export your file as an xml and then reimport it - thereby stripping it of most of its special notation - to see if your lag was due to a graphics, or an edited symbol, or any such similar detail. But in the end it was not worth doing because I experienced no lag. Perhaps you should try it.
@claude_g_lapalme, the vast majority of us have machines with a single CPU and many cores. Michael has a machine with two CPUs and many cores. Methinks you may have muddled your terminology.
1 Like
Duh! You are right, I had my coffee too! Yes, that’s a lot of cores and I will amend my message!
1 Like
Ok, so there’s still some mysterious behaviour that appears to be unique to your machine. In order to have a chance of diagnosing this, next time you in a situation where (eg) note input is very laggy, do one or two note input operations and then immediately afterwards create a diagnostic report (there’s a lot of low level data it can collect about the internals of the operation, but only the last one or two operations are recorded).
One other thing that may not have been mentioned previously - if you have been working intensively in Dorico for a whole day or more, then try restarting Dorico. Dorico’s internal operations are very memory intensive, and it’s quite likely that over this period of time you may have some memory fragmentation, meaning that the system has to do more work to access all the data it needs. Restarting the app will return to a blank slate.
1 Like
I created a new report attached
Restarting Dorico DOES help, but in a very limited way. The improvement is felt, but it is far from resolved.
Thanks for trying to figure this out.
I realized now that I didn’t share the previous file properly. Now it should be available.
I’ve had some experiences where I had a problem project file and the direction Claude was going with some kind of cut/paste to a new project resolved them. I get that others have not had a problem with the same file - but when I have experienced a number of issues/crashes like you have, I’ve had some unexplainable things happen like VST’s still being heard playing when they’d been deleted from the project - things that another machine may not have or see.
I’m basically saying Dorico generally works great. If a project becomes a problem, then creating a clean sheet project is worth not continuing to figure out or fight it for me. I
P.S. 'm not sure it isn’t more the VST’s fault, though I think I’ve triggered the confusion when I have more than one score open behind another, accidently clicked on the wrong one and clicked back. Thereby accidently triggering sample loading back and forth at more or less the same time. @Paul Walmsley -is the green “off” button functional to prevent that, or will be soon?
1 Like
Not really if starting a new project is possible in my case. My project has tons of custom lines, noteheads, playing techniques, etc.
I’ve had a look at the logs and I can see that at 1.55am the MIDI note input commands were processed in 5ms, then after returning at 11am and switching to a different project the note input takes 400-800ms. The logs showed that the slow note input operations caused substantial spacing calculations, which suggests that each edit had a major effect on the spacing, which requires a lot more things to be recalculated.
There are many things that can cause substantial recalculations, especially if you have long bars or items crossing barlines. If you have more than one tab open that also adds to the CPU load. We do find occasional problems where more things are being recalculated than are needed. If you can describe a specific set of steps with a project that reproduces the problem then someone on the team may be able to dig into it.
How about: when you have a problem:
- save the project (perhaps to a new file)
- start recording macro
- do what you do in dorico
- end recording macro
- send the project file and the macro to Dorico team
that should reproduce the problem exactly, on any machine running the same version, right?
This is nice that you can at least objectively “witness” the issue I’m having via the logs.
It’s hard to say what exactly I did that cause this behavior because the project is not a sandbox experiment, but rather a real project with lots of thing, any of which is a candidate.
I don’t have multiple tabs open. I don’t have bars spanning across systems, very long bars, or items across barlines (at least not in the score, and I haven’t opened any part layout yet).
What I have is a large orchestra with multiple instrument doubling per player, and many divisi combinations that make Galley View quite expensive. I don’t know if this is related.
I’m glad I at least have a confirmation I’m not crazy and that you can see the lags on your end.
I have the problem ALL THE TIME, with ANY action.
It looks like Paul was able to confirm that everything is delayed due to a cascading effect initiated by a lag at the note input level.
Happy to provide whatever information I can.