Dynamics/hairpin range for Voice

• Apr 28, 2015 - 08:33
Reported version
P2 - Medium
S5 - Suggestion

Currently we can set hairpins and dynamics to apply to the staff, the part (like both staves if a piano) or the entire score.
Esp. for closed score SATB, but also in other situation it'd be useful to restrict hairpins and dynamics to the voice they got attached to.

To maintain backward compatibility with existing scores, in the corresponding enum we need to take care of keeping the values for STAFF, PART and SYSTEM the same, so either append VOICE to the end of that enum or insert it in front, but set it to -1. Logically it should be the first entry.

Support for playback would mean that we'd have to change velocity to be a property of voices rather than staves.


With the introduction of single note dynamics it seems it would be better to take this into account too (should be useful for vocal scores, I believe?)

If so then the single note dynamics code (and the soundfont) needs some adjustments to allow setting different dynamics for different notes in MIDI channel. Here is a pull request by @TheOtherJThistle that can be used in implementation of this feature: https://github.com/musescore/MuseScore/pull/5004

But, of course, this doesn't revoke the necessity of assigning different MIDI velocities for different voices in order for this feature to work properly with other soundfonts.

That PR makes it possible, yes. The problem with poly aftertouch is that you need to send the note through with the dynamic events. This would require a fairly large change to the current system from just sending dynamics events to working out which notes to send events for and then sending them for the correct length of time etc. So, while not impossible, I'm not exactly prioritising implementing this, especially as it's not a regression.

The PR which lays the groundwork for this to be implemented has been merged. I'll chat with S. Christian Collins about getting the soundfont side worked out, and once that's done I'll get started on an implementation :)

If that in fact happens, but anyhow, a PR to fix playback will almost never affect layout or vice versa, since the code is almost completely separate. So a separate PR would be needed. I hadn't noticed that layout bug you mentioned, but now that I see it, it's pretty serious and should probably be dealt with first.