Final tempo marking added too late when note exceeds the selection

• Mar 22, 2016 - 10:01
Type
Functional
Severity
3
Status
closed
Project
TempoChanges

Thanks a lot for updating the plugin.

But as life goes... My first attempt using it on one of my scores revealed a minor problem with the new algorithm: If there is a note in the last track, that exceeds the selection, the final tempo marking is not generated on the first note after the selection, but on the first note following that long note in the last track. Consider this example:
TempoChange2Test1.png
Applying the plugin gives:
TempoChange2Test2.png
The marking (4=120) on the first beat of measure 2 has been replaced.

Attachment Size
TempoChangeTest2.mscz 6.35 KB

Comments

• Mar 22, 2016 - 10:39
Severity ⇒

I was actually mistaken about the "last track": It doesn't matter which track contains the "long note".

Reply

• Mar 22, 2016 - 11:20

Maybe I've approached this from the wrong side:
One might argue that the current behaviour actually is a feature (not a bug).

So maybe the real problem I'm facing here is, that I can think of two types of tempo changes:

  1. Transition: This would be a tempo change that leads to a section in a new tempo.
    The current version of the plugin seems to be optimized for this type.
  2. Effect: This would be a local tempo change returning immediately to the old tempo (a tempo) rather than leading to a new section.
    I think the plugin could easily be extended to support this, by adding a checkbox like: 
    [ ] don't create visible tempo marking for final tempo

So we could change this into a "feature request".

Reply

• Mar 22, 2016 - 11:20
Severity ⇒

ARGH :) Thanks for testing!

It's introduced by me not being smart enough about finding the last note following the selection across all voices. Think I'll track all the last segments I find and locate the firstmost (lowest tick) of those before applying the end marking.

Reply

• Mar 22, 2016 - 11:32

Cross-posted, so here are my thoughts to post #2

1. Transition This was indeed the intended behavior I needed this plugin for.

2. Effect I hadn't thought of this use yet.
I didn't go with offering a checkbox to hide the last marking as hiding it on the score is hardly more effort (select + press V) and it kept my interface clean. (Also, I'm lazy…)

So rather than doing that, I could perhaps add a field for 'restore tempo text' prefilled with 'a tempo'. Then treat it like the staff text field is now:

  1. If left blank, plugin works as it does now
  2. If filled, instead of placing an end tempo marking with ticks do the following:
    1. Place the tempo marking
    2. Set the tempo to the start tempo value
    3. Set the text to whatever is entered into the field
    4. Change the text style to be the 'Technique' style (currently not supported by MuseScore, but a PR for that is pending)

Reply

• Mar 22, 2016 - 12:22

It would indeed be very easy to hide the last marking. So fixing the original issue (the plugin overwriting the 4=120 marking) might do the job. For the Effect case, the user would just have to choose the selection appropriately and hide/adjust the final marking.

While your "restore tempo text" approach perfectly follows my description of the Effect type, in the score, I was referring to in the original post, the situation is still more complex. I first have a sudden slowdown, and some measures later, the aforementioned ritardando. The next thing to happen would be a "Tempo Primo". I could enter this into the text field, but the desired tempo would not match the start tempo given to the plugin, because there already was an earlier slowdown. So I would have to adjust the value manually, or we'd need still another UI element...
I admit this is a quite complex situation, and your "restore tempo text" idea will be useful in a lot of cases. But, as I said, I feel, fixing the original issue might be good enough and help to keep things simple. After all my approach to classify tempo changes turns out to be overly simplistic ;-)

Reply

• Mar 29, 2016 - 16:21
Severity ⇒
Status (old) active ⇒ fixed

Improved detection for the placement of the final tempo marking with release 2.3 (https://musescore.org/en/project/tempochanges)

I figure the 'a tempo' option would probably require almost as much user effort to input via the plugin than to input it manually in MuseScore; If anyone begs to differ, feel free to open a new feature request to discuss.

Reply