Barline grip handles - what does the top handle do?

• Aug 31, 2021 - 09:02

I'm trying to work out why barlines have two grip handles - the top one doesn't seem to do anything?
And how do you adjust them using the keyboard?
(I actually couldn't see how this was true for brackets either, but have some code now for MU4 that allows using up/down key to extend brackets, one staff at a time. But why don't brackets have a top grip handle? There doesn't seem to be any good reason you shouldn't be able to adjust the "top staff" that a bracket is attached to. Brackets have their own special problems because they get deleted/recreated on layout, so get deselected, but I have a fix for that too).


Comments

Good call. Brackets only have the bottom handle, makes sense for barlines too.
Although you can extend the barline upwards using the Inspector, so the upper handle not doing anything seems to be a bug. But then again the lower handle also doesn't allow for those fine tunings, but just the "Span to next staff"

Once upon a time barlines were implemented very differently, and it was at that time possible to drag the upper handle to extend a barline upward. That's no longer a thing, but the handle was I think left in place as there was some intent to consider trying to reimplement that drag behavior for the new barline implementation. It just never happened.

The current implementation considers barlines extended through multiple staves to actually be a whole series of barlines, one per staff, with the "span to next staff" property set. The old implementation saw them as a single barline spanning multiple staves. It was a pretty painful transition with many bugs, most of which were fixed around 3.1 or 3.2 so. But every once in a while you see issues that are probably traced to this re-implementation not having gone so smoothly, particularly on import of older scores.

In reply to by Marc Sabatella

It actually looks like it wouldn't be that hard to allow adjusting the top handle, and in fact for a barline on the bottom staff that's the only thing that would be meaningful (currently it has two useless grip handles!).
For now I've made a change to only show the bottom handle, but I have to admit the top handle did serve at least some purpose, which is to make it clear where the barline started - while you can just make out that above that the line changes from blue to black, it's not super obvious even in good light as someone with no colour blindness issues.
I will say the fact that it breaks the barline on the staff below the one you drag the lower handle to isn't really expected, and means where you want to adjust a barline on the top staff to extend over a large number of staves you need to be zoomed out enough to see all of them and then drag it all the way to the bottom, even if for instance, it was just the top staff that had a broken barline to begin with.

In reply to by Dylan Nicholson1

It's actually weirder than that, because even though the only way to ensure a barline doesn't get broken beneath the staff you drag on to is to drag the handle to the bottom staff, after doing so it snaps back to the top of the staff below the one the barline starts at, even though the resulting barline now shows as extending to the bottom staff. And at least in some cases if you've use the CTRL key to adjust just a single barline (rather than all barlines), there's no way to tell you did this, which can cause some weird inconsistencies when trying to adjust all barlines later (related to the fact that not just the barline you clicked on originally has changed, but the one in the staff below too).
What would be the downside if it were changed so that dragging a barline handle down didn't affect whether the barline on the lower staff got broken? I.e. the only way to break a barline would be the drag the handle up so it's close to the staff it belongs to, which seems logical enough. We can still preserve the behaviour of being able to join up several broken barlines by dragging down over multiple staves.

In reply to by Dylan Nicholson1

I'm not following what you mean here. Are you talking about taking away the ability to drag a barline down several stave and have that automatically set the span to next staff on each of the affected barlines? I would definitely not be in favor of removing that important feature. It's designed to work so that dragging a barline down connects all staves up to the point where you release.

I guess you probably mean, what happens if you drag down a few staves but stop at a point where staves were already joined. At this point, MuseScore needs to guess. Were you intending to create a brand new grouping to replace the old (which is the current assumption), or were you just trying to connect two existing groupings (which is what I assume you were trying to do in your example).

In general it would be impossible to know, but perhaps a reasonable heuristic could be devised that would cover common cases. Like, if you decide you want to join woodwinds to brass, you'd probably do it by extending just the bottom woodwinds barline down a single staff to meet the top brass. In that case, we could elect to do that and that only. But if you extend it down for two staves (to encompass both horn parts in an orchestral score, say), we could interpret it more literally and assume you really are trying to add just those two horn parts to the woodwind group.

In reply to by Marc Sabatella

Yes, I meant the latter case. The current behaviour just seems asymmetrical - if I drag a spanning barline's lower grip handle up to the staff above it just breaks the span as expected, but if I change my mind and drag it back, it now changes the barline span for the lower staff.
As for your heuristic idea, why bother? Increasing the extent of a barline and breaking an existing one seem to me to be two different actions.

Also I confirmed that the main issue with using CTRL+drag to adjust an individual barline is that once you've done this, a regular drag without using CTRL no longer works for adjusting that particular barline (I have a fix for this though).

In reply to by Dylan Nicholson1

