modified drag method to override snap-to-grid?
(This is a feature request pertaining to 2.0.)
Snap-to-grid is a wonderful enhancement, but there are times when one may need to override it temporarily (i.e., quickly and easily ... without actually having to click in the Inspector to turn the feature on and off). I believe it's common for graphics programs to offer a way of dragging that enables an override of the grid.
Could this be made possible in MuseScore? Perhaps adding the ALT key in combination with SHIFT or CTRL for constrained dragging vertically and horizontally, respectively, that overrides the grid? And ALT + drag for unfettered dragging in any direction?
Comments
What snap to grid are you talking about? The only thing I know of that fits that description are the controls in the Inspector that you have to enabled manually, and you can disable them the same way you enabled them.
In reply to What snap to grid are you by Marc Sabatella
That's precisely what I'm talking about, as should be clear in my original post.
I'll try to be clearer and more succinct:
(1) I am proposing a way to temporarily override the snap-to-grid feature after it has been manually turned on in the Inspector.
(2) There are many occasions when this is desirable because manually turning it on and off in the Inspector really frequently becomes really tedious.
(3) The sort of override I'm referring to is a common feature to graphics programs precisely because of the convenience it affords.
In reply to That's precisely what I'm by [DELETED] 448831
OK, I get it.
It's definitely not a bad idea. But I would observe that music is a bit different than free-form graphics programs - most items have a "natural" default position that can be alogirthmically determined, and or controlled by style settings. And given that the default position will *already* be aligned to a grid, and that you can *aready* move items in 1sp (or 0.1sp) increments using the keyboard, the actual need for the snap to grip while dragging is lessened. I'd personally even say eliminated - I'd much rather rely on default positioning and adjustments made via keyboard than on dragging, with or without snap to grid.
Still, I'm glad the snap to grid feature exists, but it seems to me the need for its use should be pretty uncommon. So I already see it as something you'd turn on just momentarily and then off. I'm curious what your use case is for the reverse.
In reply to OK, I get it. It's definitely by Marc Sabatella
What prompted my inquiry about the need for occasional momentary overrides is ... fingering. (Oh no, not that again!)
For purposes of my narrative, consider that our point of departure is the Snap-To Grid is ON. That's how I work; there's pretty much no downside for me to having it turned ON, as it ensures a consistency in relative positions and distances that relies on vision alone - and that makes sense to me. The elements I'm talking about positioning include staff text, dynamics, articulations, hairpins, ottavas, fingerings, and old-style pedal marks ... and probably more.
Now, here's where I often need a momentary override for fingerings. Assume a fingering with normal Fingering style, positioned above a notehead in the treble clef. By default, the numeral is precisely centered over the notehead - as it should be. But if I need to move that fingering upwards - let's say, for example, to accommodate the beginning or end point of a slur - the numeral will also shift to the left fraction of a space because of the grid.
I think the actual amount of the shift is .3 spaces (spatiums? spatia? space units?). It can be corrected by entering that amount as a horizontal offset in the Inspector, sure - but it would be easier if in this particular instance I could just override the grid when I'm dragging.
That's it, really. I know I already mentioned pedal marks in my first paragraph, but I'll take the opportunity to reiterate that the grid is virtually indispensable for consistent positioning of the 'Ped.' and '*' marks. (This has nothing to do with the snap-drag-override that's the subject of this topic, of course; it's just one of the really important uses that I have for the fabulous new snap-to-grid feature!)
We all have differing backgrounds, obviously - and this is as true for our end-user experiences with software as in any other area. Oftentimes the habits we have formed may have become fairly ingrained; that's bad if it means an inflexibility or difficulty adapting to stuff that's new and different, but I actually think it's good when it means understanding how software can be predicted to perform generally, grasping the concept of 'best practices' for efficiency and productivity, and having occasional insight into functionalities that could make a program work better. Anyway ... I used graphics programs a lot, and I have been hoping for a snappable grid since MuseScore 0.9.5.
I do feel a bit like my wish was granted, and now I am looking a gift horse in the mouth. But ... there is a need for this. If you work in an environment like mine - snap-to-grid turned on by default because you always want it to be available - but maybe 1 out of every 5 (or even every 10) drags, let's say, you want the object not to snap to the grid ... well, that's what prompted me to start this thread and request the feature. :-)
In reply to What prompted my inquiry by [DELETED] 448831
And again, I do understand the request. It makes sense on some abstract level. But I guess I still am not understand what value you see in having the grid turned on. The grip implies you are dragging things eith the mosue for some reason rather than using keyboard (edit mode / arrow keys). And this is the part I don't understand. If you care about preciseness in positioning things - as would seem to be implied by wanting to use a grid - then it seems in all possible ways, nudging with the keyboard is better than dragging.
And for Pedal, I especially don't understand. They should hardly ever need to be moved at all. If you have your style settings set as you like, then they are positioend that way by default. I guess if you have a few notes here and there that are many ledger lines below the staff, hence requiring you to move a few pedal lines lower than the default you have chosen. But this too can be done easily and precisely with the keyboard.
Note - I am specifically talking about nudging directly with the keyboard, not using the Inspector (eg, double click, arrow and/or ctrl+arrow). Although the Inspector is very useful when moving multiple items at once. And that's something you'd be doing for Pedal, it seems.
If we *didn't* provide a way set good defaults, and simply keyboard nudging capabilities, I could see snap-to-grid seeming more important. But as it is, I just don't really see it's value - if you *really* care about precise positioning, it seems the keyboard is more effective.
None of this is meant to say that a temporary override to the grid wouldnb't be a nice idea some day, but it still seems that there are easier / more effective ways of working if you are trying to get precise positioning.
In reply to And again, I do understand by Marc Sabatella
Mark, with respect - I believe you need to try to at least show a greater understanding of working methods different to your own. I'm a power user of any software I learn, and MuseScore is no exception. I do know what I'm doing, and I do what works best and easiest for me.
It's funny, too, given that piano is apparently the primary instrument for each of us - but there's obviously a huge diversity in music for piano from different periods and genres. All I ask is that you not be so presumptive that your way is the best way without qualification under all circumstances. I can assure you that such overconfidence is misplaced, as I am already fully aware of all the alternatives you propose that you believe to be superior. You, on the other hand, are not aware of the complexities of the scores I'm transcribing and how frequently the styles and positioning algorithms needs tweaking.
It feels rotten to be told that you 'just don't really see its value' with regard to a feature that's so important to me - and others! - with the dismal implication that I '*really*' don't care about precise positioning. Also, FWIW, you've ignored the specific instance of manual overriding that you asked me about.
More people unquestionably need to weigh in on this, as you, in my opinion, are blinkered by what *you* don't seem to understand about the utility of this feature. I was hardly the only MuseScore user interested in seeing a snap-to-grid feature implemented, and therefore I know that I am not just speaking for myself here in seeking a highly desirable refinement now that we have it. This is not - and should not be - about my work habits or the inherent worthiness of the snap-to-grid feature.
In reply to Mark, with respect - I by [DELETED] 448831
For illustrative purposes and to obviate any question about just what I'm working on, I'm attaching the only public domain score of Fauré's Ballade Op. 19 in existence currently. I can't share the .mscz file on which I've been working for ages because I can't compromise my own interests in my work (i.e., I have not yet decided on the level of Creative Commons protection I will seek when I ultimately upload the pdf to IMSLP). There are just two published editions of this piece in print at present, and they retail for between $15 and $20 despite some significant deficiencies in each one that I will eliminate in my re-typeset; it will contain abundant fingering and pedaling suggestions, something none of these three editions offers.
In reply to For illustrative purposes and by [DELETED] 448831
BTW, this may or may not be obvious to you, but it completely escaped my memory in my first response when I mentioned that you can disable the grid te same way you enabled it - the commands to do this are, likemost other commands in MuseScore, keyboard-assignable. So in Edit / Preferences / Shortcuts, define a keystroke for enable horizontal and enable vertical grid. These are actually toggles, so you can temporarily disable the grid in either direction independently with a single keystroke. Not exactly what you are asking for, I think - but then, I still don't quiter understand your use case, so I can't really say for sure if this fits or not. But I thought I would mention it in case it's helpful.
In reply to Mark, with respect - I by [DELETED] 448831
Sorry you feel I am being dismissive. That is not my intent. I have already said I can see why the feature you propose could potentially be useful. I am simply trying to help you make better use of the features already provided, and simultaneously gain a better understanding of the situations in which they might not be sufficient.
Many people don't realize how powerful the possibilities of positioning by style options and keyboard commands are. They either haven't discovered Inspector, or don't realize you can move virtually everything with the arrow keys in Edit mode now, or that you have contr over the specific amount of nudging. So they assume dragging is the only or best way to move things without having fully explored the alternatives. While obviously you've posted enough that I have some idea of what you might or might not know, it certainly seemed likely you were not fully aware of how much you can do to align things by style settings and keyboard and were dragging more out of habit than any carefully considered study of all the available options. So don't be offended if I try to offer advice.
Furthermore, any new feature takes time and effort to implement, and one has to consider what keyboard shortcuts are still available. So there is always a prioritization process that has to take place. And that is why *understanding* what it is about dragging with the nsap to grid feature that you find preferable to use of the keybkard helps. If it looks like a feature onky of use to a small minirity of people, it isn't likely to get se much attention as a feature with a clearly-spelled-out use case for which we can see many peoe will run jnto and hst the keyboard is not a viable option. So it is in your interest here to try your best to explain specifically what it is your are trying to do and why dragging with the snap to grid option enabled most of the time seems the best way to accomplish it. Because the better we understand the value of a feature, the better we can prioritize implementing it.
In reply to Sorry you feel I am being by Marc Sabatella
I don't really have an opinion on the requested feature but... I want to mention that there is no "snap to grid" feature in MuseScore, or at least it's nothing comparable to snap to grid we all know from graphic program. The feature we are talking about doesn't "draw" a virtual grid on the page, it just constrain the move of a given element to a grid centered to the element current position. So the grid is virtually different for any selected element.
In reply to I don't really have an by [DELETED] 5
Marc - I hadn't considered assigning a keyboard shortcut in this case, so thanks for reminding me that it's possible. (I've been holding off on that degree of customization, actually, at least pending the stability of the official release of 2.0.) Still, it may remain easier just to click the feature on or off via the Inspector - especially given that my hand is already on my mouse for the dragging process.
Oh! Something I never mentioned before because it wouldn't have been relevant to anything is that I don't use a mouse. Instead, I have a Logitech Cordless Optical Trackman - an amazing product that is alas no longer in production. They're not to everyone's taste, but I find the device so congenial generally - and specifically as regards to assignable buttons - that the Trackman (with click-lock enabled) just may have conditioned my liking for dragging and dropping in situations where I would otherwise be using keyboard alternatives.
lasconic - I understand exactly what you're saying, but I've been so happy to have a snap-to capability at all that I would never have complained that it's not really a 'grid' over which the user has control like in a true graphics program. So, despite the limitations, I am thrilled with it. Also, even though we can't adjust the dimensions of the quote-unquote 'grid', the results of object placement by snapping to it are nevertheless consistent and predictable.
The issue with fingerings - which I cited as my 'need' to override the grid occasionally - is an example of that consistency and predictability. The blue numeral in this example has been positioned by dragging it upwards when snap-to-grid is enabled; one can clearly see the -0.20sp horizontal offset that is always introduced as a result. (The scaling in Layout > Page Settings is set to the default of .069" for staff space; I would predict the actual offset might vary if the scaling is changed, but that's not something I ever do. Perhaps it's also font-dependent? I use MScoreBC 10pt for all my fingering styles.)
In reply to Thanks, Marc and lasconic by [DELETED] 448831
BTW, the fact that it is not a true grid is part of why I was not entirely sure what you were talking about at first; also the fact that the feature called a "raster" rather than a "grid" until a few weeks ago. Anyhow, glad the shortcut suggestion may turn out to be helpful.
Some other observations:
The fact that it is not a true grid - a set of snap positions the same for all elements - is why I keep mention style settings and defaults. Of course I don't think the default positions are always perfect and never need adjusting. But because we use style settings to place elements of a given type, you can usually be confident that by default, the initial placement of two elements are "compatible" - offset by some multiple of 0.5sp. They have already been placed at a predictable place relative to a grid of sorts: the staff lines and spaces, which are of course offset by 0.5sp. This is precisely what allows the pseudo-grid to be effective - it wouldn't help to constrain motions to 0.5sp incremennts if we didn't know the elements we were trying to align had started off either already aligned or else offset by a multiple of 0.5sp. So careful settings of style defaults is a necessarily prequisite for this pseudo-grid to be effective to begin with. We tried to make the factory defaults as good as we could for most situations, but indeed every situation is different, so it definitely behooves one to experiment with the style settings but also take care when doing so to preserve this important quality of making sure the initial placements of elements you may wish to align are "compatible" - so they will differ by multiples of (say) 0.5sp.
This same quality of "predictable and customizable defaults" is actually what allows keyboard adjustment to be effective in MuseScore in a way it could never be in an ordinary graphics programs, and I suspect this is not obvious. If you are trying to align two objects that you placed in a graphics programs, you have no idea how many presses of the arrow key it might take to get A to aign with B, and unless the keyboard nudging also respects the grid, you have no guarantee it will ever align perfectly since you don't know how far apart they started or whether it is a multiple of the nudge amount. Whereas with MuseScore, we were pretty careful to make as many offsets as we could be integer multiples of 1sp, 0.5sp, or at worst 0.1sp. So aligning items can almost always be done with a predictable number of cursor key presses - soemthing you can't generally say about graphics programs. Again, I point this out because it may be non-obvious that the keyboard can be used effectively in MuseScore in ways that do not apply to graphics programs.
So, on to your fingering example. I think I understand why you are seeing this horizontal shift as you adjust. It's directly related to a unique feature of the fingering position - it records its results as "user offsets" which show up in the Inspector. Thus, the initial automatic position does not set the origin for the pseudo-grid - the origin (user offset 0,0) is still right on top of the notehead where it would have been without the automatic positioning. You may recall some amount of debate as to whether that was a good decision or not, and its not too late to revisit it.
But anyhow, as is, the amount of the horizontal offset required to center the fingering over the note is not guaranteed to be a multiple of 0.5sp; it will depend on the size of the notehead, which depends on your score font and also whether we are talking about quarter, half, or whole note head types. For a score with all default settings, I get 0.66sp horizontal offset automatically applied when centering the fingering over a quarter note. That means when you try to drag it with the grid enabled, it's either going to shift left 0.16sp to the 0.50sp mark, or else shift right 0.34sp to the 1sp mark. So that is what you are seeing.
There are several good things we can take away from this:
- This could be reason to revisit the decision to record fingerings as user offsets in the first place, athough there are tradeoffs I think.
- It seems for this use case you would only need to temporarily override the horiztonal grid, so the fact that there are two separate shortcuts required to disable the grid is actually fine, and even advantageous. Disable the horizontal grid and use Shift as you drag to constrain the motion to be vertical only. Then re-enable the grid.
- At the risk of causing offense, I will point out that the adjustment in question can be achieved in just two keystrokes: press Ctrl+Up twice. Additional fine tune could be done with Up alone if necessary. But there will be no horizontal shift, so the fingering is guaranteed to remain perfectly centered over the notehead as it started. For *my* money, I'd still rather perform this particular operation this way, and in any event, if this is the *only* use case you have in mind, I'd suggest it might make a good solution even for someone who otherwise prefers dragging but doesn't want to deal with the disabling / enabling of the grid.
In reply to BTW, the fact that it is not by Marc Sabatella
I have to backtrack to seek clarification of something: how does one move multiple objects with keyboard actions? Certainly I'm familiar with selecting individual objects and moving them with either the arrow keys alone or in conjunction with CTRL, but I now realize you seem to be speaking of moving multiple objects in the same way.
i can't make that work! Am I missing something? If I want to move multiple objects of the same type, I would select them all and then use either the Inspector or drag with the mouse. Is there any other way? If there is ... then I truly don't know this program as well as I thought.
I have to ask this because the suggestion of CTRL+UP twice works fine for one notehead at a time - but what about when you're doing the same thing to several of them?
p.s. regarding this idea: "Disable the horizontal grid and use Shift as you drag to constrain the motion to be vertical only. Then re-enable the grid." Yes, this is perfect!
In reply to I have to backtrack to seek by [DELETED] 448831
Have a look at PR #786 and PR #798 , which seem to provide a wonderfull aid for dragin things around
In reply to I have to backtrack to seek by [DELETED] 448831
Sorry, for multiple items at once, indeed, you need Inspector.
I was envisioning fingerings being adjusted as you go. They are already selected as you add them, so you don't even need to click anything - immediately after entering the fingering, Ctrl+Up twice and you're done. But if you've entered fingerings first and then you are entering articulations, you'd probably want to be selecting several fingerings at once - the fingerings for all notes with articulations - and moving them together. Inspector would work well for this, except that different articulations are different sizes and might be positioned differently based on the specific notes, so there is no guarantee the same offset would apply to all the fingerings that need adjustment. So it would still be a one-at-a-time adjustment. But of course, that's true for dragging too - it only works if all the selected elements need the same adjustment.
Again, glad the shortcuts to toggle the grid will turn out to be useful. But I assumed you were originally hoping for something simpler still - something like, holding Alt as you drag would temporarily override the grid. Unfortunately, that has meaning in some window managers already (used to drag the window), and shift & ctrl are already taken as drag modifiers in MuseScore. And we are already short a good way to say you want to initiate a drag of several elements - right now we use Ctrl for this, but that's also the way you specify you want to constrain dragging to horizontal only. So we have a bit of a log jam in this area at the moment. Not that there is no solution here, but this is why I think it makes sense to take a hard look at requests like this - making sure this is really the best way to solve the problem, and that we don't don't have to give up something else of greater value to get it.
In reply to Sorry, for multiple items at by Marc Sabatella
Got it! Thanks again, Marc.