Inspector confirmation/feedback
I never know whether what I do, or even not do, in the inspector is going to take effect, and when, if ever, it is not going to take effect. Obviously, if I don't change any fields, the single object I may be inspecting is not going to change. But when I inspect multiple objects (e.g., all the notes in the score), and some kind of "global" values are inferred from the various individual objects for display in the inspector, I have no idea if the objects have already all been changed, or will be changed if I exit, or if there's any way to cancel. Before deciding if this needs improvement or just documentation, could someone explain what happens when I edit two notes with velocities 64 and 74 and a) do nothing b) change the velocity to 84 and c) at what times these changes actually take effect? A confirmation button for proposed change "Changing velocity for 1423 notes from various to 84" might be ideal.
Thanks!
Comments
Changes should take effect immediately and always do without exception for me, so I;m not really sure what you mean. At worst in the case of some particular types of controls I could imagine it *might* be necessary to click elsewhere or hit Enter or something to complete the action, although I can't think of any controls that actually do work this way. If you are seeing a specific case where changes don't take effect immediately, that's a bug, and you should post the score you are having problems and the precise steps to reproduce the problem.
But to answer your questions:
a) I don't understand what it means to "edit" two notes but do nothing. If you mean, select two notes but don't edit, then obviously, the expected and actual result is that nothing changes.
b) If you change velocity to 84, both notes should and do change velocity to 84.
c) this change, like all other changes in the Inspector, takes effect immediately. Although it should be noted that playback *is* handled a little differently internally. The change to the note property takes effect immediately, but the effect this has on the actual playback events associated with the notes (there are potentially multiple multiple events for each note) might not be not updated until the next time you hit Play.
I can't see any possibly reason I'd want to see a confirmation dialog every time I try to make a change - that would be an enormous productivity killer.
In reply to Changes should take effect by Marc Sabatella
Marc, thanks for your reply.
I propose a confirmation dialog any time you change more than object, or at least, something near the title bar saying how many objects you're modifying, or a red light on the top meaning "Modified!" No, the latter is no good, because once you've modified it/them, they're not modified any more. The lack of feedback itself isn't a productivity boon.
By "edit two notes and do nothing", I mean select two notes, with presumably differing attributes, enter the inspector, so that only one set of attributes is shown (how is it determined), and leave the inspector. I gather that nothing would change.
But if I type in the value of velocity which is already shown, that is a "change", and takes effect immediately.
I gather then, that leaving the inspector per se never, ever effects any change?
In reply to Marc, thanks for your by [DELETED] 1831606
I select a bunch of objects, I make a change - I don't wnat to have to confirm that I really meant to do what I just went very much out of my way to do. I'm not getting why there would need to be feedback. I suppose maybe you once accidentally selected a lot of objects then also accidentally changed something in the Inspector and then regretted it, but that's no reason to kill productivity in the usual case where you meant to make the selection then make the change. That's what Undo is for. Would you also want confirmation every thing you made a selection then pressed Ctrl+X to cut? The Up arrow to transpose? Double clicking the "accent" mark sysbol to add accents to a whole selection at once? The ability to quickly make changes to lots of elements at ocne is a plus, not a minus. We don't need confirmation dialogs for all of these operations; I don't see why the Inspector should be different.
Leaving the Inspector indeed should never change anything, but again, if you are seeing a specific case where behavior is not as expected, you should post details. You original post suggested there was some sort of inconsistency or unpredictability, but I have never seen any such case (other than bugs fixed long ago), so again, if you are seeing some unusual special case with some particular score and/or some particular control, you'd need to explain further.
In reply to I select a bunch of objects, by Marc Sabatella
When you cut stuff or transpose a passage, you see it happen, and you see the new state. When you change the velocities of thousands of notes, on the other hand, you have no confirming feedback at all. The velocity dropdown now says "27", so they must all be "27", except that before you changed it, it said something else, but they weren't all what it said.
It is profoundly slow and painful to inspect note velocities to determine if you've ever changed them, and to what (all I could imagine better is a mode where a little red number and a U or R came up next to each note). Operations that affect multiple note velocities ought have more feedback. Perhaps this is peculiar to velocity, which has no visual effect.
In general, the old Windows principle of "Global and profound dialog changes take effect when you click OK" was a good one; the Mac principle of immediate action, "not so much". You have to close the inspector no matter what you do (if you want to see your score). The lack of differentiation between a "confirm" close and "cancel" close feels very counterintuitive to me in this case.
In reply to When you cut stuff or by [DELETED] 1831606
OK, I do get that with respect to velocity, but realisatically, the small handful of playback properties are the only things the Inspector does that don't immediately affect the appearance of the score as well. And realistically, 99% of people will never touch the playback properties ever, but most will user the visible propertoes quite often. So I would be loathe to worsen the user experience overall just because of the slim chance that someone will accidentally change palyback properties when they didn't mean to.
But I don't understand what you mean about closing the Inspector. Why would you want to do that? I guess maybe you undocked it? That's your choice, but it is really designed to just stay up at all times, docked. Changing from the old 1.3-style modal dialogs that required explicit action to bring up and another explicit action to dismiss is one of the great improvements the Inspector provides.
In reply to OK, I do get that with by Marc Sabatella
Yeah, I usually do undock it. I can see how if you think of it as docked, the whole "dialog" paradigm in which my issues are rooted makes little sense. Where should it be docked? I should try that.
My use-case for velocity is usually with (ultimately) midi-imported files in which each note has dynamics expressed as velocities; ultimately, I'll blast all the velocities away and re-dynamic the whole piece with the proper markings, but before then I have to carefully observe and duplicate velocities if I want to insert new notes. It is something I do pretty awful, and quite tedious.
Perhaps playback properties and visual properties require further UI distiction, esp as jim is working on the trill capability....
In reply to Yeah, I usually do undock it. by [DELETED] 1831606
By default, it is docked on the right side of the score, as shown here:
https://musescore.org/sites/musescore.org/files/Note%20inspector.png
I'm not quite following what you are saying about needing to carefully observe and duplicate velocities. You might want to explain your use case in more detail. Maybe there is another solution that would fit better with the current use model.
In reply to By default, it is docked on by Marc Sabatella
I import some large piece of work from Midi. Every note has a velocity (in MuseScore), being the native Midi velocity seen by MuseScore, an army of hidden settings. I want to change some notes, so, say, I delete a measure, and enter new notes. The new notes will have velocity "Relative 0" while the notes around them might have "User 54" or whatever. If I don't compel the new notes to concur with their context, with the inspector, they sound at the wrong loudness. So I must inspect the context and the notes to be deleted carefully to learn the desired dynamics.
This is before and in avoidance of taking the major step of "Relative 0"ing the entire score and recreating dynamics from scratch. Here is such a score of mine, fully upgraded to MuseScore but for the velocities/dynamics, which remain note-by-note, because I really do use artistic control of dynamics here (i.e., in the input midi). https://musescore.com/user/1831606/scores/768861
In reply to I import some large piece of by [DELETED] 1831606
Why not that the major step first? You're going to want to do it anyhow, no? That's how I'd do it. Then you can add new notes without a second thought.
In reply to Why not that the major step by Marc Sabatella
Because there's simple no way to do it incrementally, and once you've cleaned out all the velocities you have to reconstruct ALL the dynamics (from printed score), losing all the work that went into the original. In pieces without much dynamic activity, the choice is clear, but with something with a lot, you can sneak by with something playable if you just "play along" with the velocities, as it were. It's not elegant, I admit....
In reply to Because there's simple no way by [DELETED] 1831606
The specific combination of things you are describing is not going to be a common activity for many people, I suspect, so it might be tough to drum up much support for what I'm about to suggest, but -
It seems a plugin could perhaps be written to automatic a good chunk of this. That is, going through the score note by note looking at hard-coded velocities and trying to reverse engineer reasonable dynamic markings, inserting those markings, and then resetting the hard-coded velocities.
In reply to The specific combination of by Marc Sabatella
That's not a bad idea. I haven't yet written a plugin (for MS).