Changes not reflected in part

• Oct 28, 2013 - 14:32
Type
Functional
Severity
S4 - Minor
Status
closed
Project

1. Open attached file (produced in 1.3).
2. 'File'>'Parts…'.
3. 'New'.
4. Tick instrument.
5. 'OK'.
6. Drag a line (e.g. text line) to the first note.
7. Right-click the line.
8. 'Line Properties…'.
9. Change 'Text' to something else.
10. 'OK'.
11. View part.

Result: The text differs to the full score.

Note: It also happens with changes in 'Inspector…' - perhaps elsewhere too. It also happens in a Guitar Pro file if a line is added, its properties changed and the part viewed.

Using MuseScore 2.0 Nightly Build (6df1e21) - Mac 10.7.5.

Attachment Size
Changes not reflected in part.mscz 1.34 KB

Comments

Title Text property of line not reflected in part Changes not reflected in part

Since it affects 'Inspector' too (e.g. changing a notehead), I change the title back.

According to my understanding of how links are implemented, I think the point may be that each type change not reflected should be considered a separate bug. That is, each type of change is handled differently, so it needs to be made clear which types changes currently don't work.

In other words, simply saying "changes not reflected" is kind of like saying "note input doesn't work" - too broad.

At least, this is my understanding. So my working assumption is that each type of change not linked between score and parts hould get a separate issue, because they will need to be fixed separately.

Hopefully soon we'll be looking at this. I've raised priority to normal just because it *isn't* minor. And even though I said it probably makes sense to file separate bugs, maybe first we'll build a list of what is actually. I'm thinking it probably makes sense to fix a bunch at once.

I'm working on getting automated part tests happening. Meanwhile, manual testing is showing that parts work reasonably well with respect to changes actually being linked, except in the following cases (not necessarily an exhaustive list, but I was reasonably thorough):

Elements added to score *before* part generation:
- articulations
- lyrics
- lyric verse number
- barline length customizations
- fingering
- breaks
- bends (tab)
- cross-staff note assignment
- glissandi
- arpeggios
- clef changes
- symbols
- single-note tremolo

Elements added to score *after* parts generated:
- ambitus
- fret diagrams
- frames
- volta

If an element is on this list, that means that it is either not propagated to the parts at all, or that the element is propagated but the link doesn't work, so removing the element from the part does not affect the score. In a couple of these cases, it's arguable that maybe it *shouldn't*, but most of these are just bugs.

Also add ties to the first list - that's actually perhaps the most serious issue. That is, create a score that includes tied notes, generate parts, visit part, delete the tie, then look back at score - tie is still present. At that point the further edits to the score or part will result in different pitches.

The first list looks depressingly long, but actually, it's largely items attached to chords, notes, or rests, and easily fixable within Chord::linkedClone and Rest::linkedClone (the latter doesn't exist yet, but I've created it). I have this much coded up and working.

A couple of other items on the list are not related to this but nonetheless easy:

Breaks - page and line breaks are skipped on purpose, as they should be. Only section breaks should be linked, and that's extremely simple to do in cloneStaves(). I've got this working.

Symbols (attached to segments) - actually, these are copied and linked just fine; they just don't get laid out correctly (except for symbols in the current score font), because the copy constructor for Symbol doesn't copy the _scoreFont field. That's an easy fix too, and I assume doesn't break anything else

A few items are harder, for me anyhow:

Lyric verse number - I don't understand how these work at all yet, and I'm not just talking about linking.

Clef changes - these are not linked on purpose. It's easy enough to link them, so upon delete of a clef in the part, the clef is also deleted in the score. But notes are not redrawn in the score onto their new lines. I assume that's straightforward to fix too, but I'm also not sure how this plays with the ability to have different clefs for concert pitch on versus off.

Barline customization - the problem isn't lack of links, it's that the customization code makes no attempt to follow them.

Cross-staff note assignment - again, links are there; the cross-staff note assignment code just doesn't try to follow them.

Ties - there is code to deal with these, it just doesn't work.

I think it can happen for guitar pro import? Anyhow, the rest object itself has a lyricsList (inherited from ChordRest), might as well handle it even if it's normally empty.

Werner's partial fix covers the chord-attached items as well as segment-attached symbols. Still left are the note-attached items (fingerings, symbols like parens attached to individual notes), rest-attached items (articulations & lyrics) and the few "other" items I mentioned (ties, section breaks the ones I think are straightforward).

Of the others, I'm not terribly concerned about barline customizations or cross-staff beaming. I mean, sure, it would be nice to get these working, but fixing that shouldn't be a deep change and could be done at any time. Clefs I am more concerned about, as it will affect all scores (and all tests) using parts.

Here is a PR to deal with Voltas https://github.com/musescore/MuseScore/pull/1022

Werner stated he will look at the remaining cases in the coming days. Tests for the already supported element types (articulations etc...) are welcome. Also I believe that our current tests are not testing deletion of elements in parts if the element was present before part creation.

MarcSabatella volunteered for the tests. Thanks Marc!

I believe we can skip having a separate test for deleting an item that was present before parts were created if I add a simple test for the generation itself - making sure the parts are generated correctly, with links present. That's actually the more important missing test. The deletion failures are just a symptom of the link not being there. So if we test deletion for the case of elements added after - so we know the deletion code honors the links - and we know the links are present in the case of elements added before, we know it works. Links are links.

