When editing time signature properties, only the last-clicked instance is actually changed

[navickasm]

Describe the bug When selecting all time signatures in a conductor's stave, when one goes to edit their properties, the edits only apply to the individual time signature that was most recently clicked.

To Reproduce Steps to reproduce the behavior:

1. In a new project with multiple instruments, click a time signature so that all of them turn blue (i.e. selected)
2. Select "time signature properties"
3. Change the appearance to cut time

Expected behavior The settings changed should apply to all time signatures, as they are all selected.

Platform information

• OS: Windows

[svetter]

I've recently run into this issue as well and would like to try fixing it (first time contributor). Before I do that, could someone from @musescore give some basic direction to what the UX should look like?

I would argue that editing the signature of all instruments at once should be the default, not least since you can't even select the time signature for a single instrument. So my suggestion would be to change the existing action and button to editing all at once, and adding a second action to the context menu and button to properties tab which read "Time signature properties for this instrument..." (or similar) and have it behave accordingly.

[cbjeukendrup]

not least since you can't even select the time signature for a single instrument

You can, by holding Ctrl/Cmd while clicking on it.

But I think that's even more reason to edit the time signature for all instruments at once in the time signature properties dialog. If the user wants to edit it only for specific instruments, they just select those individual time signatures using Ctrl/Cmd, and then the time signature properties dialog should edit only those selected ones.

The only difficulty about this arises when not all selected time signatures have the same values. This is for example the case when local time signatures are present, i.e. some instruments have a different time signature than others. (These can be created by holding Ctrl/Cmd while dragging them to the score from the Palettes.) So for that situation, a solution should be found.

I know that @avvvvve is working on a big research/redesign project about the whole UX around time signatures, but I believe that is not finished yet (correct me if I'm wrong!). @avvvvve do you think it's still worthwhile to work on this specific fix in the meantime?

[svetter]

Thanks for correcting me, I didn't know about the Ctrl/Cmd+Click - and also for providing the context of current developments.

As for the problem with editing differing time signatures together, would it make sense to populate the dialog with the current state of the clicked instrument's time signature (or the one clicked most recently) - just like it is at the moment - and then just applying the new signature properties to all selected instruments when the user hits OK? Seems to me like the most intuitive solution.

[avvvvve]

@cbjeukendrup Yeah, that redesign is still in progress, but fixing the current selection/editing behavior will surely need to be done. If it's simple enough to implement, I don't see an issue with you working on this @svetter!

Here's how I'd expect it to work:

• Maintain current selection behavior for non-local time signatures (i.e. clicking selects time signatures across all instruments, Ctrl/Cmd + Click selects/deselects individual time signatures)
• Changes made in the time signature properties dialog should affect all time signatures that are visually selected in the score.
• If you've edited the properties of a non-local time signature on one instrument but not others, it should still get selected as part of the time signature "group".
• NEW: If a local time signature is added to an instrument on the same measure as a non-local time signature, clicking the local time signature should not select any of the other time signatures in other instruments at the same time. Conversely, clicking the non-local time signature should select every time signature except for the local time signature. That way, you can easily edit the properties of the non-local time signature on the whole without affecting the local one. The local time signature can be added to the selection using Ctrl/Cmd + Click.
• NEW: If there are multiple local time signatures on different instruments at the same measure, selecting one does not select the others, even if they have the same value/properties.

Sound good?

[svetter]

Yup, thanks, that should give me all I need to take a stab at it. No promises of course, I can imagine running into some complexities beyond my first-time-contributor pay grade.

[svetter]

I have another question: What about applying the changes to different scores? At the moment, changes made seem to only be applied to the currently open score, whereas I as a user would actually expect changes I made in the complete score to also apply to all parts and vice versa. Is the fact that this is not happening on purpose? Should it be changed?

[cbjeukendrup]

It is by design that editing the properties of selected time signatures in a score only affects those time signature in that score. However, you can Ctrl+Shift+drag a modified time signature to the palettes, and that should preserve its properties when adding that time signature to a new score.

[sammik]

@cbjeukendrup Are You sure, it is by design, that changes made in score are not applied into parts? If so, I would expect "link/unlink" option.

Now it is, at least, inconsistent, some properties are linked (signature text), but others are not (beam gruping).

https://github.com/user-attachments/assets/fa0e378b-fd24-4468-bd77-baf232e3cf9b

[oktophonie]

For most properties, by default, changes made in the score will affect that item in the parts; changes made in the parts will affect only that part, desychronising either the position or the style/appearance of the item from the score. Some properties are not desychronisable so changes made in any place will affect all instances.

Until https://github.com/musescore/MuseScore/pull/24014, no changes made to time signature properties in the score weren't propagating to parts at all. Changes to text now do, but changes to beam groupings still don't seem to be, which is a bug for sure. Whether @svetter wants to look at that is up to him!

But the other question here is whether time signature properties should be desynchronisable between score and parts in the first place. I can maybe imagine some rather exotic niche use cases for doing it with the text, but with the beam groupings..?

[SteveBlower]

I can maybe imagine some rather exotic niche use cases for doing it with the text, but with the beam groupings..?

Here is an imagined case for desynchronised beaming:

A score might have the vocal parts beamed to match instrumental parts with the same rhythm and so make that similarity more obvious, but the individual vocal parts would be un-beamed for singers that are more familiar with that convention?

I can't say I have ever seen that but I can see a potential advantage.

[svetter]

It's difficult because you'd probably want to keep the option open but not make it confusing and unintuitive for everyone else. That would mean keeping time signatures completely in sync across scores by default but having some method of breaking sync. How would that look like though? A checkbox in the dialog?

[wizofaus]

A score might have the vocal parts beamed to match instrumental parts with the same rhythm and so make that similarity more obvious, but the individual vocal parts would be un-beamed for singers that are more familiar with that convention?

I'd say the only times this happens is when a conductor is using a more modern edition of the full score that uses metrical beaming, whereas vocalists are stuck with older editions of their vocal scores that use syllabic beaming. It's never a desirable outcome.

[svetter]

Can we get an official adjudication from @musescore on the question of synchronisation between main score and parts?

[oktophonie]

@svetter Beam groupings should synchronise between score and parts. Appearance can be allowed to desynchronise (as it does currently), even though I can only imagine this being useful in very specialised circumstances.