Tempo markings should be linked to the chord or rest they were created on, not to fixed positions

• Jan 9, 2021 - 11:20

Tempo markings can't be copy-pasted along with the music they belong to. This makes no sense.

Tempo markings should be linked to the chords or rests they were created with reference to (ie. the chord or the rest the user selected before adding the tempo marking), not to their position (measure # / beat #) in the score.


No, and they are not linked to a measure either.
Tempo has got nothing to do with noteheads, but all with their position in the score, the measure and beat inside that measure.

In reply to by Jojo-Schmitz

They should be linked to the chord/rest because it makes sense musically. I know that the developers don't want to think with the mind of a musician, but this does not change the fact that the tempo markings should be linked to the chord/rest, not the position/beat in the measure. When I move a 10-measure-long motif with a lot of tempo changes to a different position (e.g., now it begins at beat 1 and I want the whole section to begin at beat 3), I want the tempo changes to move along with the music, and I don't want to manually restore all tempo markings one by one.

I know that the developers don't really care what I want, but this is what I want because this is what's logical (for a musician's mind).

In reply to by szekelyga

You presume a lot about the intent and internal mind of all involved developers/contributors, including shaming their musical capabilities.

As you by now are aware, just anchoring them to a note/chordrest instead of the beat would not solve the copy-paste issue from a programming point of view. Moreover, it would create an entirely different can of worms in ensuring that a tempo marking still acts as a system element (thus appears at the top, rather than the anchored position); that it doesn't conflict with markings attached to other staves (or even voices) because that now becomes a possibility; that it still has to be copied into all parts when those are created.
All things that would become a lot harder by anchoring a system element not to the time position at system level, but to a specific chordrest instead.

When you copy such a motif and paste it, you expect those markings to be copied over as well; but other users might expect other things. Even yourself might in a different scenario (such as copying that motif to the same time position, but a different staff).
If you glance at the linked issue, you might notice that all of the developers and contributors that so far participated in discussions about this all agree that this should be made possible. But yes, partly due to the large amount of work involved in making this copy/paste work decently, no contributor with the right skillset has been able yet to free up enough time to make it so.
Not being able to free time up is hardly the same as not caring about user feedback and desires.

At least I hope you feel a bit better after venting the frustration that such a request has been in limbo for such a long time.

In reply to by jeetee

I made a request. My frustration was mostly caused by the response. A simple "so you want tempo markings to be anchored to the chords/rests instead of measures/beats - this has been requested already: link. Thread closed." would've been a satisfying answer. Instead, I've been given some linguistic lecturing on how the terms I used were incorrect. No, thanks.

In reply to by jeetee

That's a good analysis jeetee. Having recently mucked around with the MusicXML files in MuseScore, I think I can say that the MuseScore technical design would make copying tempos attached to notes quite difficult. It's all to do with the hierarchical XML structure, and tempo is considered more 'system' than 'note' (to roughly describe it.) To the OP: take a look at the uncompressed MuseScore score files(they're just XML, so reasonably easy to read): you can see the tempo design concept in there.

In reply to by Lofo

To be fair to the OP though; he shouldn't really have to care about those technical details. He just want that tempo marking to copy-paste and that's is, how we do so is not a lot of concern to the end user.

I find it useful to provide some of the insight into the how to those users as it might help them understand a bit about why something seemingly very simple (after all, we do copy a lot of other stuff already) isn't in there. Giving such a peek behind-the-scenes might also help in terminology and ensuring a request is understood in a good way.

If he wants to check out the xml-structure to verify the given information, then that's fine. If he just considers this technobabble and doesn't care about the "how", then that's fine as well; it's not an end user's job to understand all of the why.

In reply to by jeetee

I would add, though: making it so tempo changes and text elements like that copy with the range would actually be trivially easy. Key signature and barlines change only a little harder. But time signature changes would be fairly tricky. Also, someone would need to design and implement the user interface for how you select whether these get copied or not, so that in the many cases where you don't want them copied, you can still have that behavior. Probably that somehow goes into the selection filter, but there is also talk of someday completely redesigning that.

So anyhow, it's not that copying tempo marks specifically is difficult to implement, but that it opens a can of worms that really should be solved as one cohesive design.

In reply to by szekelyga

For the record, yes, sometimes you - or any musician, like me - might want to copy tempo markings along with the notes. Other times you - or I - very definitely do not. The most obvious example: the tempo marking on the first note of a piece, or a movement, or any sort of section of a piece. You would virtually never want this duplicated if you then copied that first phrase of the piece.

It is precisely because we developers are musicians and try to think about all the use cases that come up in real music that the decision was made not to copy these by default. But we all recognize there are other cases where it would make sense, and we all completely support the idea of someone someday adding this feature. It's open source software, so we're all just waiting for a volunteer who is sufficiently motivated to design and implement how this would work,

In reply to by Marc Sabatella

Interesting point: I thought about when I've copied passages - either to directly copy notes/rests, or to copy and edit the note pitches (useful when the note durations stay the same), and yes I would say usually I would not want the tempo markings copied along with the passage. So from my perspective, I can honestly say I'm not sure which I prefer: tempos copied or not as in my experience both sides have their uses.

In reply to by Jojo-Schmitz

What you write makes no sense, because tempo markings can only be created when the user selects a chord or a rest first. So if they can be CREATED only with reference to a notehead or a rest, why can't they be MOVED along with reference to the same notehead or rest (just like dynamics, texts, articulation, etc.)?

In reply to by szekelyga

Yes, your point is a fair one and has been requested before.

If MuseScore did not have playback capabilities, it would be a simple request -- and tempo markings would be treated as ordinary text.

However, for the additional playback feature, though, a computer has to be further reckoned with - and computers are sticklers for detail. (They don't know about music by listening to it.) Hence the use of programmatic terminology in the forum. After all, developers are wearing two hats.

Do you still have an unanswered question? Please log in first to post your question.