Cross-staff arpeggio placement
Reported version
3.0
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
Cross-staff arpeggios are re-positioned on completion of another action (e.g. note entry into another measure), regardless of the arpeggio's Automatic Placement setting being on or off.
See measure 9 of the attached score.
Note this is not a duplicate of other logged issues regarding cross-staff arpeggio playback - this issue concerns display and placement.
| Attachment | Size |
|---|---|
| Reminiscences_de_Lucia_di_Lammermoor.mscz | 24.5 KB |
Fix version
3.0.1
Comments
Hi - any update on this? Thanks.
Sorry, this slipped through cracks. I believe the underlying issue is similar to one with cross-staff slurs - at the time we lay out the element, we don't actually know the staff distance, because in fact the staff distance depends on knowing the layout of slurs, arpeggios, etc. So somehow we need to come up with a strategy here.
In reply to Sorry, this slipped through… by Marc Sabatella
Thanks Mark. I can think of a couple of approaches which I suspect would be non-trivial to code (I'm no developer!)...
1) Arpeggios work as vertical lines with top and bottom handles attached to notes, much in the same way as horizontal lines work, but with the capability for the two handles to be linked to notes in neighbouring staves and/or different voices (starting on the same beat of course). With both the bottom and top notes of the arpeggio known, its height could adjust automatically as other elements are added and the distance between the two staves changes.
2) Give arpeggios a capability similar to cross-staff beaming where Shift + Ctrl + Up/Down enables the arpeggio to 'cover' (and uncover) whole chords on the same beat in a neighbouring staff. But this gets complicated of course when considering notes/rests in other voices, invisible notes, etc. So, still a tough fix. In fact, I don't think there's a solution to this which doesn't resolve both cross-voice and cross-staff arpeggios.
Maybe the simplest fix is to enable free dragging of the top handle of the arpeggio when its 'Automatic placement' property is unchecked? In this state any collisions with other elements would be ignored, and if the staves move closer or further apart the arpeggio height would just have to be manually adjusted again. That feels more straightforward to me but I'm sure there'll be something I'm not thinking of here...
Regards,
Phil.
Looking at this. The issue is that there really is no such thing as a cross-staff arpeggio currently - just a single staff arpeggio that has been manually adjusted to be much longer than usual. So what happens is that autoplace is simply preventing the collision with the next staff. It's a minor bug that it doesn't do this until the next relayout, but a worse bug to me in that disabling autoplace doesn't allow it to work. So I intend to fix that. But an unfortunate side effect of disabling autoplace is that you'll be on your own to manage it horizontally as well - avoiding accidentals, creating enough space after the preceding elements, etc.
Since disabling autoplace for arpeggios does essentially nothing right now, this won't be seen as a regression exactly, but it does point out that we eventually need to just support these. Somehow, it seems related also to the idea of support cross-staff notes (as opposed to cross-staff chords - that is, single notes within chords moved cross-staff). I suspect similar code will be involved and this will probably need to be handled at the same time.
In reply to Looking at this. The issue… by Marc Sabatella
I'd be happy (for now) for the old v2.x workaround to be available again as you describe. Manually moving arpeggios horizontally to avoid accidentals, clefs, etc. is fine (it was necessary in v2.x so I'd be happy to do it again in v3.0).
Interesting you mention cross staff notes within chords. I've also noticed effectively the same behaviour in v3.0 with those as happens with cross-staff arpeggio placement. Creating these in v2.x was possible via a workaround involving creating the chord's lower staff notes in a separate voice with identical beaming to its other notes in the upper staff, and then dragging the lower staff's beam up to meet the upper staff's. That resulted in slightly thicker looking beams and stems, but it was good enough. Now in v3.0 the lower beam simply can't be dragged upwards onto the upper staff without the distance between the two staves being automatically increased during the drag. This happens regardless of the beam's (or any other neighbouring element's) Automatic placement property being set on or off. See measures 19 to 21 of the attached score for an example of what I mean.
The answer ultimately is support for fully functional cross staff arpeggios and chords - both placement and playback - but this is free software so it's only right to be patient! In the meantime I'd really appreciate seeing your proposed short-term fix implemented.
Thanks and kind regards,
Phil.
Well, in 2.3.2, you only would have needed to adjust horizontal position of a cross-staff arpeggio if the "foreign" staff had accidentals but the "native" one did not, because the arpeggio does avoid the "native" accidentals (accidentals on the chord it is actually attached to). Disabling autoplace means it doesn't avoid anything except the notes themselves. Considering that disabling autoplace accomplishes nothing right now, I still consider this a win, it means a simialr workaround as 2.x exists even if it requires an extra step. Also, it should be mentioned a second workaround exists - use a fixed staff spacer (new for 3.0) to keep the staves a fixed distance apart, thus in effect disabling that particular aspect of autoplace for that particular system.
The issue you mention with faking the cross-staff notes by extending beams is actually the issue I started out wanting to fix, using the same approach - allowing you to get the desired effect by disabling autoplace on the stem. See #280677: Autoplacement won't allow a stem crossing staves
Anyhow, here's the PR to address both the beam and arpeggio issues: https://github.com/musescore/MuseScore/pull/4564
Fixed in branch master, commit bbbe1f68e8
fix #280677, fix #279643: semantics of disable autoplace on stems et al
Fixed in branch master, commit 5fe8363cd7
Merge pull request #4564 from MarcSabatella/280677-autoplace-stem
fix #280677, fix #279643: semantics of disable autoplace on stems et al
Fixed in branch 3.0.1, commit 5a4dd5514e
Merge pull request #4564 from MarcSabatella/280677-autoplace-stem
fix #280677, fix #279643: semantics of disable autoplace on stems et al
Automatically closed -- issue fixed for 2 weeks with no activity.