I go from 2-fold divisi in the cello part to a 4-fold divisi. In the staff where this happens (in the middle of the page shown), Dorico is only showing cello 1 and 2 (there are notes for 3 and 4 in those two bars rest). It fixes itself in the next staff. Note I put a “visibility reset” for all 4 celli staves in the frame break on top just in case, but that didn’t help.
It rather looks like a bug or am I (yet again) missing something obvious…?
Happy to e-mail/submit the file somewhere if anyone is keen to have a look (not sure what the procedure is these days).
And this might be further clue: if I insert a system break on the offending staff and try to force a “staff show”, the first two cellos are labeled “cello (1)” and “cello (2)”, but the next ones “cello (c)” and “cello (d)”. They don’t respond to the “show staff”.
Is the issue that you are trying to make two changes of divisi within the same system? Dorico cannot do this at present, so the first divisi change it encounters on the system will be the one that is used for the system as a whole.
No, I don’t think that is the issue (unless I misunderstand you). There is a divisi-change at the top of the page shown, going to two cellos. Then there’s a divisi change 2 systems lower, going to 4 cellos. That divisi change is in the middle of the staff, which seems to confuse Dorico. If I put a system break right at the divisi change, it is working fine. Happy to send you the file, if you want to have a look?
If you already have divisi sections active at the start of the system, then you won’t be able to change to a different arrangement in that system; the change will indeed need to come at a system break.
Ok, thanks. So you mean you can’t go from e.g. two-fold divisi to four-fold divisi at all (within a system), even though it’s only one CHANGE within the system?
That’s right, because at the start of the system, the previous divisi change is still in effect, it’s prevailing (e.g. perhaps imagine that at the start of every system from that position on, Dorico’s having to make an active choice to show more staves than normal for that player, but that decision gets made once at the start of each system and can’t change within the system) .
It’s on my to-do list to clarify these circumstances in the manual as well.
Ok, thanks for clarifying that. It’s not a major issue anymore, because the work-around (force a system break at the same bar-line), is obvious. And it doesn’t happen very obvious (if in doubt, blame Wagner!).
If you would allow me, could I say that to me this is not an issue of “clarifying it in the manual”. A mismatch between score and part should really never happen, unless the user explicitely asks for it. Indeed, it caused me some embarrasment during rehearsal, as I was wrongly criticizing players for not playing their notes.
Assuming it’s not easy to fix this because of the software-architecture, would it be a thought to automatically make a divisi change always a system-break by default (in both the score and the relevant part)?
Indeed. Although I presume the gold-standard is to not to have to proof-read parts at all ;-).
The thorny aspect of this issue is that you create the divisi while inputting the music, which (presumably like most people) I do in write-mode and panel-view. At that point you are blissfully unaware of system and frame breaks.
So the proofreading step you mention is to go through each part scanning for divisi labels that don’t coincide with system breaks. But that is a task is onerous, error-prone, and could/should be automated.
I’m sorry I need to dig up this old topic again.
While I do appreciate the solidification of the Divisi functionalities in version 5.1, this limitation still persists to this day (5.1.40) and I consider it a very critical problem.
I will be heading into a recording session later today and last night while doing some last checkups, I noticed some notes were missing in divisi either in parts or in score depending on where the system breaks were (no matter whether divisi condensing was activated or not).
This is something that in my opinion under no circumstances must happen in a software. I need to be able to trust the software to show all the notes that I (correctly) entered. I was aware of this limititation and went for manual hunting of these issues already but in high volume, high pressure situations like the current project, obviously these things can slip through and it adds an extra layer of stress to an already stressful project deadline when I can not trust the software in this regard and need to add in another high alert proof reading round.
In fact the unrealiability in this regard makes me prevent using the divisi functionalities as much as I can when working on high pressure projects.
I really would appreciate if solving this issue could get a high proirity with the Dorico development as it can be an absolute show stopper in critical situations (and causes the last minute reprint of several dozen violin parts today).
How would you propose that Dorico handle more than one divisi change in a system? Just showing the maximum number of staves doesn’t solve it, because it may not be equal divisions of a section; there can be one or more soloists, or any designation.
If you want to show and hide staves as necessary (as proposed by brittencellist above) that can be done by adding and subtracting staves from a single player. That offers the advantage that a solo staff can be added above, which the divisi feature can’t do.
I’d like it to exactly behave how it does when you reduce the amount of divisi during a system: show a blank staff till the end of the system.
So in this case, show the maximum needed amount of staves right from the beginning, leave the ones not needed blank until needed, clear up any splits through divisi labels during the system and definitely not omit any notes on the way.
Force a system break at a divisi change (where appropriate). That is a very crude way, but still very much preferable over losing notes in a part, and also relatively easy to program. Keep this until a more elaborate but more elegant solution can be programmed.
I agree this is anything but ideal. It has bitten me in the past as well. I am usually working with files created by composers with varying degrees of proficiency in their software of choice so I can’t rely on how they entered things as a safeguard against music going missing. This leads to a lot of extra proof-reading time and effort when dealing with divisi which I feel goes against the design philosophy of Dorico. It would be nice if it would at least throw up a signpost or warning for easy identification. Under no circumstances do i want the software to remove things without my consent!
Ah yes I’m also encountering this problem at the moment and it would be great if it can get fixed. it’s very common to go from one Divisi to another — and the big problem here is that there is no way of knowing whether Dorico is showing you all the inputted notes or not, so as you say it’s easy for things to get missed.
It feels like the lack of signpost for invisible notes is a drawback which has various undesired side effects in Dorico (ref. also hunting down music that plays but is not visible even in galley view…). Perhaps if the Divisi issue itself can’t be fixed, at least a signpost could be invented to appear whenever there is invisible music in the file.
(although it would be preferable to fix the ability to go from one Divisi combination to another.)
will say my preference personally is the “cutaway score” one: the extra staves appear/disappear when they are called for, similar to what’s already been implemented for adding/removing staves to a single instrument
