Defeat automatic accidentals?

Not really a way to defeat it, but just press the Up or Down array to put the notes at the right place or use a MIDI keyboard to enter the right pitch directly.

I apologize for the oversight, but I discovered this thread after noticing the feature request in the issue tracker.

So, I posted there a longish post about why I see the current program behaviour possibly preferable (even if not perfect) to the suggested change, suggesting a fair amount of prudence before changing it.

My main point there is that the choice is not between automatic addition of accidentals or not, but rather between the automatic addition of accidentals a) to the visual representation of the notes (current implementation) OR b) to the note implicitly intended pitch (feature request). More details on that in that other post.

In summary, I believe the current implementation strongly preferable while modifying (editing, revising) already written notes (rationale: please do not change anything 'underneath' or silently, rather if necessary change the visual representation, so I'm alerted).

For new data entry, I see the point and I have no strong preference over a) or b) above. However, choosing b) in this case would bring some behavioural inconsistency and I'm not so sure b) would systematically guess right more often than a) (in my case, probably it wouldn't).

So, I would probably vote for a user-selectable preference, notwithstanding the correct remarks by David about multiplying preferences.

Thanks,

M.

P.S.: among the various reasons for the change, the fact other programs do differently seems to me the least compelling: I care little what other do, as long as there is a reason for doing in a certain way; and in this case there is probably one, at least under some respects.

Bill-G makes several good points, but other arguments could be made as well. Please note: I'm not 'taking side' or saying he's wrong, not at all, simply that there can be more than one perspective (that why I prefer adding a preference to simply changing the program behaviour).

As I said before (but I thing it is worth repeating), the choice we are facing is not:
    between (automatically) changing the 'music' or not;
the choice is:
    between (automatically) changing its visual representation OR its substance;
given the conventions for accidentals of modern Western musical notation (which are in most case enforced by default by MuseScore), either one or the other must be done.

Bill-G prefers the second alternative (altering the 'substance' to keep the 'surface'); I think there are cases when the first (keeping the 'substance' even altering the 'surface') is preferable. This is more evident during editing of already input music. I'll take Bill's example of the 3 Bb in a measure.

1) While entering a score, I entered 3 B in a measure (assuming the Bb is not in the key signature; if it is, there are (almost) no problems):
2) Later, I discover I made a mistake (I constantly do mistakes) or, if I am the author, I change my mind and I go back and lower the first B to Bb (down key)
3) MuseScore changes the first B applying a flat (OK)
4) It then 'needs' to change the visual representation of the second B, which is still B natural, adding a visible natural sign to it.

I strongly prefer this current way of doing, because:

a) MuseScore has no way to tell if the other B's also need to be flattened (this may depend on style, period, ...), so I prefer it does not touch at them, keeping them natural;
b) the visual change (the natural sign appearing before the second B) is a very useful reminder that the status of the following B's need to be considered: sometime they may need to be flattened too (which I prefer to do, without delegating it to a program); sometime not, in which case the natural is already correct.

So, a user-selectable preference may accommodate both Bill's needs and mine. I have no problems if this preference be set by default to a 'new editing way', as long as I can re-instate the current way.
________________________________

This is for editing. In data entry mode, I have no strong preference, as long as the behaviour of the program is predictable.

In fact, I am not at all sure that a 'surface'-oriented data entry (a B entered after a Bb is to be intended as another Bb and silently converted) would guess right more often than the current 'substance'-oriented data entry (the second B is a B, regardless of what comes before).

If there is a consensus for the former and the current data entry way is changed, OK, I can easily live with it. If another user-selectable preference can be added for it, good; if not, (almost) good as well.

What I feel important is: please do not remove the current way of editing!

Thanks,

M.

In the previous post, I have on purpose left out an important point made by Bill, to discuss it in more detail.

MuseScore is a notation program more than a sequencer: this is a very good point and, in fact, I sometime believe that recently there has been a bit too emphasis on sequencer features when some notation issues still lag behind.

However, I see MuseScore also as a music coding program: a way to store music information which can be then printed, played back, converted to other formats, from which extract parts or perform other manipulations.

For instance this applies to the "inefficient user" route described above by Bill:

