I am having some troubles with Dorico software. When I started out with my project, it had been really smooth and fast. But the more flows and instruments I added, the more it slowed down. And it’s not like the project file is too big - it’s not even a full orchestra, just about 10-12 players and 30 flows. My laptop is not the issue either - every other program runs smoothly, no matter how complicated the operation, and I exported the project file to a different computer and the results were the same.
I have seen this issue mentioned before on the forums, and the answer has often been some specific settings in the project that affected the speed of processing the file, but I have tried many of the solutions mentioned previously and none of them seem to work. Is there any way someone here could help me analyse my project files? I would much appreciate it.
You could send the file to me if you wish and I can try it now. However, in the past whenever I was working with a large project (orchestral plus extra instruments) I use to have the same issue. The solution, which might not apply to you depending on your gear, was to put my VSTs (virtual instruments) in decoupled mode. Now it works wonderfully, but this solution requires you to be using Vienna Ensemble…
I can vouch for the fact that this is an issue. Number of flows isn’t really the problem (in my experience), but number of players. I have lag issues when doing larger orchestral or band scores. My laptop isn’t the issue, and I’ve tried every optimization suggestion.
I know the development team is aware of this, and is always working to improve performance.
I know this isn’t an answer, but you’re not alone, and they’re working on it!
If you’re comfortable posting your file here, zip it up and attach. If not, maybe someone would offer some advice via private messaging. I would, but you’d be better served by one of the “gurus”.
There are strategies to making the program run as quickly as possible:
– Although the system track has far less of a bad effect on performance than it did in early 2.x builds, if you don’t need it, turn it off
– Due to a bug, large time signatures (drawn centred on instrument brackets, or above the staff at system object positions) can slow down editing: while you’re editing your score, change the settings in Layout Options so that time signatures are drawn at the normal size on every staff instead
– Due to a bug, hiding bar rests and other rests in many bars by way of setting ‘Starts voice’ or ‘Ends voice’ on a note a long way through a piece can also cause the program to feel slow: while you’re editing the score, keep rests showing and try to avoid causing rests to be suppressed in long ranges of bars by way of the ‘Starts voice’ and ‘Ends voice’ properties
– Work with the smallest number of tabs open at any one time as possible. If you are constantly switching between the score and a part, consider having one tab for whichever part you’re working on, and another for the score.
– If you need to do large-scale edits in Setup mode, e.g. reordering flows, adding/removing/grouping players, first close all tabs but one, show a part layout in that tab, then close and reopen the project before making the edits. This will be much, much quicker than doing the edit with the full score layout showing.
– In general, galley view will be a bit quicker than page view because it doesn’t have to do some of the collision avoidance work that is done in page view, so in particular it’s worth doing note input in a big project in galley view
– Also for note input, it can be useful to create a “working layout” that contains only the flow you’re currently working on, but this doesn’t work for layout-related work, as almost all Engrave mode changes are layout-specific, so any Engraving changes you make will only be present in that layout, and detaching a flow from a layout cleans up those adjustments right away, so they will be gone if you subsequently re-attach the flow to that layout.
– Playback doesn’t really have an impact on the performance of the program in general note input and editing, but of course it causes issues when copying and pasting between projects. For that kind of workflow, you should consider using the “Silence” playback template for that phase of work, though of course the downside of that is that you will lose any manual adjustments you’ve made in Play mode.
We’re always willing to look at projects that are particularly slow. To help us diagnose the problems, we need the project file, the diagnostics, a system report (an Apple System Report on Mac or an MSINFO32 report on Windows), and ideally some specific steps that the user feels appear to be causing Dorico to chug especially badly.
Dorico uses as many cores as it can for whatever action it’s performing. The nature of many layout tasks (such as the Setup mode ones that Daniel mentioned in post #6) means that they can only be handled serially: page 10 cannot be cast off until page 9 has been cast off, which can’t happen until page 8 has been cast off. Throwing more cores at the problem won’t help.