As you can see in my screenshot, I appear to have done something wrong, resulting in the lower stave to account for MUCH too much vertical spacing. Looking in the Layout Options, I don’t see anything that would seem to relate to an object like the custom line, and I’m failing to think of where else an applicable setting may reside. Any thoughts? Obviously, I can manually move it, but I’d like to find a way to have the box operate reasonably.
It might be easiest to move the box to an earlier rhythmic position so that Dorico doesn’t include it in the vertical spacing decisions at bar 415, and then manually move it where you like. This might work.
I don’t really follow what you mean? The whole point of making the box as a custom line is so that it automatically stretches and attaches to the music. Even if I were to attach it somewhere “wrong”, shouldn’t it still produce spacing issues at that point then too?
This would be incredibly above and beyond any expectation I would have, considering this is a custom line. Thank you!
In revisiting the passage to clear out the rest of the music and undo manual adjustments I’d made to force it to look right, I found/re-discovered that some of it doesn’t work quite like it showed in the YouTube video. For one, that guy had a “distance from staff line” of -9 for both top and bottom boxes, but I found I needed -3 for my top to sit at a reasonable position. I’m guessing that’s due to the fact I’m measuring in inches, and he’s probably in something else?
The other thing was that, while the top box had no qualms with me changing the spacing parameters such that it would cross the staff (or, just to test with an extreme case, go far, far below the staff), my bottom box would do no such thing. I couldn’t find a setting that would ever let it touch the staff, so I had to manually move it into place. I don’t understand why the bottom would be obstinate on this while the top isn’t. box example.dorico (1.8 MB)
The ideal solution would be for the box to be a single line, with Inside staff placement. Instead of making the box out of two lines, why not create a new “double line” line body with e.g. a line separation value of 12 spaces (or whatever), and then set your start and end caps to provide the sides of the box?
Ah. The idea of the two lines was so that it could function with collision avoidance - stretch up or down depending on the range of the notes (either automatically, or manually by moving only one of the lines away from notes). Though in most cases, notes aren’t spanning ledger lines above AND below, so I suppose doing this may make more sense and just pushing the box up or down as needed and duplicating it and making a taller one when the need arises.
However, for just my own understanding of the program, I’m still confused about the function of the bottom line being different from the top one. Am I experiencing a glitch, or is this intentional behavior - that the top line is willing to cross the staff but the bottom one is not? It doesn’t seem like this happens in the Youtube video, so I’m still thinking I should get it to work as envisioned, I just don’t understand what I’m doing wrong.
Taking a look at it, when I tried to re-apply the box to those notes, it runs into both the first and the last note. Did you manually widen the box so it doesn’t collide, or did I apply it wrong?
Thanks, I’m aware of how to apply manual adjustments. I was just wondering if the default placement resulting in collisions was happening for you as well (requiring expanding the box left and right from where it ends up based on the selection applied), or if you had it so that it wrapped around the notes automatically like how it looked when I opened your file.
Hi Daniel,
Jesper was very helpful and sent me a file with your suggestion implemented.
With a bit of experimenting, I’ve realized that the horizontal placement is different if the line is defined as “Inside Staff” vs “Above” or “Below”. With the Above/Below options, the left edge situated to the left of the first selected notehead.
Here, you can see in the Vla how the box as defined as a “double line” “Inside Staff” placement sets it to start after the first note.
However, in the original methodology with separate “box top” and “box bottom” approach, the default horizontal placement actually encompasses the left-most note (although the height is much more fiddly, and it can result in the strange spacing that I started this post about). I’ve been messing with the “distance from staff line” and “distance from item” parameters so at the moment this actually looks OK, although I lack confidence this will be good consistently.
My question though, is this - is the “Inside Staff” position supposed to start after the first note, as it appears here? I’m just wondering if this is intended behavior, or if there’s something off here. And if intended, is there any way to alter the horizontal positioning into a setting/within the line definition so that I could make it apply to the left of the notehead instead of the right of it?
Hmmm I just checked against a bunch of default lines, and they all started directly over the note, as you can see in this shot. They’re all behaving the way the Above or Below parameters are acting
And noticing this, I just went through every single line provided, and I’ve realized that they’re all actually set as “above” positioned. None of the provided lines utilize “below” nor “inside staff” as their position, so there’s not actually a line provided by Dorico to show that they meant for the “inside staff” option to be offset to the right relative to “above” or “below” positions.
I meant that with inside staff, it’s logical that they start just after the note.
It would be nice with a horizontal offset parameter in the definition.
Jesper
Oh, yes, I see. I do find it a bit funny they don’t include any “inside staff” lines with the program, as the fat inside staff arrow is a reasonably common thing. But yes, if you’re doing that, you’d want it to appear after the note, so with that thought process it does make sense why they’d build in an offset.
Hopefully in a future update they’ll make it an offset parameter, which they just have with a default value of 1/2 or whatever it is currently.
