change handling of hairpins (cresc & dim)
Hi all
I've quite a bit of music which has a dynamic marking, say p followed by a cresc and dim with no intermediate dynamics marked, and no final dynamic marked.
It should be clear that the final dynamic after a cresc + dim should be the starting dynamic.
But MS scans ahead to the next explicit dynamic, and applies that after the first cresc or dim.
so if you have
p < > < > < > f
then MS plays
p < f
and stays at f for the remainder until it hits some explicit dynamic.
In many scores, there are hairpins without intermediary dynamics marked. I think MS could adopt a different strategy.
1. If you have a < > then the final dynamic should be the dynamic prior to the opening <
2. If you have a > < then the final dynamic should be the dynamic prior to the opening >
So look back for the dynamic rather than forward.
Also if you have a < with no subsequent dynamic, there should still be some effect to the <
for example if you have
p < > < > p
then none of the < or > have any effect whatsoever in playback. MS should be able to do something like make sure that any < or > increases or decreases the dynamic by at least 1 click.
Anyway, just an idea. Otherwise I have to go through and manually put in dynamics (and hide them) or try and edit velocity deltas. The hidden attribute also often doesn't carry from score to part so if I forget I can end up with these things in the part if I only hid them in the score.
Comments
That would be great, and surely welcomed if contributed by a volunteer programmer, but it's not going to be a priority for the core developers who have so many notation and layout agenda items.
In reply to That would be great, and by Isaac Weiss
sure,
I consider notation to be priority over playback. Collision avoidance would be a great thing. I spend a lot of time moving hairpins to avoid dynamics, or moving dynamics to avoid note heads, moving slurs etc etc.
In reply to sure, I consider notation to by Adrien de Croy
Can I assume you've seen https://musescore.org/en/user/101731/blog/2016/05/01/musescore-3.0-unde… or tested development builds from the master branch? Lots of functionality is currently broken and crashes are continual, but those are exactly the priorities I was talking about (well, those along with restoring broken functionality and fixing the constant crashes!). ;-)
In reply to Can I assume you've seen by Isaac Weiss
I've run various builds of 3.0 before, but had to drop them fairly quickly due to bugs.
It's a shame because I need the speed improvements to make the large scores usable.
Until I can contribute code though, there's not much I can do.
Maybe a bounty for someone to put together a Windows / MS Visual Studio build package. I'll happily put some money into that.