Notation in a divided section of bowed string instruments

[Dima-S-Jr]

Your idea

First of all, I ask you to include in the properties of the staff text the automatic alignment of the word "div." in the center between the staves of the part, since it is very often used when writing a score in the section of bowed string instruments. And very often I have to manually align this word between the staves. We all understand perfectly well what the word "div." means. I usually try to avoid splitting the part into two or more staves when divisi, indicating only the word "div." above the corresponding places. But sometimes it is still necessary to write a part on two or more staves, so as not to create confusion by placing everything on one staff. And that's where the problems begin. Firstly, the word "div." itself can be written as a regular text of the staff, and it will not automatically align between the staves of the part, since Musescore simply does not have such a function. Secondly, Musescore does not know such a thing as "divisi", and, accordingly, it does not know any of the 2 existing ways of writing. Basically, people use a method in which in the system where divisi appears, the part is represented as 2 (usually) staves (from the beginning of the system) and a divided line is written in each staff. If the divisi begins or ends not at the beginning and not at the end of the system, respectively, then the contents of the non-divisi are simply duplicated by staves. At the same time, the marks are "div." (at the beginning of the system) and "unis." at the beginning of the system, preceded by a system with divisi, are also affixed. There is also a more complicated way of writing a divided part. It consists in the following: the adjacent staff does not appear throughout the system, but only in those places where the "div." begins (above or below the main staff, but preferably from below, since it is better to reserve the upper space for solo lines). And there is no strict rule that an additional staff for divisi in this way should start with a bar-line. The main thing is to specify the clef and the key signature before starting (if the score is not in "C"). Before the beginning of the divisi, a brace is also placed between the main and additional staves and the word "div." itself, and at the end of divisi an arrow is placed from the last note/rest of the additional staff (in the SMuFL it is represented as "Staff divide arrow up" for the lower staff and "Staff divide arrow down" for the upper) towards the main staff with the indication "unis." on the next note/rest. In the case of "div. a3" and more, I gave an example-a picture, since explaining it all in words will take me half my life 😅 There is also a method of writing solo strings selected from one of the parts of the bowed strings section. The method is similar to the previous one, except for the fact that the staff placed on top of the main staff is not covered by brackets (neither square nor secondary). In this case, the solo line should be signed as "solo" (or "sola" if these are violas), and the main line as "gli altri" (or "le altre" if these are violas). At the end of the solo line, "tutti" (or "tutte" if these are violas) should be indicated on the main staff. Although this option is not often used, it is very convenient for occasional division.

Problem to be solved

Firstly, the user does not have to constantly manually adjust the placement of the corresponding text in the center between the staves. This will reduce the time of writing the score and save the user from such inconveniences.

https://github.com/musescore/MuseScore/assets/134041121/7ffae47d-ac27-46d6-b3c3-3e5e97fe7a42

Secondly, the user does not have to constantly copy the contents of one staff to another in systems where divisi is represented.

https://github.com/musescore/MuseScore/assets/134041121/48d13b27-629a-4d94-84bb-9e2bd65bbd3c

Prior art

If divisi changes occur partway through a system, Dorico automatically extends the extra staves to the start or end of the system, and duplicates the regions where the section is tutti automatically using unison ranges.

Additional context

It should be noted that the loudness of the divided part should not be increased, as it is happening now. That is, if you duplicate the contents of one staff in the 1st violins to another in the system where "div." is present, the loudness will increase, because Musescore does not understand that this is divisi. It is also not possible to assign a separate solo instrument in the mixer for the solo string of the part. The implementation of such a notation is not that difficult (as I think). In the settings of the score style, the user could choose the way he wants to write the divided part. In edit mode, clicking on "div." would pop up a window in which the user could select one of the ways. At the moment, I'm asking you to at least implement the possibility of automatically aligning the text of the staff between the staves of the part.

[DaddyLudwig]

For the third thing you mention about the gaps, if you right click and go to Staff/Part Properties for the divisi staves, you'll see a Hide when Empty property. If you set that to Always, it will not produce such a large gap in the score when the divisi staves aren't used. I do the same thing for symphonies and operas and such where entire instruments are left out of movements or sections.

Video demo of what I mean:

https://github.com/musescore/MuseScore/assets/6530761/67338245-93d3-4b6d-8ac6-1b66bdbd2676

[Dima-S-Jr]

For the third thing you mention about the gaps, if you right click and go to Staff/Part Properties for the divisi staves, you'll see a Hide when Empty property. If you set that to Always, it will not produce such a large gap in the score when the divisi staves aren't used. I do the same thing for symphonies and operas and such where entire instruments are left out of movements or sections.

Video demo of what I mean:

8mb.video-uQO-E5Al09K7.mp4

Thank you for such a video demonstration. It turns out that the issue of gaps has been resolved.

[Dima-S-Jr]

Partly related to #15616.