To flatten a B, he describes using sometime the 'flat' icon and sometime the [Down] key. They have different effects (this might be made not very clear in the documentation, but that can be improved):

a) the [Down] key lowers the note by a semitone; then the note is drawn according to modern Western music conventions for accidentals.

b) the 'flat' icon (or its shortcut '-') marks the note as an unconditional flat note: this note will always have a flat (and be a flat), no matter what happen before it (of course, as long as the note itself is not changed by further editing). This comes very handy in all the cases (ancient music, serial music, extra-European music) when the modern Western music notation conventions for accidentals do not apply or are too narrow, or also when one is reproducing a specific original, and so on.

In fact, the notes we end up with are quite different (even if they sound, and often look, the same), with different properties and behaviours; i.e. they are different 'coded entities'. This 'coding' difference, once entered, has to be kept and, possibly, exported to other media, exposed to manipulations, and so on..

Both 'coding' are useful and necessary; removing (or altering) either of them will severely maim MuseScore, methink.

I believe that MuseScore should be usable for all kind of music (well, as many kinds of music as possible); privileging the modern Western notation conventions is reasonable (and it is already done in many cases) as most users will remain within them. But options should be left to go 'outside'.

M.

I just wanted to ask, what to current state of this issue is?

Maybe both ways make sense in their own way, i would strongly prefer to have an input method, that reflects the way accidentals are handled in notation rules: an accidental takes effect for the whole rest of the measure it is placed in, so I think, note input should also behave this way.

When in any sharp key signature (like G major) and the user presses the 'f' key or puts a note on the 'f'-line, the result is a f#. The same thing should happen, when the key signature does not contain an f#, but an f# appeared in the same measure earlier.

This is confusing for beginners on musical notation, but notation rules are pretty clear on that.

Either way, if there's automatically placed accidentals or not, the most unpractical thing is the fact that there's no easy way to remove an accidental during note input. The only way I found, is to leave note entry mode, select the accidental with the mouse and press the 'delete'-key to remove.

It would be a great improvement for note entry, if there would be a possibility to add and remove accidentals quickly, say press '-' to add a b, press again to remove it, and likewise press '+' to add a sharp, or press '+' to remove a sharp that is already there.

Alternatively there could be a 'remove accidentals' button next to the 'b', '#', and similar buttons.

I read this thread and other postings to the forum and entries in the issue tracker, so my intent was not to bring some very new aspects to the topic, but to reflect the fact that many people have this problem.

Just to clear the point of view I'm writing from: I have some education in computer sciences too but primarily I'm discussing this from the perspective as a professional musician, so it is mostly about
a) what would a musician expect, who has used notation software before, maybe different programs, and so is used to a certain input method
b) what would a musician expect, who has not used notation software at all

I should also emphasize, that my priority is the use of musescore as _notation_ software, which is used to produce a print layout of a score and use it for playing, not a _sequencing_ software, which you use for putting music together you can listed to on your computer.

I use sibelius for many years now. I have tried finale and capella a little bit, mostly to quickly exchange scores with colleagues, who are using it. In the past, I had several requests from students and colleagues, who asked which notation software I would recommend - so in most cases I told them to use musescore before buying anything, and find out if it's sufficiant.

Most people asked me, after a few beginner's problems which could be solved easily, why accidentals don't come out as expected and what to do against it.

I respect the fact, that there are different approaches to the input method and all of them are _correct_, there's not a thing as incorrect behaviour here, the question is: what do users expect. As it turns out in fact, there seem to be different types of users - or groups of users with distinctive goals and educational background - that expect different things from the software.
Most people I deal with, are more or less well educated in music, some of them professionals, most of them part-time, some amateurs, but all of them seem to use the software as a replacement for pen and paper and use it like they would do with handwritten music. Which means: write one sharp in front of a note -> expect it to have effect on the whole measure; put a note on a line with a mouse-click -> only the note appears, no natural sign.

I see the problem of the current input method not in the fact, that it's wrong - which it is not - or that it is not the sibelius-style input method; the problem is, the distinction is not clear.

Let's call the to methods 'absolute' and 'relative' - which is not exactly, what they are about, but for easier discussion.