One other thing we are not currently testing, though, is "editing" (above and beyond manual positioning) of a linked item. Text, mostly, but also things like changing anchor points of spanners. That also includes two of the cases I mentioned above that I already know don't work: cross staff note assignment and barline customizations (by which I mean, changes to the length or style of a single barline for a single measure/staff). For barlines, it's debatable whether it should link, since the span is pretty much guaranteed to differ between score and part. So it probably can't work in the general case. Similar story with brackets. I'll try to add tests for what makes sense here, but am not necessarily sure what does or doesn't.

Recent commits fix a number of the remaining issues as well. So I did another round of checking to see where we stand.

The most serious issue I see remaining is with ties. As mentioned in #9, ties already present in score when parts are generated get propagated to parts but with no links, so deleting a tie in score doesn't affect part and vice versa.

Also remaining from the first list (items not propagated correctly to parts if already present in score when parts are generated):

- section breaks (not propagated)
- clef changes (propagated but not linked)
- ties (propagated but not linked, as mentioned above)
- lyrics verse numbers (propagated but laid out incorrectly; that might be a more general issue)

From the second list (items not propagated correctly if added after parts are generated - not propagated at all except where notes):

- section break
- ambitus
- fret diagrams
- frames (propagated but not linked)
- titles etc (a frame is created even if not necessary, but no text is added)

Cases where "edits" to existing elements are not propagated:

- guitar bends
- fret diagrams
- cross staff voice assignment
- barline length customizations (changes to length or type of single barline on single staff)

There is also a layout issue with clef changes I'll submit separately. And another - mmrests not displaying on tab staves.

After the last round of changes, ties are good.

Section breaks do now propagate to parts and they are linked properly if the break is added after parts are generated. *However*, if a section break is already present in the score when the parts are generated, it is propagated but not linked.

Looking at the list of what's left - both here also in other open issues - there's relatively little I would feel comfortable dealing with myself. Here is a PR that picks off what I perceive to be the easiest of the remaining link issues. It finishes the job for section breaks (adds links for breaks present before parts created) and frames (adds links for frames added after parts created), and handles both the propagation and linking for fret diagrams (both before and after parts created):

https://github.com/musescore/MuseScore/pull/1086

After those are fixed, the remaining issues I know about with respect to *creation* of elements are only:

- titles (not propagated if added after parts generated, plus an extra frame is added to parts)
- ambitus (not propagated if added after parts generated)

There will still be at least the following issues with *editing* of elements, where the edits are not propagated but should be:

- guitar bends
- fret diagrams
- cross staff voice assignment
- barline customizations (although I haven't tested since recent changes here)

There are still problems with lyric verse numbers, but these seem to go beyond linking issues.

Great! I also see you merged my PR, so the list of known problems is now quite short.

BTW, regarding ambitus, I note that it does not take transposition into account, and thus there would be more to getting that working in a score/parts setting than simply setting up the links. My guess is that users of this feature would consider that pretty low priority, though.

Titles are the biggest remaining known issue with parts in my opinion - perhaps the only one left that I'd consider important to fix before any Beta release. Well, except for #28401: Chord symbol entered after parts generated not transposed if score and part are at different concert pitch states, which I submitted separately because it's of a different nature.

Latest changes - titles are now added, however, it still creates an extra title frame in the parts. That is:

1) new score with no title, composer, or other text entered in wizard
2) generate parts
3) view parts - should be a frame for the instrument name in parts that is not in score
4) return to score
5) add title
6) view parts

Result: there is now a *second* frame for the title

Also, if one of the parts is for guitar and itself has a linked staff (eg, standard+tab), then you get a crash at step 6.

BTW, I assume part of the problem is that upon generation of parts at step 3, there is a title frame for the parts to hold the instrument name, but not one in the main score. It wouldn't bother me if one were added to the main score when the parts were generated, if that turned out to be a better fix than creating a new one at step 5 but linking it to the existing frames in the parts.

BTW, guitar bend editing does now work.

Regarding titles: see https://github.com/musescore/MuseScore/pull/1158. This PR forces an empty title frame to be generated for the score (if one is not already present) before generating parts. That way, it is guaranteed the frame generated for the parts (for the instrument name) will have something to link to. This fixes both of the problems with titles - the extra frame and the crash.

I did first try an approach where adding a title to the score after part generation would attempt to link the new title frame in the score to the existing frames in the parts, but this led to problems if you tried adding the title from the part rather the score. This was not an unsolvable problem I'm sure, but I decided adding the frame to the score up front would be an easier and safer solution.

After this is fixed (either by my PR or by other means), the only significant issue remaining here will be that edits to fret diagrams are not propagated to parts.

Title change is in.

Ambitus as mentioned has other issues - doesn't account for transposition, probably not likely to be used in a "parts" context anyhow.

Barlines have other concerns - some changes to barlines make no sense with respect to parts, because things like span might apply differently. So while this deserves attention at some point, it's not a priority.

I think if we can get fret diagram editing to work, I'll be satisfied, and we could even close this issue. And then maybe I'll open new ones for ambitus and barlines, which will need additional discussion & consideration anyhow.

Status (old) active fixed

Fret diagram editing works!

I'm sure there is stuff I've left off, or things that worked and now are broken, but I think we're down to the point where it's better to file individual issues for the things that don't work. So I'm marking this fixed.