Automatic Staff/System Spacing

Discuss the rules of notation, standard notation practices, efficient notation practices and graphic design.
Knut
Posts: 867
Joined: 05 Oct 2015, 18:07
Location: Oslo, Norway

Re: Automatic Staff/System Spacing

Post by Knut »

jan wrote: 08 Mar 2017, 08:56 If if it had taken the vertical distance as radius, it would have detected a closer collision (between p and the top left corner of the G box instead of between the slur and the top of the G box), and the bottom system would have probably gotten a more pleasing position a bit further down.
That's a great idea, and employing this radius principle more broadly may also make the results more robust.
jan wrote: 08 Mar 2017, 08:56 I think systems 2 and 3 from the video (image below) are too far apart and would have looked better if the calculation took into account some of your thoughts about the "center" of the top/below staff areas. There is only a rather small peak in the middle of the 3rd system ("F Grave") and at the very left ("E") which leads to a very large system distance. The wide hairpin on the top staff seems to be a "calm" element which could come a little closer to the other staff in this case.
I agree.
I know I said above that Tempo markings take an overall precedence, and that the top margin should align with it. In cases like this, however, I would ignore this principle to avoid the excessive space. It should be said that I generally tend to ignore rehearsal marks altogether (especially the border), instead relying on a predetermined amount of blanket space between staff groups or systems that is large enough to fit them. In this particular case I would also entirely or partially disregard even the tempo marking, bringing the top margin down as needed, but no more than above the tuplet bracket.
jan wrote: 08 Mar 2017, 08:56 - take into account the overall size of the surface area covered above/below staff
Awesome! How would you do that, btw? This sounds like a great premise to base rules and conditions on, and from your excellent list of conditions, it looks like this could be a very robust plug-in in the end.
User avatar
jan
Posts: 84
Joined: 22 Jun 2016, 08:29

Re: Automatic Staff/System Spacing

Post by jan »

>>take into account the overall size of the surface area covered above/below staff
>Awesome! How would you do that, btw?
You mean how I would calculate the overall size of the surface area above (below) the staff?
Currently I have the coordinates of the "skyline", i.e. the vertices of the boundary box above/below staff (marked as + in the image below).
dots.jpg
dots.jpg (69.69 KiB) Viewed 12578 times
The surface area is the sum of the distances between each point of the boundary box and each corresponding point on the staffline.
And from this area definition it's easy to calculate the mathematical center which then must be adjusted according to peaks - if necessary.
Knut
Posts: 867
Joined: 05 Oct 2015, 18:07
Location: Oslo, Norway

Re: Automatic Staff/System Spacing

Post by Knut »

jan wrote: 08 Mar 2017, 11:39 >>take into account the overall size of the surface area covered above/below staff
>Awesome! How would you do that, btw?
You mean how I would calculate the overall size of the surface area above (below) the staff?
Currently I have the coordinates of the "skyline", i.e. the vertices of the boundary box above/below staff (marked as + in the image below).
dots.jpg
The surface area is the sum of the distances between each point of the boundary box and each corresponding point on the staffline.
And from this area definition it's easy to calculate the mathematical center which then must be adjusted according to peaks - if necessary.
Thank you for that explanation, Jan!
That's quite ingenious!

BTW, I just made a final plea to MM for your support (if a public release is indeed entirely out of the question) on the official Finale boards. I doubt it has any effect, but in light of recent protests, you might consider contacting them again.
User avatar
OCTO
Posts: 1742
Joined: 05 Oct 2015, 06:52
Location: Sweden

Re: Automatic Staff/System Spacing

Post by OCTO »

Wonderful, Jan!

Apropos your focused conversation, the staff/system spacing is a very complex issue indeed.
I use to to describe it as a BW-balance; it means that when looking at one page of music, there should not be black or white spots, but music should be placed "as dense as possible" in order to keep coherence. "As dense as possible" doesn't mean that it is as dense as possible, rather that no part of music should be positioned outside of the musical flow, herewith keeping the density equal.

This example is wonderful.
shot 1.jpg
shot 1.jpg (230.08 KiB) Viewed 12571 times
Finale is unable to automate this, and I am unsure if Sibelius would be able to do this in the same way as it is engraved. Using rounding box exclude possibility for STAFF KERNING, which is actually a great space saver, and not only that but it makes score to look more connected.