strictly 'absolute' should be:
- one key produces one note, always the same, no previous accidentals take effect
- this leads us to the question: when every key produces only one note, should every note have a corresponding key?
- so we could have a key for all 12 chromatic tones and
- call the input method 'piano keyboard'

strictly 'relative' should be:
- when I put a note on a certain line or inbetween, I can expect the software to do that and nothing else
- key signatures have global effect, accidentals have local effect in their measure, input should respect them
- when we talk about keyboard input, we should either have
a) tone name input: 'C' is the c-line, no matter which key we are in, so it could result in C double-b, C b, C nat, C #, or C double-#
b) some kind of relative solmization: there's still 7 key, but the lowest key produces always the tonic (a D in D-major), the third one would procude a F# in D-major. one could use d, r, m, f, s, l, t, (as in do re mi, etc) for that.

currently we have a mixture of both
- note input respects the key signature, so there's not always the same note with the same key. The 'A'-key can produce A b, A nat, A # depending on the context of the key signature
- note input does not respect accidentals, so as long as the key signature does not change, there is in fact the same note for the same key, but it is _not_ the note, that the keys name implies, an 'F' can still produce a F#
- the most confusing thing is though: mouse input. When notes are created with the mouse, the behaviour is still as if the corresponding key had been pressed. So when I click on the A line, where a # was previously, I expect a note to appear and be played as A#, but musescore produces a natural. Although, when I put a note on the F line when there's a F# in the key signature, there's only the note drawn and it plays as F#. This is not easily explained to musescore-newbies.

So, sorry for the long text, but I would like to suggest:

Options for four keyboard input methods:
a) piano keyboard: chromatic scale on to rows, like Y,S,X,D,C,V,G,B,H,N,J,M
b) tone name input, relative: no automatic accidentals produced during note input
c) absolute tone name input: having the key signature respected makes sense, so this would be, what we actually got
d) relative solmization: for educational purposes

One could combine b) and c) into one 'tone name input' method and have options, as suggested be previous posters.

Default options should be:
Mouse input:
Default should always be like relative tone name input - _no_ automatic accidentals
optional there could be different behaviour

Keyboard default could be:
c) (or general 'tone name input')

Pros:
- musescore would have some sophisticated choices for the input method, this what most other software lacks of
- default behaviour would be intuitive enough

Contras:
- keyboard shortcuts would be different and so would the whole keyboard layout change, when the input method is changed

To conclude my wishlist:
MuseScore is designed for easy and intuitive use, and in fact, most people can produce first simple scores just by trial and error. And we have many non-professional enthusiasts, who have no or very little experience with musical notation so far, and put together their own songs with musescore.
But we should also have in mind, that there is many musicians - semi-professional and professional - who have waited years for a decent open source notation software. Maybe we will not hear very much from those people, because when you test software for professional use, you usually give up very quick and take another solution, when an open source software doesn't fit your need. So most of them will hop directly to capella, or one of the bigger one's, depending on budget and frequency of use. And although I have to admit, that often I switch to sibelius for more complex tasks (especially when time is an issue, for example in bigger scores, I choose the quickest input method), I still try to use to musescore as often as possible. But there's still some issues which would make it easier to make the transition to musescore as the primary notation software; or intruduce people to it, who haven't used other software so far and keep them from doing so.

As always:
best regards, sorry for long post and bad english

@fnbecker:

About your four proposed input methods with keyboard:

a) piano keyboard: if we go at this, someone would probably need to distinguish, during input, C## from D, Dbb from C and so on (the point has already been raised in this thread). This gives a total of 35 keys (##, #, nat, b, bb for each of the seven grades; 31 if we discard Cbb, E##, Fbb, B##): I'm afraid it would be rather unpractical...

b) tone name, relative (nickname: "no auto accidentals"): strongly requested.

c) current method: as Werner himself said 2 years ago, this method as some inconsistencies (key signature is followed, previous accidentals in measure are not); in practice it does not satisfy completely neither the 'mainstream' music writing nor special needs like atonal music. If thing are changed, I see little need to keep it.

d) 'solmisation': for God sake, no! Otherwise, I would ask for another, real solmisation input method, with 6 keys for the 6 hexachord chordae, with all the hexachord mutation rules, una nota super la (and maybe a soft 'keyboard' with the manus Guidonis <g>)....

