See also [#https://musescore.org/en/node/285591]. One of my proposed partial fixes there would make it so disabling autoplace would do this, no reason setting it invisible couldn't have the same effect.
“Interface” is too broad a term, it encompasses both UI and UX issues. Even UI is too broad really, that’s why “graphical” is intended to help clarify (eg, the G of GUI).
But no doubt these distinctions make sense only to software insiders, and possible even then, they involve subtleties that may only register with native English speakers. And still can be easily misinterpreted.
So, feel free to propose alternatives, but I think the more appropriate place is on the forum, or perhaps on Telegram.
Whatever reasons you may have for wanting to hide an accidental, I have my own reason for wanting to fix this issue, and it has to do with the playback of microtonal accidentals. Each microtonal accidental has an amount (in hundredths of a semitone) by which it should raise or lower the sounding pitch of the note, but this value is ignored during playback. The tuning of a note can easily be automatically adjusted to account for any accidental attached to the note, but for reasons that I will not go into here, getting microtonal accidentals to apply to subsequent notes on the same staff line within the measure is complicated, to say the least. A reasonable workaround might involve the use of invisible accidentals, so long as they didn't take up any extra space. https://github.com/musescore/MuseScore/pull/6100 addresses this particular issue.
This skips allocating space for accidentals if marked invisible
or no autoplace.
For accidentals marked invisible, they also don't affect stacking
of multiple accidentals._
Comments
See also [#https://musescore.org/en/node/285591]. One of my proposed partial fixes there would make it so disabling autoplace would do this, no reason setting it invisible couldn't have the same effect.
For the record: anything relating to layout is by definition "functional". The "graphical" setting refers to the UI only - the appears of buttons etc.
In reply to For the record: anything… by Marc Sabatella
Then I suggest we change this "Graphical" word, I don't think this is a proper word for UI either.
It is "Graphical (UI)", and as such clear enough
In reply to It is "Graphical (UI)", and… by Jojo-Schmitz
It isn't to me. Why use "Graphical" which can be easily related to "drawing", "painter", "pixel", while the intended term is "Interface"?
In reply to It isn't to me. Why use … by Howard-C
If I'm not wrong, it's graphical because the user interface uses graphics instead of command-lines.
In reply to See also [#https://musescore… by Marc Sabatella
Looking forward to it!
“Interface” is too broad a term, it encompasses both UI and UX issues. Even UI is too broad really, that’s why “graphical” is intended to help clarify (eg, the G of GUI).
But no doubt these distinctions make sense only to software insiders, and possible even then, they involve subtleties that may only register with native English speakers. And still can be easily misinterpreted.
So, feel free to propose alternatives, but I think the more appropriate place is on the forum, or perhaps on Telegram.
Whatever reasons you may have for wanting to hide an accidental, I have my own reason for wanting to fix this issue, and it has to do with the playback of microtonal accidentals. Each microtonal accidental has an amount (in hundredths of a semitone) by which it should raise or lower the sounding pitch of the note, but this value is ignored during playback. The tuning of a note can easily be automatically adjusted to account for any accidental attached to the note, but for reasons that I will not go into here, getting microtonal accidentals to apply to subsequent notes on the same staff line within the measure is complicated, to say the least. A reasonable workaround might involve the use of invisible accidentals, so long as they didn't take up any extra space. https://github.com/musescore/MuseScore/pull/6100 addresses this particular issue.
Fixed in branch 3.x, commit a8819878ed
_fix #305487: invisible accidentals take space
This skips allocating space for accidentals if marked invisible
or no autoplace.
For accidentals marked invisible, they also don't affect stacking
of multiple accidentals._
Fixed in branch 3.x, commit 4a053fca49
_Merge pull request #6100 from mattmcclinch/305487-invisible-accidentals
Fix #305487: Invisible accidentals take space_
Automatically closed -- issue fixed for 2 weeks with no activity.