Does Dorico make any staff kerning possible, by automation?
Freelance Composer. Self-Publisher.
Finale 27.3 • Sibelius 2023.5• MuseScore 4+ • Logic Pro X+ • Ableton Live 11+ • Digital Performer 10+ /// MacOS Monterey (secondary in use systems: Fedora 35, Windows 10)
User avatar
jan
Posts: 84
Joined: 22 Jun 2016, 08:29

Re: Automatic Staff/System Spacing

Post by jan »

Thanks, OCTO for your input!

Yes, making a condensed score and spacing a part are two different things.

Although at first sight there are only few rather simple rules to be implemented for your Don Juan example that are different from the spacing used in my video above:
- the minimum distance between vertically colliding elements is very small
- if necessary, put dynamics on a rest before
- put tuplet numbers on top, if otherwise very low (and probably vice versa)
- hairpins may overlap with stafflines (and can be set to diagonal, if necessary)
- accents can be slightly moved to the right if colliding with a stem in the staff above (see accent in m.3)
- flat slurs, if necessary (see measure 4 bottom staff: ok, that's indeed ugly in Finale)

I will see what can I implement. It is a bit more complex process than in part processing. Because after detecting the "colliding skyline peaks" the critical musical symbols (dynamics, articulations, tuplet numbers) need to be shifted to avoid those collisions.
After fixing these elements, the spacing process has to be re-run. But it's not impossible ... at least not with only those rules mentioned above.
User avatar
jan
Posts: 84
Joined: 22 Jun 2016, 08:29

Re: Automatic Staff/System Spacing

Post by jan »

Here is the first result of automatic spacing for condensed scores as described above. Thanks again, OCTO, for the input.
The parts are processed as usual, but the score gets a condensed look as in the screenshot above.
(Note: tuplet number collisions with slurs and hairpins are not yet supported by the Perfect Layout plugin, that's why they are not automatically corrected in the video)
Screencam video that demonstrates the process in detail: http://www.youtube.com/watch?v=_IenL_wKKhI (video length: 43secs)

output_GxRGXX.gif
output_GxRGXX.gif (257.07 KiB) Viewed 12525 times
This is, of course, only a limited example for testing all "condensing" features, but still a very good starter.
Knut
Posts: 867
Joined: 05 Oct 2015, 18:07
Location: Oslo, Norway

Re: Automatic Staff/System Spacing

Post by Knut »

That's great, Jan!

One thing I noticed is that only the tuplet number on the second staff, m. 2 is flipped. I would think that either all staves should be subject to this behavior or none at all. The way it works now seems inconsistent.
User avatar
jan
Posts: 84
Joined: 22 Jun 2016, 08:29

Re: Automatic Staff/System Spacing

Post by jan »

It's indeed a bug, that it was shifted in the second staff, because in the second staff it is not relevant to staff spacing.
What is more difficult and might result in other collisions is to shift it in all staves no matter if there are collisions, i.e. also in the third staff.

Consistency between the staves is indeed a problem and not so easy to achieve as the plugin system usually (with a few exceptions) works staff by staff and not measure by measure.
Other inconsistencies:
The hairpin bottom line in m.4 in staves 1 & 2 is horizontal, in staff 3 it's not (though it probably will when the other staves of the original score were added).
The accent articulation is m.3 staff 3 is slightly shifted to the right, but not in the other staves.
The ff in staff 3 isn't shifted to the left either as there is no collision.
Last edited by jan on 10 Mar 2017, 11:14, edited 1 time in total.
Knut
Posts: 867
Joined: 05 Oct 2015, 18:07
Location: Oslo, Norway

Re: Automatic Staff/System Spacing

Post by Knut »

That's what I thought!

I think a certain amount of inconsistency is to be expected as some of these decisions will depend on the context and matter of taste, which is difficult, if not impossible for a plug-in to address without explicit options.

After all, you have to leave something for us engravers to work out. :)
Knut
Posts: 867
Joined: 05 Oct 2015, 18:07
Location: Oslo, Norway

Re: Automatic Staff/System Spacing

Post by Knut »

BTW, two additional aspects which it would be nice if this plug-in could address in condensed situations are hairpin opening width and stem length. (Slur height is a related aspect to this, but I believe you already have it on your list above.)

Would this be possible?
Post Reply