Is it possible to set the Beam properties for all beams in a Range Selection?
Is there a way to set the Beam>Direction property for all the beams in a Range Selection?
After importing MusicXML I often find beams set inappropriately to Down or Up. So I'd like to change them all to Auto. But after making a range selection I don't see a Select>Beams button, like the Select>Notes or Select>Rests buttons. It seems if I have anything but a List Selection of notes I can't get to Inspector>Beam. I can't even get there with a List selection of just beams!
I must be missing something. I'd find it hard to believe that beam properties can only be set one at a time.
Any advice or suggestions?
I suppose saving to uncompressed format (mdcx) and running a find/replace could suffice as a a workaround, but I'd rather find a solution within the app.
scorster
Comments
"After MusicXML import I often find beams set inappropriately to Down or Up. "
When the range selection is done, the shortcut Ctrl + R (or menu "Format" -> Reset Shapes and Positions) doesn't lead to the desired result?
In reply to "After MusicXML import I… by cadiz1
@cadiz1 When the range selection is done [use] the shortcut Ctrl + R (or menu "Format" -> Reset Shapes and Positions
That does the trick! Thanks for pointing that out. I sure better remember it!
But since the inspector has beam properties I figured, we'd be able to access them when beams or beamed notes are selected.
Plus there are other properties that I might want to set ... and not necessarily to the default reset:
• What if I wanted to set all Beam>Direction = Down or Up? Only possible with the x key?
• And if I want all beams set to Force Horizontal? Use Format>Style>Beam>Flatten all Beams? I could also set one beam to Force Horizontal and then press the style button -- but that affects the entire score rather than the Range Selection.
I suppose there some purpose in making those properties Inaccessible in the circumstance I described?
Much appreciated!
scorster
Right-click one beam.
Select > Select all similar elements in Range
or since 3.5-ish:
Click one beam
Shift+Click another
→ All beams in that range will be selected.
In reply to Right-click one beam. Select… by jeetee
@Jeetee
Right-click one beam.
Select > Select all similar elements in Range
Here on the Mac the menu item Select all similar elements in Range is disabled in the contextual menu.
However Select all similar elements in Staff works. So that gets me further down the road and I'm able to set Beam properties via the Inspector.
@Jeetee
Click one beam
Shift+Click another
→ All beams in that range will be selected.
Well, best I can tell, all beams in that "range" on THAT staff will be selected.
Good news is: With the techniques you've recommended I can set the beam properties in the Inspector. So thanks!
Changing the size of a Range Selection
For range select, we click to set the selection origin. Then each additional shift click logically extends the range to include the clicked note or clicked full measure. Oddly, attempts to decrease a range selection via shift-click
work by only full measure; shift-clicking a note loses the range selection and results in a single note List Selection. And ... I think the logic is more messed up than that.
All said, I still think it's odd that the Inspector has beam properties made inaccessible by the type of selection.
scorster
In reply to @Jeetee Right-click one beam… by scorster
> "Here on the Mac the menu item Select all similar elements in Range is disabled in the contextual menu."
Make sure to actually have a range selection first, because if you do and that command is still disabled that's a bug that needs reporting and fixing.
> "Well, best I can tell, all beams in that "range" on THAT staff will be selected."
You can shift-click a beam in another staff as well to have all of them on all staves in between the range of your first click and second click selected. It is literally just a faster way to "select all similar elements in range" that doesn't require you to make the range selection yourself first.
> "All said, I still think it's odd that the Inspector has beam properties made inaccessible by the type of selection."
The inspector always only shows controls that apply to all elements in the selection. In a range selection you have included more than just beams (or articulations or notes or ...) so it'll only show the few controls that apply to all of those.
It might be a habit thing for me, but I don't find that odd at all.
In reply to > "Here on the Mac the menu… by jeetee
For MuseScore 4, the Inspector is improved to not give up on mixed selections like this.
In reply to For MuseScore 4, the… by Marc Sabatella
@Marc Sabatella > For MuseScore 4, the Inspector is improved to not give up on mixed selections like this.
Thanks Mark! It's a big relief to hear that the Inspector will be improved in this regard.
@ Jeetee> The inspector always only shows controls that apply to all elements in the selection. In a range selection you have included more than just beams (or articulations or notes or ...) so it'll only show the few controls that apply to all of those.
Right, but sometimes there's the Select buttons that allow us to refine the selection and regain access to the properties in the Inspector.
@ Jeetee> It might be a habit thing for me, but I don't find that odd at all.
As mentioned, what struck me as odd was the lack of Select>Beam button that allows the user to drill back into the Inspector.
But it sounds like v4 will address this issues. I'll be patient. Just thought perhaps I was overlooking something simple or obvious.
Thanks!!
scorster
In reply to @Marc Sabatella > For… by scorster
> "As mentioned, what struck me as odd was the lack of Select>Beam button that allows the user to drill back into the Inspector."
The inspector has indeed some pre-filter buttons to access the most commonly required (or otherwise very hard to filter) items out of a range. Beams isn't one of those.
But if we were to add buttons for everything there you'd basically end up with the selection filter (F6) which already exists as well.
In reply to > "Here on the Mac the menu… by jeetee
@scorster >> "Here on the Mac the menu item Select all similar elements in Range is disabled in the contextual menu."
@Jeetee > Make sure to actually have a range selection first ...
Right. Of course ... if you don't have a range selection you can't select similar items in the range, because no range selection exists.
BUT once I've made a range selection ALL items are selected, so how does one indicate the item to "similarly" match?? Seems like a "Can't get there from here" situation.
In reply to >> "Here on the Mac the menu… by scorster
> "BUT once I've made a range selection ALL items are selected, so how does one indicate the item to "similarly" match?? Seems like a "Can't get there from here" situation."
The base element of similarity is provided by on which element you provide the right-click (ctrl-click) action. Just the same as when you have no range selection or even nothing selected at all.
In reply to > "BUT once I've made a… by jeetee
@ Jeetee> The base element of similarity is provided by on which element you provide the right-click (ctrl-click) action.
Wow. NICE!
Like many things in Musescore that's rather elegant ... but entirely undiscoverable I think, and probably undocumented?
I'm sure to use this technique as a right-click selection filter. Thanks so much!
scorster
In reply to @ Jeetee> The base element… by scorster
It's reasonably discoverable, just be in the habit of right-click things to see what shows up in the menu (not just for MuseScore, it's good practice with any program really). Also, yes, it's documented in the Handbook under "Selection modes".
In reply to It's reasonably discoverable… by Marc Sabatella
Here https://musescore.org/en/handbook/3/selection-modes#all-similar-selecti…
In reply to It's reasonably discoverable… by Marc Sabatella
When I said "probably undocumented" I was referring to Jeetee's enlightening comment that one can identify the base element of similarity by right-clicking it:
@Jeetee > The base element of similarity is provided by on which element you provide the right-click (ctrl-click) action.
I think the manual might mention that essential kernel in Step 2 ... even if it's documented elsewhere. Currently, right-clicking in no way reveals this very helpful feature.
Here's a snippet from the Handbook:
Select all similar
To select all elements of a specific type (e.g., all barlines, all text elements, all staccato markings):
1 Select an element;
2 Right-click and choose Select…;
scorster
In reply to Select all similar To select… by scorster
Perhaps the handbook may be amended to:
1. Select an elementof the type you wish to select;But to me that would be overly verbose in this instance. I mean, there's really no other way to say I want all of "this" without clicking on "this".
In reply to Perhaps the handbook may be… by jeetee
I think it would be valuable to unpack and review the Handbook's coverage of Select All Similar ... and do so one piece at a time.
First, does anyone agree that the Handbook needlessly/erroneously specifies Step 1 as required?
1. Select an element;
When I start at step 2
2. Right-click and choose Select…;
… I get the choices and results that I need and expect.
Best I can tell, Step 1 is entirely superfluous.
scorster
In reply to I think we need to unpack… by scorster
It is true that no selection is needed. As with pretty much every program I know of, the behavior of right-click depends on where you right-click only, not on what might or might not be going on with selection.
In reply to It is true that no selection… by Marc Sabatella
@ Mark Sabatella It is true that no selection is needed.
Agreed.
I've updated the Handbook entry.
And because I saw no reason to have a list for just two actions I removed the list numbering.
scorster
In reply to It is true that no selection… by Marc Sabatella
Not quite true, in fact it was pointed out that MuseScore was unusual in that right clicking did not change the current selection, and this has been fixed for MU4, but the way it's been fixed isn't exactly in line with how other apps work (not that there's any one consistent behaviour between them, particularly when shift/ctrl are held down while right-clicking).
Essentially now if you right click on something (or an area) that's already selected, the selection is unchanged, otherwise whatever you click on is treated as the "new" selection (which may be added to the current selection if SHIFT or CTRL are down). And I believe that means if you right click in an area with no elements, everything is deselected (which is consistent with how many other apps work, at least in Windows).
In reply to It is true that no selection… by Marc Sabatella
Btw, one related thing I forgot about until just now - for quite some times there were bugs in which element would actually be affected by commands in the right-click menu. The intent is it should be the element you right-clicked, but for a while if you had an element selected at the time, it would be affected instead, or in addition. That could be why the Handbook is off.
In reply to Select all similar To select… by scorster
I still don't understand what you mean about it not being discoverable. As with virtually every program I have ever used, you discover what's in the right-click menu by actually right-clicking. Which "essential feature" are you saying is not revealed?
In reply to I still don't understand… by Marc Sabatella
Regarding discoverability, this appears in the Handbook:
The "chosen object"? Chosen when? By what method?
I think the entire section would be clearer if rewritten:
It's the part highlighted in green that clarifies. The problem is that the Select menu does not appear (hence no All Similar Elements in Range Selection menu item) until the user applies a secondary right-click to identify the element to match to.
scorster
In reply to This appears in the Handbook… by scorster
"Discoverability" to me means, can you figure it out without looking it up in the Handbook. Not whether or not the Handbook contains errors or is unclear. Again, every computer in the world works the same way as far as right-click - it's based on what element is under the mouse the moment you right-click it, Handbook or no Handbook. That's my point. The Handbook can use clarification, sure, but that has no bearing whatsoever on whether the feature is "discoverable" or not.
In reply to "Discoverability" to me… by Marc Sabatella
@Mac Sabatella The Handbook can use clarification, sure,
Do you think my rewrite of the Select menu items is an improvement?
If so, would you recommend I put it in the Handbook?
scorster
In reply to @Mac Sabatella The Handbook… by scorster
Barring any objects, in the next day or so I'll update the Handbook (as mentioned above and) as shown here:
scorster
In reply to Barring any objects, in the… by scorster
Looks good to me. Makes sense to also mention the new method I implemented recently for select similar in range: just click one element, shift+click another of the same type.
In reply to Looks good to me. Makes… by Marc Sabatella
Marc Sabatella worte> I implemented [a new method to] "select similar": just click one element, shift+click another of the same type [to select all similar elements between the click and shift-click].
Please tell us more about this new function that Jeetee cited earlier in this thread. In my opinion you're created the simplest way of selecting—for example—all beams between the clicked beam and the shift-clicked beam. And thankfully the result is a List Selection, so the Inspector is available for editing properties.
Your shift-click method also works on flags, chords, down strokes, up strokes, accents, dynamics, fingerings. However I get a surprising result when I try it on repeats.
In contrast, when applying the same same keystroke to note or a rest obviously we get the familiar Range selection, which of course includes all notes and rests between the clicks and child objects as well.
I'd like to document:
• which kinds of shift-clicked objects result in a List Selection
• which kinds of shift-clicked objects result in a Range Selection
• if any are kind of shift-clicked objects are immune or perhaps intentionally excluded from selection
scorster
In reply to Marc Sabatella worte> I… by scorster
The Handbook's Select All Similar entry now updated.
As mention in my previous post, I'd like to document:
• which kinds of shift-clicked objects result in a List Selection
• which kinds of shift-clicked objects result in a Range Selection
• if any are kind of shift-clicked objects are immune or perhaps intentionally excluded from selection
Also, is there an accepted/preferred means of MarkDown indenting used in the Handbook? (I used hard spaces for now, but those will get ugly if the reader views in a narrow browser page.)
scorster
In reply to Marc Sabatella worte> I… by scorster
The facility works quite simply: first it actually creates a range selection from the time position of the first element to the time position of the second, then it does the equivalent of select / all similar elements in range selection. For repeats, I guess you mean the fact that the first repeat isn't actually part of the range selection. That's because barlines belong to the previous measure. Or maybe you mean the fact that "similar" means all barlines, not just repeat barlines? That's the same for the regular "select all similar" command, since they use the same code.
The new facility (introduced, I think, at 3.5) doesn't change a thing about how click/shift+click always worked in the past. Click/shift+click on a note or rest continues to make a range selection, same as it always has. The only thing I changed was what happens when shift+clicking something other than a note or rest. Formerly, it did nothing at all. Now, it creates a range selection and then selects all similar elements within it.
In reply to The facility works quite… by Marc Sabatella
Marc Sabatella > The facility works quite simply: first it actually creates a range selection from the time position of the first element to the time position of the second,
Apparently the range selection is invisibly created ... and this is nothing the user would notice or need to know. Right?
Marc Sabatella > ... then it does the equivalent of select / all similar elements in range selection. Click/shift+click on a note or rest continues to make a range selection, same as it always has. The only thing I changed was what happens when shift+clicking something other than a note or rest. Formerly, it did nothing at all.
Marc Sabatella > For repeats, I guess you mean the fact that the first repeat isn't actually part of the range selection. That's because barlines belong to the previous measure.
Well, I'd think logically (and certainly from the user's standpoint) the selection would always include first clicked object, the shift-clicked object, and no more. I lightly assume that's true in all other cases—without having performed any exhaustive testing.
Here I've clicked on the opening repeat in M57:
Here's the result when I shift-click on the closing repeat in M58:
Based on your description of the inner workings I can see why these "fencepost" errors.
Marc Sabatella > Or maybe you mean the fact that "similar" means all barlines, not just repeat barlines? That's the same for the regular "select all similar" command, since they use the same code.
I understand that they're all barlines, but there might be value in offering great granularity over the type of barline included in the resulting list selection.
scorster
In reply to Marc Sabatella > The… by scorster
Yes, we could indeed special case situations like this to make sure the clicked elements are present in the result whether they are technically part of the range or not. Offhand, I’d guess that other elements that are attached to the final “tick” of the previous measure could have the same issues - like breaths or pauses, say.
And yes, the range selection created is internal only. I’m mentioning it only to be clear about how it actually works - it really is the same as doing the range selection yourself.
As for more granularity, that’s what Select / More is for.
In reply to > "Here on the Mac the menu… by jeetee
@scorster >> "Well, best I can tell, all beams in that "range" on THAT staff will be selected."
@ Jeetee >You can shift-click a beam in another staff as well to have all of them on all staves in between the range of your first click and second click selected. It is literally just a faster way to "select all similar elements in range"
Okay. Thanks, that works!
In reply to >> "Well, best I can tell,… by scorster
Just as an aside (as to, "in all programs"), I note that in Thunderbird, if I select a block of text, and then right click on a word elsewhere, the context menu I get depends on what was in the selected block. It is not just dependent on the word I right-clicked on to bring that menu up.
Then, in MS Word, if I select a block of text and then right click elsewhere, the block selection is canceled.
And so forth.
Doug