Somehow I'm still not following, then - an actual score as example would help. But I thought mine was pretty clear. Take an orchestra score, then drag the bottom woodwind staff's barline down to encompass the two horn staves. Yes, I expect it to break there - if I wanted the barline to encompass all brass staves, I would have dragged it through all brass staves. I would have to say that's likely to be the case any time I drag a barline down through more than one connected staff - otherwise why not stop at the first? But maybe you have an example that would make it clear why sometimes you might drag through more than one staff, stop before the and of the group, and not expect it to break.

In reply to by Marc Sabatella

Well no, I don't get why should it break the barline below the horn staff? All I want to do is join the barline between the Bassoon staff and the upper Horn staff, just as if I'd checked "span to next" in the inspector. If I then want to break the barline between the lower Horn staff and Trumpet that's a separate action.
But currently if you want the barline to extend to the tuba staff, you have to drag it all the way down there, but then on letting go the handle jumps back up to the first horn staff, which doesn't seem expected at all.

In reply to by Dylan Nicholson1

Having played around a bit more I think I can see that it makes sense to break the barline if you drag the lower handle to the very bottom of a specific staff, i.e. indicating "this is where I want the barline to end".
But currently it also breaks it if you drag it to the top of that staff, even though this not where you want the barline to "end", but where you want it to join up to the next one.
That wouldn't be that hard to code up (e.g. only break the barline after a staff if the dragged handle is closer to the bottom than the top of the staff when released).

In reply to by Dylan Nicholson1

NOT FOUND: bracket.png

This is what happens currently if you release the mouse button once you have the barline nicely joining up with the one below it, which sure feels unexpected to me.

Also at least a few times I was unable to undo adjusting barlines this way, specifically if you press certain keys while dragging, and that seems to apply to all dragging actions. It's not hard to cause crashes dragging elements around either. Is there ever a case it would useful for pressing a key while dragging to do anything? I was thinking it might be nice to be able to press "Esc" to cancel but even that's problematic if you still have the mouse button depressed (if you're not moving grip handles, the code assumes you're panning the score around...).

In reply to by Dylan Nicholson1

Perhaps think of it as not so much connecting two barlines, and more like creating a new one.

When you drag the handle to a lower barline, you create a new barline system. MuseScore breaks line below the staff you connected because you created a new system of lines.

When you drag the handle all the way down to the bottom the tuba staff, you are telling MuseScore that this is the new barline system.

It's not like drawing on manuscript paper. Should it be? I don't know.

In reply to by Dylan Nicholson1

My example is a standard orchesteal score with two horn staves (I & III, II & IV). Right now horns are part of the brass. I decide I want to include them in the woodwinds (which is of course the whole reason they are at the top of the brass - because they are often voiced with the woodwinds). So, I take the bottom bassoon part and drag it down to encompass the two horns. I'd love it if that did the job completely - I just told MuseScore exactly how far I want the woodwinds to extend. I release at the second horn staff, so I want the barline to end there, seems plain and simple enough.

As I said, I can easily believe there might be other cases where for whatever reason, you are dragging a barline down to some very specific staff in the middle of an existing section but for whatever reason, don't actually intend for the barline to end at the staff you just released. No doubt such cases exist, I just can't think of any right now. Hence my request for an example.

The only case I can think of where you wouldn't want the barline you just extended to actually end at the staff you dragged to is the special case of dragging down to meet the top staff of an existing section. So for instance, if instead of dragging the barline from the basson to the second horn staff, if I release at the first. Here, I might well have been thinking, I really just want one big "winds" section. So that's kind of heuristic I proposed. More precisely, if the target staff does not already have a span into it (eg, the first horn staff), don't break the span out, If the target staff does already have a span into it (eg, the second horn staff), do break the span out.

My point is, if the goal is simply to join the two sections, I'd release immediately at the first staff of the new section. if I continue to drag past that first staff of the brass section and release anywhere else within that section, I have to imagine my reason for that is that I do in fact want the barline to 8end* there. Why else would I drag to such a specific location in the middle of a section rather than stopping at the top?

In reply to by Marc Sabatella

Sure, I can see that makes sense now - ie if you drag the barline handle onto a staff that the barline is already broken before, you're just joining, but if you drag onto a staff that the barline was already joined to, you're establishing a new end point, so it makes sense to break after it. That's easy enough to implement. Though doing it based on whether you drag to the top or bottom of a staff makes just as much sense to me at least.

In reply to by Dylan Nicholson1

If I'm working on an orchestral score an d thinking about joining barlines, I'm probably zoomed out to the pint where I'm not really differentiating between top and bottom of staff when releasing. I'm just aiming for the general vicinity. I don't think I'd want a one or two millimeter difference in where I release the mouse to be the determining factor. But no doubt there are other possible heuristics to employ as well.

Do you still have an unanswered question? Please log in first to post your question.