Mouse control blues
I'm sure this has been mentioned countless times...
Mouse control is BROKEN.
Even when zoomed in is hard to move a note up or down by a half step.
You start dragging the mouse and nothing happens; more, nothing happens; more, nothing happens; more and the note jumps by a fifth... Too much filtering ... and/or ... too much hystheresis.
Comments
Select a note, use up/down arrow?
Does the mouse work correctly on other programs?
In reply to Select a note, use up/down… by Shoichi
It does in some programs. I work in graphics and 3D design a lot, so Blender3D, and Gimp are two programs I use without mouse problems.
But the arrow key will do; thanks!
For the record - mouse works to move by "full" step (one line or space, which may be a whole or half step). You need to double-click and drag. Works fine on my system. but - it's not really the best way of changing pitch. Arrows are the normal / supported method.
In reply to For the record - mouse works… by Marc Sabatella
Double click and drag? That won't change pitch, just the visual position, IIRC.
In reply to Double click and drag? That… by Jojo-Schmitz
Depends on how your system is configure, I guess. On mine, I always need a double-tap of the touchpad to initiate a drag operation, although I can initiate it with a single "physical" (hard) click.
Anyhow, however it works on your system is what you need to do. Something to watch out for is that you start the drag in the same motion as the double tap. Otherwise, the double-tap will be interpreted as a command to enter Edit mode - or fine tuning physical position, and you won't be able to then drag to transpose until you leave Edit mode.
In reply to Depends on how your system… by Marc Sabatella
I don't get it. Are "systems" so different from each other? Or do you mean differences between Windows, MacOS and Linux? Or between desktops and laptops?
In reply to I don't get it. Are … by danw58
Yes, systems are that different. Not just Windows vs Mac, but also within the Windows world alone, you could have mouse vs touchpad, hardware/drivers by Logitech vs Synaptics, default settings provided by Dell vs Acer, and further customizations performed by one user vs another. All sorts of things differ in this way - double-click speed, whether a single or double click is required in order to initiate drag, etc. So I can't tell you how your particular system works. All I can tell you is that if MuseScore receives a "drag" signal from the system, and if you are not it Edit mode, it works flawlessly as far as I can tell and have ever seen (never heard another report about this in the many years I've been on the forum).
So my guess is you are accidentally double-clicking and releasing before initiating the drag, thus putting you in Edit mode, and then indeed drag won't work the way you'd expect. Could you please test this? Try to drag again, this time being careful not to double-click if your system is configured to initiate drag on single-click, or if double-click is required, being sure not to release between the double-click and the drag. If you find yourself in a place where the note appears to not be responding, look at the lower right corner of the screen to see if it says "Edit mode".
In reply to Yes, systems are that… by Marc Sabatella
I have never experienced anything even close to a double-clicking requirement for dragging. Didn't know such thing existing. And trust me I neever EVER accidentally double-click; my life's problem is the opposite; often I try to double-click and miserably fail. No, the problem is that the application is setting some minimum amount of dragging movement before calling it a drag, but that minimum it imposes is too large, and so the movement does not register until it registers too much, and the not jumps. There is also filtering --low-pass filtering, to be precise (averaging in time) of mouse x,y data. How do I know this? Because when I'm trying to drag a note, sometimes, by being very slow and controlled on the mouse, I manage to move a note a half step up or down, and I release the mouse button, with a great feeling of success, but a second later the not jumps an additional half-step... I'm not even touching the mouse! It's like the note is very heavy and has like inertia; it keeps going to the next line. Very frustrating. I can show your programmers how to do a proper filter and hysteresis algorithm. THis is kind of my specialty. I'm an electrical engineer by profession, and I design motor controls and machine controls, and I applied the same kinds of clean algorithms to many areas of game dynamics. Essentially, to get good noise filtering in a data input stream, rather than average a gazillion samples, you average just a few, best numbers are powers of two plus two.
You set up a FIFO of that size, say 6 samples. At each step of the data processing you push the new incoming value into the FIFO. Then add all 6 values into an accumulator. Next you find the highest value in the FIFO and subtract it from the sum. Then you find the lowest value in the FIFO and subtract it from the accumulator, also. So now you have the sum of 4 samples in your accumulator, and they are the 4 middle values. The two outliers, which are the most likely to be corrupted by noise, are removed. This way, with very few samples, and therefore very low delay or inertia, you get a very steady and smooth filtered value.
In reply to I have never experienced… by danw58
You don't need to double click to repitch a note with the mouse, in fact you cannot. If you double click and drag a note it will move with the same pitch. If dragging the note works erratically then either you mouse sensitivity is wrong (not likely) or something is slowing down MuseScore. As a test, select a note and press an up or down arrow to see if it immediately moves. If it doesn't then your MuseScore is slowed down and there are a few reasons this can happen.
In reply to You don't need to double… by mike320
Arrow keys work like a charm for me, fast as lightning. This could be another Qt thing, for all we know. After my last post I thought, "are the developers REALLY filtering the mouse?" And my feeling changed to that probably all they did was set some parameters in some library which does the mouse driving inside a black box. Because not only are most libraries forbiddingly huge; they are also full of poor implementations that never get fixed just because they don't meet the full qualifications to be called "bugs".
In reply to Arrow keys work like a charm… by danw58
MuseScore is not slowing down your mouse response. I can, but don't usually, change pitches with the mouse quite quickly.
In reply to I have never experienced… by danw58
All I can say is that works flawlessly on every system I have used it on - at least a dozen. As soon as I drag far enough to reach the next line or space, the note moves, every time without fail. I tried this zoomed in, zoomed out, fast, slow, every variation I could think of, and cannot get it to fail. So something must be unique about the configuration of your pointing device or how you are performing the operation. Feel free to try some different settings to see if you can pin down what the trigger seems to be. And then perhaps a workaround for that can be programmed in. But normally, it's not really anything we have control over - either the system transmits a drag message to us or it doesn't and it sounds like for whatever reason your is doing so only erratically.
In reply to All I can say is that works… by Marc Sabatella
On a large score the delay in doing anything might be the cause for this behavior? Do the arrow keys respond immediately or do they have some delay until the note moves?
In reply to On a large score the delay… by Jojo-Schmitz
Ok, let me explain, because I may sound as saying there is a TIME delay; there isn't exatly, If I grab a note (click mouse button down) and I move the mouse fast, the note moves fast (but the note moves too much). What there is is "phase delay" perhaps? To avoid moving the note too far up or down I have to move the mouse very slowly, and there is no immediate response on the screen, so it FEELS like a time delay. Once I move the mouse far enough, suddenly the response comes, but often it is a whole step, not the half step I was intending.
Regarding filtering, that's more than just a feeling.
And I get it that probably nobody intended for the mouse to be filtered, but probably the library you use does it without you being aware of it.
So here's how the appearance of filtering manifests:
Imagine you have a note in the G line, and you want to move it up to the A position. Click on it, start dragging the mouse up very carefully... nothing... nothing... nothing.... Done, the note jumped up a half step, so you immediately let go of the mouse button (unclick), but even as you are breathing a breath of success and self congratulation, you see the note jump up, all by itself, another half step to the B line... 1/2 second after you let go of the mouse... Boom! Feels like there is a sort of "inertia" built up. You thought you had moved the mouse just enough, but obviously there was more motion accumulated than was readily appearent.
So, this is how it is for me with this app. And I don't have mouse problems with any other app, before you ask.
My guess is that maybe Windows filters the mouse but Linux doesn't, and then you use a Linux library that does mouse-filtering under the hood, and when ported to windows it adds its own filtering on top of Window's filtering... I don't know; I'm just taking a wild guess. By the way, this machine is a very old Dell, running windows XP, the mouse has the Dell brand on it; it is optical, USB, if any of this is any help.
This is how it is for me. And I don't have this problem with other apps I use.
In reply to Ok, let me explain, because… by danw58
Dragging does not move by whole or half steps - it moves by lines and spaces. That is, G to A is a whole step, but B to C is a half step. That is how it is supposed to work, and again, it does for me. As soon as I have moved the mouse to the next higher line or space, the note moves, always and without question, instantly, each and every time. I have now tried this experiment dozens of times at various zoom settings and never once seen it fail. This is on Windows 10, Microsoft Surface with touchpad. But more than that, I have been on this forum daily for almost eighth years now and never once seen another report of problems in this area. It really does work in general.
You say you havent noticed this problem with other programs, but I wonder, which programs are you comparing to that have a similar idea of only moving things in discrete amounts like this? Certainly in most other programs that provide a drag behavior, the drag is continuous rather than discrete. That is, if this were an ordinary graphics program, you could normally drag an object to a position that is, say, 0.17sp above the line. And in fact you can do this for most symbols other than notes. Do other symbols drag as expected for you?
Given that drag of notes is defined to actually transpose the note and not just fine-tune it's physical position (double-click for Edit mode to do that), it is quite right that the motion is discrete. And as such, indeed, you will need to move the mouse around 0.5sp before anything happens, naturally. So if you want to compare to your experience with another program, please find one that also moves discretely like this.
My guess is you simply aren't zoomed in far enough to be able to control your motion within 0.5sp, and you are overshooting your target before you realize what has happened. But if you do find another program that implements discrete dragging like this, try setting the zoom to give similar step sizes in both programs and then do your comparison that way, so it is apples to apples. My guess is that you will find the behavior similar - it's hard to be accurate if you aren't zoomed in far enough, but as you zoom in it becomes easier.
In reply to Dragging does not move by… by Marc Sabatella
"Dragging does not move by whole or half steps - it moves by lines and spaces. That is, G to A is a whole step, but B to C is a half step. That is how it is supposed to work, and again, it does for me." Damn, I had the vocabulary wrong; I thought step meant from line to line, and half step from line to space, etc. So that's what I was meaning.
"Certainly in most other programs that provide a drag behavior, the drag is continuous rather than discrete." You're absolutely right; I AM comparing apples and bananas.
"Do other symbols drag as expected for you?" Good question, and frankly no, moving the p of piano or f of forte, they also don't seem to move until I've dragged the mouse a bit too much, then they jump too far, as if there was a threshold applied to the mouse input.
I can't think of another program that implements discrete dragging at this moment.. I probably have several, but can't remember one right now.
Regarding zoom level, the problem is not as acute if I zoom in, but I'm kind of lazy to zoom in, out, in, out ... all the time; so I try to find a compromise level I'm semi-comfortable with and try to stay there.
In reply to Dragging does not move by… by Marc Sabatella
Posted twice. Deleted this copy.
Check if you have enabled the navigator (menu View/Navigator). In that case response is slow because the edit affects both the score and the navigator miniature. Disabling the navigator speeds up this kind of edits.
In reply to Check if you have enabled… by fmiyara
I checked, and I did have it enabled; but I disabled and the problem was not fixed. But I'm getting used to using the arrow keys now; it's a lot easier. Still, it would be nice if mouse dragging feature was either improved as to be basically usable, or else disabled entirely. To have it there but not working properly makes no sense.