Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix linking between score and parts #16544

Closed
oktophonie opened this issue Feb 25, 2023 · 10 comments · Fixed by #18722
Closed

Fix linking between score and parts #16544

oktophonie opened this issue Feb 25, 2023 · 10 comments · Fixed by #18722

Comments

@oktophonie
Copy link
Contributor

oktophonie commented Feb 25, 2023

Task description
When a part is first generated, it will reflect the state of the score at that time. Subsequent changes to the score or part are sometimes reflected in the other and sometimes not, according to a logic which is inadequate for the purpose, and which cannot be properly controlled by the user.

Currently (according to my best understanding, and trying to boil it down to the simplest description):

  • adding or deleting an item in the score will be reflected in the part (or vice versa)
  • changing primary characteristics of an item (the pitch of a note, the actual text in a text item, etc) will be reflected in the part (or vice versa)
  • changing anything considered a property or style of an item (changing the stem direction of a note, or making some text italic, for example) in the score is NOT reflected in the part (or vice versa)

While this distinction makes sense in terms of now the data is modelled, it falls down in practice because many things which are considered 'properties' or 'styles' are significant content which should be reflected in the score and in the parts. Worse, the user has no way to control this (and instead must resort to changing things in multiple places at once, which defeats the whole point of 'linked parts').

Some examples of this (these issues are now closed, as they are expressions of the same basic issue, and replaced by this task, but they contain useful context and discussion): #10268, #13572, #14676.

There are perfectly good reasons why a change in the score may not be wanted in the part, so it's not as simple as saying that everything should always go both ways.

Fundamentally what is needed is:

  • a way to 'unlink' an item in a part so that it is no longer affected by changes in the score, and changes made to it in the part will not affect the score
  • a way to 'reset' an item so that its state resynchronises with that of the score
  • a way to see whether something is linked or unlinked

'Resetting' could work both ways: perhaps you've styled an item one way in a part but you decide you just want to change it back to how it was in the score. Or, perhaps you want those changes to affect the score and, indeed, any other parts in which the item appears. Conceptually, these are the akin the "Reset" and "Save as default style for this score" options available in the Properties panel.

We also need to be able to create or delete an item in a part without affecting the score. These operations pose their own UI challenges (i.e. how do we 'undelete' an item in the part? or, how do we propagate a created item to the score, if we decide we want it there after all?)

To some extent, even changing 'fundamental' properties of items in the parts should be possible. It's a perfectly common thing to want to change an "allargando" (from the score) to "allarg." in a part, for example, in order to make it fit in more limited space, or to put a line break in a long tempo marking for the same reason. We may want to change the pitch of notes for various reasons. Of course this must have a limit (we can't arbitrarily change the time signature, or the rhythm of notes in a bar, etc.)

Some nice bonuses would be:

Most importantly we need to decide on the policy by which the score and parts are linked in the first place. The logic must be extremely easy to understand. There are (at least) two obvious possibilities:

  1. Everything in score and part is linked in both directions; a change in one will change the other.
  2. A change in a part is specific to that part and does not affect the score; but any change in the score will affect the part

Either of these would then be controllable in something like the manner described above; the main difference is that in option 2, changes made in the part will automatically 'unlink' the item, and changes made in the score automatically 'relink' it if necessary.

Finally, we need to consider and rationalise which properties of items should and should not be taken from the score into the parts. There are definitely some questionable things happening there just now. (Height and margins or frames, or the styling of text in frames except for the 'predefined' Title, Composer etc styles, do not transfer over, for example.)


Some related issues:
#14558
#15753
#15863
#17168
#17416
See also: https://musescore.org/en/node/311725

(I'll update this according to corrections/comments ... or close it if it turns out I'm talking utter rubbish)

@oMrSmith
Copy link

oMrSmith commented Feb 25, 2023

or close it if it turns out I'm talking utter rubbish)

No, I think your making a very important point here!

Another thing which I do believe has also to do with the linking
between parts and score is how hiding elements works.

In Sibelius there is an option to

image

To achieve number 1 in Musescore
you currently have to go through each part
and hide the item.

I could make up another request for that
but I feel like it's basically the same problamatic...

@oktophonie
Copy link
Contributor Author

Yes! I reference that (under 'bonuses') as having a way to show an item only in the score but not in any parts. Essential, definitely.

@Tantacrul
Copy link
Contributor

Thanks for writing this out @oktophonie. I should have done it a while ago. We need to get on this quickly.

@xlf1024
Copy link

xlf1024 commented Feb 25, 2023

