Should Note Entry Mode Exist?
I began this question on a different thread (Feature Request, "Alter Duration via Keyboard"), but after discussion, I've come to a more far-reaching conclusion: Note Entry mode in MuseScore should not be necessary, and should be removed.
Some background on the problem might help support how I've reached this conclusion. I've been trying to learn MuseScore for some time, but I've always seemed to stumble on how things were handled. In particular, how Note Entry mode worked seemed arbitrary and unpredictable.
My fundamental problem seems to be this: I expect actions to have immediate results on the object with focus. For example:
* Pressing an arrow key (Up, Down) should change the pitch;
* Pressing Shift+NoteLetter (A, B, etc.) should add a chordal note;
* Pressing an accidental shoud
* Pressing a duration (1, 2, etc.) change the duration;
* Pressing a dot (.) should add an augmentation dot;
* Pressing a tie (+) should add a tie;
For some reason, some of these are immediate actions, but others are deferred. The result is that MuseScore doesn't seem to be consistent in how it handles actions.
I suggest that these actions should always be immediate. There are a number of reasons to adopt this:
* It makes MuseScore predictable and, which aids in learning the program.
* It makes MuseScore consistant, which gives the design direction.
* It removes Note Entry mode, which simplifies the application.
Consider the situation: a user selects an action, such as an augmentation dot. Why should it not be immediately applied?
One could argue that in MuseScore, the duration is first selected, and then then the duration is selected. But why is this? As I've pointed out, it bifurcates how MuseScore behaves.
Perhaps the argument is based on the fact that adding notes is a destructive operation. Consider the scenario:
| AQ BQ CQ DQ
That is, the cursor is currently in front of a quarter note A note, and you wish to replace it with a quarter note G note. The current duration is set to a whole note, so pressing the G note results in a whole note G replacing everything in the measure:
GW |
Note that I've advanced the cursor, and placed focus on the newly inserted G note. To recitify the problem, the solution is to change the duration of the note to a quarter note by pressing the 5 key:
GQ | BQ CQ DQ
The overwritten B, C and D notes have "magically" returned. This shouldn't be a difficult behavior to implement, since it's essentially an Undo followed by another insert.
If I chose to make this a dotted quarter note, pressing . should make it so:
GQ. | BE CQ DQ
This again overwrites the overlapping following note, shortening the remaining duration.
I then want to then replace the following B with an A. Pressing A would give the standard "overwrite the next note" behavior:
GQ. AQ. | DQ
Ooops... this should be an eighth note. Press 4 to make it so:
GQ. AE | CQ DQ
Again, the "missing" C note returns.
Let's say I want to change the pitch. I could press the Up arrow, and the note with focus is transposed up a half step:
GQ. BbE | CQ DQ
If I want to alter the following pitch, I can move the cursor to the next note:
GQ. BbE CQ | DQ
Note: Actually, I'd prefer the focus to move to the front of the I beam like it does in Noteflight, but that's a different discussion.
I can then alter the duration of the note by pressing the 4 key:
GQ. BbE CE | RE DQ
I can change the pitch with the Down arrow:
GQ. BbE BE | RE DQ
At no point have I needed to change in and out of Note Entry mode. I can also perform the actions in the same number of keystrokes as MuseScore currently uses, and haven't introduced any new keystrokes.
So I've got two questions:
1. What advantage is there to entering the duration before the pitch? It seems to me that going this route causes MuseScore to behave inconsistently, and forces the creation of something like Note Entry mode. While modes are sometimes necessary (for example, Lyric and Chord Entry modes), they should be avoided, if possible.
Am I missing something fundamental? The argument that "this is the way MuseScore does it" is an argument for keeping things, but isn't - in itself - a compelling reason for keeping it that way.
2. Is there a problem with this method that I'm overlooking? If you haven't already, I'd suggest having a look at Noteflight, a free, Flash based music notation. The data entry model is very close to what I'm suggesting here, and shows that such a system is practical.
Thanks!
Comments
I should have supplied a link to the original discussion, sorry.
I'm sure that having the various modes makes a lot of sense from a programing/developmental perspective. Perhaps there is a way through shortcuts and such to basically make it more transparent to the user?
Good idea to start a new thread.
I agree with the general principle of reducing modes and reducing the barriers between unavoidable modes but I really don't like the idea of notes "magically" reappearing.
As a point of correction: all the actions you list above that you expected to have immediate action do have an immediate effect regardless of whether you are in note entry mode or not. You should also note that Werner has already implemented shortcuts for doubling or halving the note duration as mentioned in the previous thread.
In reply to I agree with the general by David Bolton
but I really don't like the idea of notes "magically" reappearing.
I put "magically" in quotes to emphasize that programs really can be smart. Replacing value with a rest seems reasonable, until you remember that it's a computer program you're working with. This is the sort of "magic" they're supposed to be able to do, to make life easier.
I've run across this in Noteflight, and found the default behavior almost always be wrong. For example (recall that Noteflight puts the focus in the front of the cursor):
| AQ BQ CQ DQ
If I change the duration of the A to a half note:
| AH CQ DQ
If then, immediately after, back to a quarter note:
| AQ RQ CQ DQ
the B has been transformed into a rest, and - problematically - I have to manually restore the note if I want it back. But why should this happen?
If I had initially selected a quarter note duration and committed to it, the B would not be transformed into a rest. Why should it become a rest because I initially chose a whole note? I've not yet committed to what the final value should be, and the program can certainly remember what the overwritten value was.
By way of analogy, consider the non-destructive "try before you buy" options in MS Office. You can select a chunk of text, and then scroll through various styles, seeing what they look like. But until you've committed to one (if any), the changes are non-destructive.
Put another way: if I wanted the B to be a rest, I'll do it myself. The computer should be smart enough to let me fiddle around with various values without punishing me for them.
Now, once I've committed to an action (i.e.: move the cursor position), I'd have no expectation that you could go back and toggle the pitch and have the prior pitch appear. This action only makes sense in the context that you're replacing the note(s) that follow the note with focus. If you ultimately decide that the note with focus won't overlap them, they should not be overwritten.
Is there a reason why this behavior is good that I'm not understanding?
all the actions you list above that you expected to have immediate action do have an immediate effect regardless of whether you are in note entry mode or not.
That's correct. What I should have said is the actions do not have an immediate, visible effect on the score.
Something I find distracting is having to take my eyes off the score and look elsewhere. This is compounded by MuseScore's habit of occasionally not rendering focus, so when I return my eyes from the toolbar back to the notes, I don't know what note had focus.
In Finale (simple entry) and Sibelius all note properties must be selected before entering pitch. For example duration, dotted or not, sharp or flat, rest or note. The advantage of this is its consistency: you don't have to wonder about which items on the toolbar you have to select before pitch and which items you have to select after adding the note to the score. Its disadvantage is the scattered visual feedback: you have to visually check multiple buttons to make sure you selected the ones you want before you add the note to the score.
In Noteflight all note properties must be selected after entering a pitch. The advantage of this is it allows you to see exactly what it looks like as you are changing or adjusting various properties. The disadvantage is what you see on the score is often wrong until you change the properties. This can be disconcerting the first few times you used it (as Lasconic mentioned in the previous thread). The order is also reverse of what people are used to from almost every other scorewriter.
In MuseScore duration must be selected before entering pitch all other properties must be selected after entering pitch. For example duration and dotted or not must be selected before pitch; flat or sharp, tie, slur, etc. afterward. The advantage of this over the Finale/Sibelius method is you only have to keep track of one thing (duration) before you see what you want on the score. The advantage over the Noteflight method is you don't see the wrong thing on the score (such as quarter note instead of half note) although it may be "unfinished" (still needs an accidental or tie, etc). The disadvantage is its inconsistency: it is not immediately apparent what items must be selected before pitch and what items must be selected afterward.
In reply to A comparison of note entry methods by David Bolton
you don't see the wrong thing on the score
Yes, this is problematic. I found that I got used to it rather quickly, and didn't really find it much of a hurdle. In comparison, coming from Noteworthy Composer, I found the idea that you couldn't "insert" into the measure much more problematic.
The order is also reverse of what people are used to from almost every other scorewriter.
The "pitch, then duration" format is used in ABC and Lilypond. I'm not sure if that should be counted as a point in it's favor, or against it. (Where are emoticons when I need them?)
I'm curious to know what sort of barrier this has proven to Noteflight. It would be interesting to perform user testing and see how long it would take someone to adapt.
Is there anyone reading this thread who's got a positive or negative experience with trying Noteflight after being used to other notational software?
For the record, I should mention that NoteFlight does have a note entry mode. If you click on a note or rest it begins note or rest entry mode. If you click on an area between a note and a rest you are in selection mode. I found I was often leaving note entry unexpected until I worked out this distinction. The barrier to enter or exit note entry mode is lower in NoteFlight. In MuseScore to have to specifically press "N" to enter or exit note entry mode.
However the design in NoteFlight does significantly reduce the number of sub-modes. Finale, Sibelius, and MuseScore all have sub-modes of note entry (e.g. note entry of quarter notes, note entry of dotted half notes, etc.). NoteFlight does not need these sub-modes.
Also for the record, I do kind of like NoteFlight's note entry although I did encounter some annoyances such as the floating note duration selector sometimes covering the measure I intended to edit and the problem mentioned above with note entry mode unexpectedly finishing.
In reply to NoteFlight has a note entry mode by David Bolton
I found I was often leaving note entry unexpected until I worked out this distinction.
I've also found this to be an irritating behavior. (If you haven't noticed by now, there seem to be a lot of things in various software programs that irritate me).
Prior to Noteflight, Noteworthy Composer was perhaps the easiest music notation software for me to use. But Noteworthy Composer has a different sort of note entry paradigm that doesn't match well to the MuseScore model.
In reply to Noteflight's disappearing I Beam by dcuny
For what it worth, I'm creating a NoteWhorthy to MusicXML converter at http://nwc2musicxml.appspot.com
And unfortunatly the note entry paradigm in notewhorthy is very linked to the model or the contrary.
What I mean is that a lot of things are missing in NoteWhorthy model, compared to MuseScore one. No "measure" element per se. Just list of notes with bar. No Chord/harmony. No voice etc... From a developer point of view I prefer a lot the MuseScore and MusicXML model.
Now I have again tried out Noteflight at www.noteflight.com. I tried it out the first time shortly after its first release but found it too limited and have not done much with it since. Having read dcuny's forum postings about Noteflight I opened the demo score and pressed "D" with the hope of directly inputting a note D in the score. To my surprise nothing happened. I had to click in the score first for the key D to really input a quarter note D; Noteflight actually has a note input mode. (The only program I have used that doesn't have a special note input mode is Capella (www.capella.de), which also has other interesting peculiarities.)
What I find most awkward in Noteflight is that when having thought out a melody to input you have to input a lot of wrong note values that have to be edited to their correct values. Noteflight also makes use of what I like to call the annoying and confusing "Sibelius principle of highlighting at note input". I can quickly summarize that Noteflight is not for me.
To answer dcuny's question "Should Note Entry Mode Exist?": Perhaps not. E.g. Capella users can obviously do without a special note input mode. But I think it is more important at this stage to improve input itself. I hope there is a possibility to proceed with the development in this manner rather than having to throw out input mode completely. What I believe both dcuny and I would like to see in MuseScore is insertion mode as an option to overwrite. Most notation programs, I think, only have one of them: Sibelius and Noteflight have overwrite mode; Capella and Igor Engraver have insertion mode. If it is only possible to have one, I would, not unexpectedly, want to have insertion mode.
In reply to Note input mode by Magnus Johansson
What do you say, Werner; is it too much complicated coding on MuseScore to make it have insertion mode? If it is, I guess I have to continue once again wrestling with Noteheads' CEO Christer Sturmark with the aim of making him do something sensible with the source code of Igor Engraver. In August I was interviewed by the business news site www.realtid.se about Igor and Noteheads, and that made Christer feel so pressured he actually updated www.noteheads.com, something he very seldomly do. Sturmark also told the news site in an earlier article that the intention with Igor Engraver is to make it into "some sort of open source software", whatever that is supposed to mean.
In reply to Werner! by Magnus Johansson
I am thinking about this for some time. Its a similar problem as changing the time signature in a non destructive way. Unfortunately its not easy to do with the current data structure but its of course possible.
It may be a performance problem inserting notes at the beginning of a bigger score as complete reformatting has to be done for every note. There are other problems with splitting notes across bar lines etc. which i have to investigate.
In reply to Insert Mode by [DELETED] 3
Yes, this is something that takes a lot of deliberation. My own experience is that I'll often think an idea is great until I've coded and played with it. Then, in testing, I'll discover there's some flaw with the design, and there's a better way to have done things, or have set up the data structures.
It would be interesting to see what would happen if the source to Igor Engraver were released. It's written in LISP, the same as Lilypond. While that's an appropriate language for music, I don't know how large a community there is of open source LISP hackers.
In reply to Yes, this is something that by dcuny
I am afraid that the community of open source LISP hackers is not that big. Some years ago I was involved in Gsharp (http://common-lisp.net/project/gsharp/), but this project seems now to be sleeping. But if Werner, Nicolas and a few others are as good in LISP as they are in C++ then interesting things might happen if the source code of Igor Engraver is made free and open. I would not like to hold a position at Sibelius Software in that case ...