Menu
▾
▴
9 Attachments
#2142 accidental right-padding should depend on the tightness of music
Accepted
nobody
None
Enhancement
2012-01-02
2011-12-28
Anonymous
No
Originally created by: *anonymous
Originally created by: janek.li...@gmail.com
When notes are close togehter, accidentals should be closer to the noteheads (their padding should be smaller). See attached "flexible right-padding" examples.
Accidental should always be closer to the note to which it applies than to the preceeding note (unlike in "cary, anti-example.png" taken from our website).
In some occasions a narrower version of accidental should be used (see "squeezed accidentals.png").
Additional shortening of ledgers should perhaps take place.
Related issues:
issue 2141
issue 2143
issue 2144
issue 2145
Originally posted by: lemzw...@googlemail.com
Providing squeezed glyph variants for tight typesetting is a good idea!
Originally posted by: m...@mikesolomon.org
Welcome to my world of pain.
I toyed around with ideas like this in my summer-of-lily but gave up because of the following reason :
In LilyPond, springs and rods are calculated based on the distances between paper columns, which requires knowing the columns' horizontal skylines. What you're suggesting are having conditional skylines that can change in different spacing situations. This means that a given spring-and-rod problem will need to be solved 2**n times, where n is the number of conditional spacing variations that could happen in it. If there are 10ish conditional variations (meaning accidentals) per line, you're looking at compilation times that last well into the end of Western music (if not earth).
I've suggested several times that linear programming & the simplex method (or a commensurately effective solver) could be the solution to these woes, but Han-Wen told me that in the early days of LilyPond this is how things were done & compilation times got outta hand. I'd be interested in seeing how linear programming w/ 10000ish variables would fare on a modern computer - if it's hackable, it may be worth looking into this.
Originally posted by: janek.li...@gmail.com
Mike,
do you mean that generally changing accidentals' right-padding depending on situation is very hard, or is it only the idea of introducing narrower accidentals that may make the computations hard to do?
Originally posted by: m...@mikesolomon.org
The problem is that right-padding is calculated in order to calculate the springs that are then used in spring-and-rod calculations.
The only way this could be pulled off in the current model of LilyPond is if the padding is set as the smaller of the two values and then the larger accidental is slotted in if there is enough room, but this is supposing that the height of the two accidentals are the same. Otherwise, the pure height approximations will use the larger of the two, which would lead to spacing weirdness in certain situations.
Originally posted by: m...@mikesolomon.org
In the current model, I think that the only way to get this sorta thing implemented is by faking a spacing calculation between the two columns and then adding a rod that simulates this sorta padding.
Originally posted by: lemzw...@googlemail.com
This `conditional skylines' approach is overkill IMHO for chords and its accidentals. I would rather consider the accidentals be part of the spring, this is, you construct a chord, then its accidentals, and the accidental configuration is handled as a rectangular block which can be squeezed and stretched horizontally to a certain extent. Wouldn't this simplify the problem so that it can be handled with `conventional' means of lilypond?
Originally posted by: janek.li...@gmail.com
Hmm? Accidentals' right-padding isn't calculated, it's a constant value. It doesn't depend on anything, as far as i know.
"The only way this could be pulled off in the current model of LilyPond is if the padding is set as the smaller of the two values and then the larger accidental is slotted in if there is enough room, but this is supposing that the height of the two accidentals are the same."
Yes, i think this should work.
I also think that Werner has a point. If i understand how Lily horizontal engine works, the solution would produce results like this:
(1) a Notecolumn which has constant width
(2) a spring between NoteColumn (1) and the accidental belonging to next NoteColumn
(3) "accidentalColumn", something like a spring which minimal value equals width of narrow version of acidental and maximum value equal to width of normal version of accidental
(4) a spring between accidental (3) and NoteColumn (5) to which it belongs
(5) NoteColumn
It may not work perfectly, but the results should be good enough i think.
Originally posted by: m...@mikesolomon.org
Springs (in the current LilyPond model) are only between PaperColumns and NonMusicalPaperColumns. To implement your idea, there'd have to be several columns (arpeggio column, accidental column, note column, dot column for example) all of which received springs or rods. This'd be hellish to implement but is doable.
If you wanted to go down this route, you'd have to:
Create an AccidentalColumn grob that implements the paper-column-interface.
Throw all of the accidentals into this grob and NOT into either of the currentCommandColumns.
Make sure that this column got a rank lower than that of the PaperColumn to its right.
Change the main functions in staff-spacing.cc and note-spacing.cc such that they returned different values for accidental columns.
In general, if you want to do this, try to make it as extensible as possible so that a variety of columns could be created. Someone once told me that in computing, there are only three numbers: one, two, and many. We are at two with PaperColumn and NonMusicalPaperColumn, but if we went into many, it'd be impossible to have separate functions for everything & we'd need to come up with some extensible framework for the creation and horizontal spacing of columns.
Originally posted by: janek.li...@gmail.com
"To implement your idea, there'd have to be several columns (arpeggio column, accidental column, note column, dot column for example)"
Indeed, you've reminded me that arpeggios, dots and everything else need this feature too (it looks weird when an arpeggio gets closer to barline than to the notes it affects). Is it worth opening a new issue or should we keep everything here?