Hairpins with arbitrary end points in terms of beat position

Hairpins in MuseScore must start or end on a note or rest. This behaviour is simple to code and easy for users to understand, but it causes problems for the common case where there are two hairpins on one note:

This particular case could be solved by having a "double hairpin" element, but there are other cases (admittedly more rare) where hairpins do not have any relation to note boundaries. These cases can be notated by manually adjusting the length of the hairpins, but doing so has the following drawbacks:

• Playback is incorrect
• The hairpins will move if the score reflows, leading to the notation also being incorrect

These problems arise due to the fact that the hairpin's length is a purely visual concept in MuseScore: its musical position is still "logically" connected to a note or rest.

A common workaround is to use invisible rests in higher-numbered voices as spacers:

This allows the hairpin to be logically connected to the rests, which leads to correct behaviour on reflow, and potentially also during playback once single-note dynamics is enabled.

However, this is not the solution adopted by the common interchange format MusicXML or its successor MNX. These formats both allow hairpins to be placed at arbitrary locations in a bar, but they each have a different method for doing so.

MusicXML Offsets

The approach used by MusicXML is to add hairpins (or "wedges") to notes or rests (like MuseScore) but then to specify a Start Offset and End Offset in terms of musical divisions away from the fixed location of the note or rest.

This would be relatively straightforward to implement in MuseScore. It could be accomplished by adding new Inspector properties for Line Start Offset and Line End Offset, which would be measured in beats (or possibly in fractions of a whole note) rather than in terms of position on a printed page.

However, it means that hairpins are still in some way "attached" to notes and rests, which leaves open the question of what should happen if those notes or rests were to be changed later on. If a note or rest is moved, deleted, or its durations changed, should the hairpin be moved, deleted or duration changed too? Alternatively, should we go through the score looking for hairpins and updating all their offsets to be relative to new notes and rests that are closest to where the old ones used to be? Should the new offset be given as a positive offset from a prior note or a negative offset from a later note, etc?

MNX Locations

MNX is a draft specification and subject to change, but the approach currently used is to give each hairpin (or "wedge") a location attribute and an end attribute, both of which are specified in terms of beats relative to the current measure, or to the start of the piece. This means that hairpin positions in MNX do not bear any relation to the placement of notes or rests in the measure.

The MNX approach has the advantage that hairpins are unaffected by notes and rests being moved, deleted or having their durations changed. (Of course if you want to move or delete the hairpin and the notes at the same time then you would simply select both in MuseScore, so it is not limited in that regard). However, the implementation is very different to the way hairpins are currently implemented in MuseScore, so some thought would need to be given to how this would be presented in the UI and stored in the MSCX file format.

Questions

1. Should we allow hairpins to be placed at arbitary points in a bar?
   • Or should we continue using the trick with hidden rests?
2. If we allow this, which approach should we adopt?
   • The MusicXML approach with offsets, or the MNX approach with locations?

This is purely a discussion about how to store the positions in MuseScore's internal representation, and how to present it in the UI. In terms of export to and from MusicXML and MNX, it doesn't actually matter which approach we take as you can get the same information both ways. However, we would need to pick one of them because the trick with hidden rests doesn't translate well during import and export.