J-key should change spelling of subsequent notes in tie

Yes, this is a known limitation of that command. See #54501: Tied enharmonics incorrectly notated. Currently, I think the only workaround is to add an accidental manually from the Symbols palette ("Z"), although maybe someone can come up with something more clever.

I use a slur. Then I flatten it until it is as flat as a tie. I know this is technically incorrect, but the optical distinction between ties and slurs is not that important in practice (in handwritten scores you'd never be able to see a difference, and very few people will notice the difference in my score when they are actually using it to play the music). The advantage is that this works with playback--well, if you disregard the tiny pause--while an accidental from the symbols palette will give you a half tone shift causing shrieking dissonances in most cases.

The other solution would be to notate the enharmonic change after the end of the tie. Disadvantage: Technically incorrect notation if the enharmonic change takes place in different locations in the various voices. However quite a few composers don't seem to care: They probably try to achieve well readable situations for every player.

You *could* get ties to playback reasonably by using the Inspector to silence the second note, or lower its pitch, and/or use the Pianoroll Editor to lengthen the first note. But indeed, using a slur probably makes sense.

I am removing "duplicate" status from this bug, because etranger is not describing the same bug as #54501.

Here is what is happening. Let's say I have the note C# tied:

I want to turn that into a tied Db instead, so I select the first note and press J. Here is what I get:

But I was expecting to get:

MuseScore should function like this: Pressing J on a tied note should switch to the enharmonic equivalent on that note and any following notes it is tied to. Any preceding tied notes would remain at their previous enharmonic equivalent. This would allow the user to change the enharmonic of just the ending tied note, for example, which is useful when changing key signatures.

Current workaround: instead of using J, select the first tied note and move it up and down using the arrow keys. Cursor up will get you sharps, and cursor down will get you flats. So if you want to turn a C# into a Db using this method, you would press UP (turning it into a D) and then DOWN (turning it into a Db).

Well, the *bug* is the same bug - the accidental that should display on the second note is not displayed. What you are asking here is, in addition to a fix for that bug, a new feature: having the "J" command change not just the current note but subsequent notes as well. It's a reaosnable request, although some I'm sure would actually prefer the current behavior. Either way, though, the bug needs to be fixed.

What puzzels me is that your ties look like slurs, as they reach almost to the center of the noteheads?

These are normal for single-note chords. The attachment point is only slight inside center, but is closer to the notehead vertically, and arces less, so it still fits within a slur on the same side of the note.

In regard to people preferring the current behavior, I would be really surprised if this were indeed the case. Wanting notes connected by ties to all share the same enharmonic equivalent is the desired result in 99% of all cases. When I am editing a score with lots of syncopations, for example, I have to do twice the work when changing enharmonics on tied notes. The cases where I want a note to tie to the other enharmonic equivalent are extremely rare (I've personally only ever done this in one song).

As I understand it the bug is that two different ways to do the same thing--what you'd think is the same thing, namely enharmonically changing a series of tied notes--give you different results. If you use arrows you get the result you expect intuitively: The tied notes--being in fact one note which are tied either because a measure line forces the tie or because of readability considerations--change in concert when you use the arrow keys. With the J shortcut however, only the first note is changed and the tie stays attached to it but presumably no longer to the following note--which is now a half tone off. I wasn't aware of this because the arrows are my way of doing this, but I just tried.

Here is a second workaround though: Select the entire series of tied notes (select the first, then shift-select the last note) and use the J shortcut now.

So I am not sure there is anything urgent to fix (except that the middle picture above is clearly incorrect notation). But Musescore treats tied notes like one note generally (also e.g. when you add an accidental from the palette) and the J key appears to be the exception.

One may consider changing the accidentals for all notes of the same pitch in the same measure. That would match the rules on accidentals. But I think it is easier to avoid typesetting errors the way it works now (because I am getting an alert: I change an f to an f sharp and the next f in the same measure will automatically display the natural sign--with rare exceptions). It goes to your point that Musescore can't guess the intent of the user.

Regaridng the current behavior: the reason I assume many users would prefer the current behavioris not that I think it is common to ties Db tied to a C#. It's that if you want a Db tied to a Db, you'd just enter that directly - you'd never need to user the J command at all. The J command is normally needed only in very uncommon situations - like to change B to Cb in the key of C, or to change F# to Gb in the key of G. And even then, there are other ways of entering these notes that don't require use of the J key. So most users will almost never use this command. The case of wanting a Db tied to a C# is actually one of the very times most people would ever need to use the J command, which is why I think many might prefer the current behavior.

I guess MIDI input is another situation where people might end up needing the J command a lot, but that probably applies to only a small percentage of users

Aah, that makes sense, as I always use MIDI input when composing in MuseScore. It's just so much faster for me. The downside, of course, is having to go through afterward to fix the enharmonic spelling.

I also get students who put in the wrong enharmonic frequently, and then I must have them go through the score and change all of the G-flats to F-sharps, or what have you.

I start suspecting that we are all talking at cross purposes here. I misunderstood the question initially myself but when Chris posted the three pictures I think I understood: He wanted to have the J command apply to the entire set of notes that are tied together as opposed to just the first note (The bizarre thing seems to be that while the notes look like the middle picture the sound is like the desired third--or the initial first--picture. If I understood him correctly). I think this is reasonable, especially since tied notes generally behave as one note, e.g. when an accidental from the palette is added or when the up / down arrow keys are applied. You don't have to select all tied notes, the first is enough to affect the whole set.

But it seems also quite likely that some of the responses still deal with a different problem though I am a bit in the fog as to exactly what problem.

Let me try to be clear:

Of the three pictures posted, the second is what we get now after pressing "J", and it is clearly a bug - the same bug reported in #54501: Tied enharmonics incorrectly notated as far as I can see.

The question is what should happen instead. I believe the "correct" behavior would be just like that second picture but with the sharp now showing on the second note. Chris (? a good way to address you?) is wanting it to instead look like the third picture. Both are valid expectations, really, but to me, the *bug* is not displaying the sharp; modifying the behavior to actually change both notes is more of a separate feature request.