Jumpy Note Entry
Again working on the Chopin Nocturne and when I'm adding a chord to the the last rest in the measure, each time I enter a new note of a chord, the program jumps to the next measure and it's difficult to drag my way back to the measure I was attempting to complete. Every time I enter anther note the same behaviour reoccurs. I really don't care for this auto advance feature. I would prefer to just move to the next measure myself when I want to after I'm actually finished with present measure. Note entry is with a mouse on the Linux platform.
Comments
Switch to continuos view for note entry
In reply to Switch to continuos view for by Jojo-Schmitz
Okay thanks, I'll try that the next time I work on it.
Also, you should never need to drag to navigate - that's what mouse wheels, the page up/down keys, and the Navigator were invented for.
I think if you were forced to always advance the cursor yourself you'd be far more frsutrated - that would be twice as many keystrokes to enter the same piece of music as with the current system. Could you imagine if a text editor made you hit the cursor button after every letter you typed?
In reply to Also, you should never need by Marc Sabatella
Well this isn't text, and the jumpy behavior wastes a lot of time and effort. There's no way it should be jumping to the next measure until I'm finished with the measure I'm working on. Is the program clairvoyant? It tries to be but its intelligence is obviously totally artificial. This is like a word processor jumping to the next paragraph before you've even written 1/2 of the first sentence. Switching out of page mode helps somewhat.
In reply to Well this isn't text, and the by gBouchard
No clairvoyance or artificial intelligence is involved or required. it's quite simple: as soon as you enter a note, the natural assumption - true at least 90% of the time - is that the next thing you will want to do is enter another note *after* the note you just entered. Just as with text, after typing one letter, the most natural assumption is that you will want to enter another letter *after* the one you just entered. So no, it's nothing like a word processor jumping to the next paragraph before you've written half a sentenc.e It is exactly as I said - one letter at a time, the cursor advance to the next position ready for you to enter another letter after the one you just entered, because most of the time, that's exactly what you want to do.
I guess if you are entering piano music full of large chords, then the assumption that after entering a note you want to enter another afterwards is not true as often as it is for the majority of music. So in the very special case of piano music with large chords, then indeed having the cursor advance after each note is not necessary optimal. But it's also normally harmless - the previously entered note will still be in view most of the time. Only if you are in page view and at the end of the measure and the next measure is on another line is there an issue - in these case, the previous note entered may no longer be in view. But that accounts for well under 10% of all notes entered. And simply switching to Continuous view avoids that problem.
So, for the vats majority of music, the current behavior *is* optimal. For the very special case of piano music with large chords, it is not always optimal, but the automatic cursor advance is harmless msot of the time, and it's harmless *all* the time if you simply switc to Continuous view. Meaning, everyone can get what they want. The majority of users can use page view and enter notes one at a time and have optimal behavior. The people entering piano music with large chords can switch to continuous view if they are bothered by the small number of cases where the jump to the next line positions the previous measure out of view.
In reply to No clairvoyance or artificial by Marc Sabatella
Sounds like a lengthy explanation by a politician of why America needs to go to war against an unarmed non violent country.
Perhaps if the program was clairvoyant enough to realize I was working on the last note(s) of the last measure on the page it would wait like an obedient well trained dog for the "release command." I didn't know about the continuous view when I posted my original comment, but given the fact that the original set up was designated "Solo Piano," perhaps Musescore needs to go to a better "agilty school" so that it doesn't head off hell bent over the wrong jump.
In dog competitions you and the dog can be completely disqualified for such behavior. In my view, Musescore is still a very unruly pup, that has yet to reach maturity. Good dogs do much better at following hand signals.
In reply to Sounds like a lengthy by gBouchard
No need to get personal or sais clever. Let's stick to the technical issues.
As I said, well over 90% of the time, this is the optimal behavior. The only time it isn't is on the last note of a line in a score involving multi-note chords and you are not in continuous view. Can you think of other programs that change their behavior automatically just because the cursor reaches the end of a page? I think most users would find this surprising. But feel free to point to examples. I suspect you will find MuseScore works just like most other programs in this respect. But maybe someone out there has found a clever solution (in addition to continuous view which we of course already support) and you can show it to us.
In reply to No need to get personal or by Marc Sabatella
Well, I am always flummoxed when the screen changes unexpectedly, and I am happy to see a possible solution: "continuous view". Great!
Where is it? I looked through all the areas in the top bar (don't know what to call it, "File" etc.), and I can't find it.
In reply to Well, I am always flummoxed by xavierjazz
It's not in any of the menus (that's the word you're looking for). However, right in the middle of the toolbar you'll see a place where it says "Page View"—click that, and the option for Continuous View will appear.
In reply to It's not in any of the menus by Isaac Weiss
Thank you. It is so hard to organize everything so that everyone will instantly understand everything. :)
In reply to Sounds like a lengthy by gBouchard
Perhaps if the program was clairvoyant enough to realize I was working on the last note(s) of the last measure on the page it would wait like an obedient well trained dog for the "release command."
That would be unexpected for me... A software is not supposed to do something very different in a very special case (just like a trained dog I guess...). If there is a solution to this issue, other than using the continuous view, it needs to be a solution that work for any position in the score, not only the last measure of the last page (especially because depending on the current zoom, the same problem can arise anywhere)
In reply to Perhaps if the program was by [DELETED] 5
Out of curiosity, I just tried this in Noteflight, and the way they handle it is, while the cursor advances in all cases, the view does not *not* update to shwo the current cursor position. So if the cursor moves to the next line or page, you can't see it. This seems like a bug to me - it means you can't see where you are about to enter a note in the normal case where your intention is to add a note at the current cursor position (ie, following the one you just entered). But FWIW, that's what they do.
In reply to Out of curiosity, I just by Marc Sabatella
Just because other programs are poor is no justification for poor behavior on the part of Musescore. Most software is crappy. Good software is the exception, not the rule.
In reply to Perhaps if the program was by [DELETED] 5
I would say the technical solution would be for there to be a checkbox in the master preferences, or in the Taskbar at the top, to turn off auto cursor advance. I think the actual reason for auto advance is because probably many people use a MIDI keyboard for note entry where an entire chord can be entered at once. Naturally if you are using a MIDI keyboard you would obviously want it to advance to the next position because it would enter subsequent chords on top of previously entered chords, and this would obviously be a complete disaster. it would also require manually moving the program forward after each chord entered. All that said for those of us using a mouse and no MIDI keyboard for musical note entry, the present behavior is very irksome.
In reply to I would say the technical by gBouchard
Although I'm not against the proposal to stop auto-incrementing the cursor, it would have to be a setting only affecting user-input and not plugins for example, which would mean coding it in is not as simple as one would like.
Most people I know whom are using MuseScore actually use the computer keyboard for note entry as it is *way* faster than mouse and the current step-time MIDI entry. Once you get the hang of that, the jumpiness either doesn't matter that much, because you know what you enter/augment through the keyboard (no need to have the visual feedback). But if you need to review the just entered chord it's only a single keypress away (press the left arrow key a single time).
That is the same whether you've gone out of view on the same line (because zoomed in), on the next line (because end of line) or even on the next page (because… you've guess it: end of page :) ). A single keystroke brings back the view.
In reply to Although I'm not against the by jeetee
This is most valuable information.
In reply to I would say the technical by gBouchard
The main reaosn the cursor advances automatically is for keyboard entry. Most people want to be able to enter ntoes by simply typing. Like, Mary had A Little Lamb is E D C D E E E. People don't want to have to stop to advance the cursor after every note. That's why I said in 99% of cases, it's the right behavior. it's right for other programs, and right for MuseScore. There is pretty much no way anyone would want keybaord entry to rewquire advancing the cursor.
Mouse entry is indeed potentially a different story. I could imagine things work differently in that case. I'm not familair enough with that entry method to have good insight. Feel free to provide concrete suggestions for how you think all the different cases should be handled. If other mouse users agree, then perhaps changes could be made.
In reply to The main reaosn the cursor by Marc Sabatella
It's mentioned above that all you have to do is hit the left arrow key to go back to the previous measure. If that is the case, and it actually works then there really isn't much of an issue other than user understanding of how all these various key strokes work. I had noticed that the right arrow key does advance to the next note. However another annoying jumpy screen behavior is the enlarging from 100% to 200% doesn't keep you in the same measure or on the same note even though it is selected. Some other features I'd like to see is to be able to group objects much in the same way Inkscape does. With that in mind, I'd like to be able to snap the peddle lines to a grid or guide line. Another behavior I'd like to see is to be able to highlight at particular style of pedal and than replace it from one in the palette of a different style by just double clicking on the one in the palette. This how bar lines work I believe. The behaviors of various objects is very inconsistent in my opinion. I don't know how important it is, but Continuous View does not keep the same measure proportions as page view wich throws the pedal lines off. Also when entering notes into Voice II, it moved various objects in Voice I which were actually already correctly placed. So if you ask me there is a whole lot of unwanted behavior with Musescore. If Inkscape did the same thing it would really be hell to use. Traditionally with hand written notation you choose a measure size by setting the barline, and than manually space the notes. Musescore automates the note spacing which in fact is very nice, but moving notes that are properly placed just creates more work. Some other poster mentioned "work flow" in regards to Musescore, and that seems to be a huge issue at the present time. There are just too many unexpected and unwanted behaviours which creates a lot of confusion, extra work and anguish. On the positive side the final printed output is exceptionally nice once you finally get the notes entered.
In reply to It's mentioned above that all by gBouchard
I like the idea of replacing one line with another by selecting and double clicking - you should submit that officially to the issue tracker as a feature request.
Continuous View by its very nature will have different measure sizes and other differences from Page View. Lines should appear correctly if you have adjusted them correctly, hwoever - that is, using Shift+left/right to change the attachment point, not just dragging with the mouse. If you have encountered some unusual special case where this is not working correctly, please start a new thread and post the specific score you are having problems with and precise steps to reproduce the problem.
I don't understand what you mean about entering ntoes in voice 2 affecting voice 1. That shouldn't be the case either, except in as much as the spacing is *required* to change to be correct. You should never need to be moving notes manually - the defualts are almsot always correct. Again, if you have encoutnered some unusual special case where this does not seem to be working correctly, please start a new thread and attach the specific score you are having problems with and precise steps to reproduce the problem.
In reply to Perhaps if the program was by [DELETED] 5
I thought the agility dog analogy was in fact quite appropriate. If an agility dog exhibits this same behavior in a competition, it is flat out disqualified from the competition, although out of courtesy to the dog and handler it is allowed to finish the course, it just doesn't receive a score. It's perhaps the most egregious error aside from running out of the course boundaries. Obviously in all these cases the dog is not appropriately responding to the signals of the handler, and that's exactly what Musescore does It jumps to the next page before a measure is actually completed.