Personal wishlist regarding the score-part relationship:

  • Replace instruments in parts

    • different clef and/or transposition than main score
    • maybe via linked staves?
    • (why?: trialing different voice-instrument combinations during rehearsal; backup parts in case of illness)
  • Hide lyrics per part

    • currently possible via select similar -> properties -> visibility off, but this doesn't affect lyrics added afterwards
    • should probably be easier to set up as a property of the part (or the of voice in the part)
    • (why?: compact parts for instrumentalists playing along with singers)
  • SA/TB compact/closed score handling:

    • generate separate parts for each voice (currently possible by hiding sub-voices)
    • generate expanded (4-staff) score (currently possible via linked staves)
    • compact stem rendering for piano part:
      • entering e.g. soprano and alto as separate voices causes the stems to face outward even if the rhythm is the same, which takes extra vertical space
      • have a style option to merge the stems of both voices so that less space is needed
  • Lyrics cloning

    • SA/TB scores often have the same lyrics for all voices.
    • currently, copying the lyrics to each voice is needed to make them appear in the individual parts. The copies then need to be hidden manually in the main score
    • automatically clone the lyrics from soprano to alto, from alto to tenor, and from tenor to basso.
    • entering lyrics in tenor disables cloning from alto to tenor for that note. The tenor lyrics are then cloned to basso.
    • display the clones greyed out or colored to distinguish them
    • in parts: only display the lyrics once: the original, if visible in the part, otherwise the first visible clone
  • some method to hide instrument names in the score/parts while keeping them visible in the instruments panel

  • some method for linked cue notes (--> only visible in parts if source voice is not visible; automatically update if source voice is modified, automatically display source voice name) (Macro or tool to "paste as cue notes" #13570 i guess)

  • system breaks

    • I like to try and have system breaks at phrase boundaries and identical in all parts (so that they are easy places to agree on during rehearsals)
      • some parts can fit two phrases in one system
      • some parts might need two systems for a single phrase
      • either way, the system break in the part that has the most measures per system should be a system break in every part
    • some support for that would be nice; ideas:
      • configuring system break sync (seems more in line with what you're discussing above):
        • e.g.: main score system break changes propagate to parts, but not vice-versa, string section parts sync, trumpet part propagates to whole brass section, but not vice-versa)
      • soft system breaks (probably easier to use (?), but separate feature)
        • guide automatic system breaks
        • ideally different priority levels
          • what I tend to do (manually; to make the system breaks reflect the structure of the piece):
            • split every 16 measures
            • line too long? --> 2x8 measures
            • too long? --> 2x4
            • etc.
          • each of these steps (i.e. 16 measure group, 8, 4, ...) would be a priority level for the soft system breaks
        • even just one level would be a huge help though
        • soft breaks are synced between all parts, but which ones are used differs (like how measure boundaries are the same in all parts, but automatic system breaks already aren't)

While I describe this as individual features, some unknown subset of this might be achievable using the generic system you seem to plan here. Would probably require some linked staff, ... -trickery, but I'm fine with that
Tried to keep this somewhat compact; I hope it's readable; if not, please tell me
And yes, most of this is already possible using a bunch of copy-pasting, but that's tedious and error-prone when making adjustments/fixes during rehearsals

@oktophonie oktophonie added this to To triage in MuseScore 4.1 via automation Feb 27, 2023
@oktophonie oktophonie removed this from To do in 4.x SHORTLIST Feb 27, 2023
@bkunda bkunda moved this from To triage to Major tasks in MuseScore 4.1 Mar 14, 2023
@jonarnoldmusic
Copy link

Thanks for adding this spec. In my work with early music, I do a lot of input into the parts directly since I'm working from partbooks. The main aspects of this that would help me are differing clefs in the parts and score, and the styling of accidentals. Parentheses, brackets, and positioning of accidentals (musica ficta) are crucial for editorial accuracy, and it's very easy to make a mistake when I have change the styling in both places.

@jonarnoldmusic
Copy link

jonarnoldmusic commented Dec 5, 2023

I was hopeful about the new parts features in 4.2, but it seems like accidental brackets and size are not included in the linking between score and parts in 4.2 Beta. Is this planned for the future? It would really be helpful for working on mensural music as mentioned in my comment above. I would also consider things like cautionary accidentals to be musical content that should at least have an option to sync.

Also, although there is a toggle for accidentals to sync/unsync, it doesn't seem to be syncing in either direction. I tested position and color.

Seems like different clefs in score and parts is also not an option.

@oktophonie
Copy link
Contributor Author

oktophonie commented Dec 5, 2023

Accidentals: not as simple as I first thought - see the comment below - so to facilitate what you want (which I agree is desirable) is going to require some thought, design and internal rejiggling. Please raise this as a feature request - comments on a closed issue are not likely to get much attention.

You can have different clef changes in score/parts; if you want different initial clefs (which is fair) this should be raised as another feature request, too.

@mike-spa
Copy link
Contributor

mike-spa commented Dec 5, 2023

@jonarnoldmusic Accidentals are complicated, because in most cases they don't exist "per se": they respond to context, and context can easily be different between score and part. So linking them is really not trivial, but thanks for raising this point, we'll keep it in mind for the near future. (Please open new issues/feature request in future).

Side note: I read your comment above, and I don't see why it's necessary for your workflow to enter your music starting from the parts. Sure, early music comes in partbooks, but you can still copy it into the full score: if you need to work with one staff at a time on the screen, you can just go on the Instruments panel and hide the staves you are not currently working on. If you do as much work as possible on the full score, and only then generate the parts: then most properties will be copied (like accidental positions, brackets, etc) even though some of them may not be linked.

About the different clefs: now you'll be able to do that, thanks to the "Exclude from score" / "Exclude from part" option.

@jonarnoldmusic
Copy link

jonarnoldmusic commented Dec 7, 2023

I find it much easier to proof my note entry when I mirror the line breaks in each partbook. That can't easily be done for multiple parts in the score. I also use the "Display note values across measure boundaries" in the part only in order to mirror the partbook more closely. I find that I can enter the music much faster and more accurately if the target engraving looks more like the partbook. Then I let the software change clefs, tie rhythms across barlines, etc.

I'll open new requests, thanks.

@Jojo-Schmitz
Copy link
Contributor

There's a plugin for this, see https://musescore.org/en/project/export-layout-breaks-parts

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
engraving needs design Design is needed P0 Priority: Critical task
Projects
Status: Done
Parts
  
Done
MuseScore 4.1
  
Major tasks
Development

Successfully merging a pull request may close this issue.

8 participants