So, IMHO, this leaves us with just one input method with a reasonably wide consensus (not universal, but it is often difficult to please everybody), i.e. your b).

(Side note: Having multiple input methods sounds to me more as marketing hype than a real feature, but this is just my opinion; in case, rather than preferences, hard to find and to explain, I would propose a toggle somewhere in the menu / toolbar: equally hard to explain, probably, but at least, easier to play with.)

Summarizing:
*) Keyboard input: 7 keys (like [A] to [G]) always generating a note without accidental, taking into account the key signature AND any previous (and relevant) accidental in the measure, across different voices of the same staff.
*) Mouse input: clicking on a 'note place' (staff line or space) also produces the same kind of note as described above.

In any case, as said above (by me, by Marc and by others), this would only apply to entering new notes. Editing of existing notes (already entered) should remain as it is now and should not change the pitch of any other note (before or after) already there (yes, I am taking side in the religious war, because not changing is easier, see below).

This was the kind of consensus reached in 2010. If we can agree on it again, I believe to be able to provide the core developers with a proposal of code implementing it. I cannot promise any delivery time, as I do this on my free time, but I feel somehow confident.

M.

Yes. And I'd like to add, I feel this would be *very* helpful.
http://musescore.org/en/node/7314

A side note on E#, B#, Cb, Fb.

In V2, a way already exists to enter those notes without recurring to the palette symbols (as Marc said above, palette accidentals have subtle differences from the accidentals entered with the up / down arrows).

For instance, to enter E#:

1) Enter E (in whatever way)
2) Press up: you get an F.
3) Press the key for "Enharmonic Down"; (default is J, I think, but it can be configured)
4) Enjoy your E#!

"Enharmonic Up" (G) and "Enharmonic Down" (J) cycle in one direction or the other across all the possible enharmonic representations of a pitch; for the above example: E#, F, Gbb, E#... (up) or Gbb, F, E#, Gbb, ... (down).

It is not as automatic as Marc asked for above, but it come closer; doesn't it?

M.

P.S.: The above steps are from a "didactic" point of view (for E#, start with an E); of course, it is possible (and quicker) to directly enter an F and convert it to E# with "Enharm. down".

Hi,

I have a prototype code implementing the specs defined by David above. Now, as we are dealing with a very basic feature, some more testing is needed before posting it (it is always possible I overlooked disastrous side effects of such a deep change).

An additional good new is that the code is rather neatly layered in 3 steps: start by ignoring any accidental / take into account key accidentals / take into account previous accidentals for that note (in measure). This makes easy to stop after each step and obtaining 3 input methods at the cost of one:

1) always enter natural notes (natural sings appear when required)
2) always enter notes according to current key signature ONLY (the method used now)
3) enter notes according to current key sig. AND any accidental for that note used previously in the measure (if any, of course)

but some user interface is required to choose. I would prefer NOT to introduce many changes until we know the change is not dangerous under other respects and/or does not require extensive reworking.

So, the initial release (if the core developers agree to include it) will have 3) active by default and no way to choose. Once the new method will be tested, appropriate UI can be added.

(In effect, I am speculating of not adding a preference, but a menu item: "Notes | Input method => No accidentals / Key sig. accidentals / All relevant accidentals" right below the current "Notes | Respell pitches" menu item).

With a bit of luck, we are getting near...

M.

P.S.: As far as I can tell, the "alternate input" quoted above is no longer present in V2. It currently has only one note input method.

** EDIT**

Not-so-good new: Mouse input does not seem affected by the change (yet!); only keyboard input is. More work...

I am afraid I have to give up.

The work flow for keyboard input and for mouse input is very different and, for each, adding a new (single note) chord is different from adding a new note to an existing chord. In all cases, the routines (often different from case to case) actually computing the note pitch/tpc are very deep in the call stack, where important context elements (for instance, which (diatonic) note has been asked for) are lost.

The net result is that rather deep and potentially far-reaching changes are required and the risk of introducing unexpected (and far-reaching) instabilities is significant.

Adding to this the almost total silence kept by the main developers in the issue, I do not feel confident enough to go on.

I am sorry, but this specific point seems to exceed the possibilities of an open source external collaboration.

M.