Re: Re: Issue 2245: always align dynamics and lyrics on main notehead (issue 108270044 by janek.lilyp...@gmail.com)
Hi,
2014-07-01 21:35 GMT+02:00 markpole...@gmail.com:
This patch is problematic for me.
Firstly, when a lyric syllable extends to the next note (as with a slur
or tie), it is my understanding that the lyric text should be
left-aligned with the left-most note of the chord. See Issue 3521:
http://code.google.com/p/lilypond/issues/detail?id=3521
This patch prevents the 3521 workaround from working, which is bad IMO.
Secondly, to my eye, I think the ideal alignment for a center-aligned
syllable on a harmonic second (suspended) dyad would be center-aligned
with the stem, and not with the NoteColumn.
Actually, NoteColumn contains all noteheads (including suspended
ones), so aligning to NoteColumn is the same as aligning to stem (in
case of chords with seconds).
No idea how easy or hard
that would be to code,
With my patch that you are reviewing? Trivial - it's already there ;-)
While I think that it's better to always align lyrics to the main
notehead, I knew that some people woul prefer to do this otherwise,
so the patch allows to choose how to align LyricTexts (and
DynamicTexts):
\markup Aligned on main notehead (default):
\new Staff {
g' f'2~ q
e'' d''2~ q
g' f'1
}
\addlyrics { la __ la __ la }
\markup Aligned on whole notecolumn:
\new Staff {
g' f'2~ q
e'' d''2~ q
g' f'1
}
\addlyrics {
\override LyricText.X-align-on-main-noteheads = ##f
la __ la __ la
}
Tada!! (see the output here:
https://lilypond.googlecode.com/issues/attachment?aid=22450016000name=2245-example-for-mark.pngtoken=ABZ6GAd_97MyGubnBUDOhPTmY_JHF76TaQ%3A1404282296494inline=1)
And the alignment will be consistent regardless of input order -
either aligned on main notehead, or on the whole notecolumn, depending
on property X-align-on-main-noteheads.
As i didn't know that this problem affects LyricExtenders, this
version of my patch isn't changing their behaviour at all. I'll look
into the code and try to make them consistent as well.
How do you like this? ;-)
https://codereview.appspot.com/108270044/diff/40001/input/regression/text-spanner-attachment-alignment.ly#newcode21
input/regression/text-spanner-attachment-alignment.ly:21: \repeat unfold
2 {c'4 _ \markup { LONG } }
git complains about trailing whitespace here.
It was already there before, but i'll remove it in the next patchset.
best,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \magnifyMusic stem-length enigma
Mark Polesky markpole...@gmail.com writes:
Can anyone help me solve this?
Why do these two beam groups have different stem lengths?
If the beam/stems were mirror images of each other, the noteheads in the
left group would be closer to the beams than the noteheads in the right
group since the noteheads are attached to the right of the stems rather
than being centered on them.
It would be an interesting question whether one should actually
disregard this in the distance calculations in order to avoid
quantization introducing symmetry artifacts like this. Or perhaps do
a mixed strategy: make distances that would provide the proper clearance
regardless of whether the notehead would be attached to the right or the
left of the stem.
I prefer the second one, but I have no idea how to get the
first one to look like that.
\version 2.19.9
\relative c'' {
\magnifyMusic 0.5 {
c32[ c d d] d[ d c c]
}
}
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB failing
Please push this patch, then I can kick GUB off again. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES: The next countdown will be on July 5th.
Hello, Here is the current patch countdown list. The next countdown will be on July 5th. You can always view the most current countdown list here: http://code.google.com/p/lilypond/issues/list?q=Patch%3Apush%2Ccountdown%2Creview%2Cnew%2Cwaitingcolspec=Patch%20Owner%20ID%20Summarysort=patch PUSH: Phil Holmes: Patch: Minor update to Gregorian section of NR http://code.google.com/p/lilypond/issues/detail?id=3977 James Lowe: Doc: Snippet 'Create Delayed Turn' uses old syntax http://code.google.com/p/lilypond/issues/detail?id=3970 Mark Polesky: Improve output of scheme-engraver.ly regtest. http://code.google.com/p/lilypond/issues/detail?id=3968 James Lowe: Extending 2.3.2: Add sentence to definition to clarify point further http://code.google.com/p/lilypond/issues/detail?id=3955 COUNTDOWN: David Kastrup: Patch: Avoid define-public and define*-public with curried definitions http://code.google.com/p/lilypond/issues/detail?id=3983 Phil Holmes: Patch: Adds incipit section to NR http://code.google.com/p/lilypond/issues/detail?id=3980 Janek Warchoł: Patch: cleanup alignments of various grobs (follow-up to 3254 and 3962) http://code.google.com/p/lilypond/issues/detail?id=3978 James Lowe: XML: 02a-Rests-Durations.xml has incorrect last note duration in the MusicXML test suite http://code.google.com/p/lilypond/issues/detail?id=3974 James Lowe: XML: 01b-Pitches-Intervals.xml has incorrect number of measures in the MusicXML test suite http://code.google.com/p/lilypond/issues/detail?id=3973 Devon Schudy: Patch: Don't depend on obsolete Guile features. http://code.google.com/p/lilypond/issues/detail?id=3972 David Kastrup: Patch: Pitch alterations use SCM rather than flower rationals http://code.google.com/p/lilypond/issues/detail?id=3967 James Lowe: Patch: Changes.tely updated - 2.19.x up to June 2014 http://code.google.com/p/lilypond/issues/detail?id=3965 James Lowe: Patch: Doc: Updated Roadmap text file http://code.google.com/p/lilypond/issues/detail?id=3963 Mark Polesky: Scale slurs and ties when using \magnifyMusic. http://code.google.com/p/lilypond/issues/detail?id=3942 Janek Warchoł: unnecessarily wide spacing caused by Lyrics http://code.google.com/p/lilypond/issues/detail?id=2462 REVIEW: James Lowe: NR 4.5.4: rename node Line length to Line width http://code.google.com/p/lilypond/issues/detail?id=3982 James Lowe: NR 1.2.1 - Tuplets - could be made clearer with regard to direction http://code.google.com/p/lilypond/issues/detail?id=3956 Janek Warchoł: wrong/inconsistent placement of lyrics and dynamics under suspended notes http://code.google.com/p/lilypond/issues/detail?id=2245 NEW: James Lowe: set-bar-number-visibility appears to be unused http://code.google.com/p/lilypond/issues/detail?id=3351 WAITING: Urs Liska: Patch: Issue 3916: Add \alternatingTimeSignatures http://code.google.com/p/lilypond/issues/detail?id=3918 Janek Warchoł: Positioning of 8 under clef symbol in G_8 clef http://code.google.com/p/lilypond/issues/detail?id=3186 Mike Solomon: Patch: Prevents vertical axis groups with empty skylines http://code.google.com/p/lilypond/issues/detail?id=3156 Mike Solomon: Patch: Removes the translate_axis call from axis-group-interface outside-staff positioning. http://code.google.com/p/lilypond/issues/detail?id=3134 David Kastrup: Patch: Implement music functions in Scheme rather than C++ http://code.google.com/p/lilypond/issues/detail?id=2716 Thank you, James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB failing
Pushed to staging as commit 7c6becbfa9deba7e58af8780e3ea2627169d5c4e Author: Janek Warchoł lemniskata.bernoull...@gmail.com Date: Sun Jun 29 22:58:45 2014 +0200 Rename argument to avoid preprocessor problems thanks! Janek 2014-07-02 11:12 GMT+02:00 Phil Holmes m...@philholmes.net: Please push this patch, then I can kick GUB off again. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB failing
On 02/07/14 11:51, Janek Warchoł wrote: Pushed to staging as commit 7c6becbfa9deba7e58af8780e3ea2627169d5c4e Author: Janek Warchoł lemniskata.bernoull...@gmail.com Date: Sun Jun 29 22:58:45 2014 +0200 Rename argument to avoid preprocessor problems thanks! Janek 2014-07-02 11:12 GMT+02:00 Phil Holmes m...@philholmes.net: Please push this patch, then I can kick GUB off again. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel It's just been pushed to master James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2245: always align dynamics and lyrics on main notehead (issue 108270044 by janek.lilyp...@gmail.com)
Janek Warchoł wrote: While I think that it's better to always align lyrics to the main notehead, I knew that some people would prefer to do this otherwise, so the patch allows to choose how to align LyricTexts (and DynamicTexts) Okay, this is less problematic than I thought it was, and I'm slowly convincing myself that for LyricText, main-notehead-alignment is better than NoteColumn-alignment. However, for DynamicText, I think NoteColumn-alignment is preferable, especially when the main notehead is on the right of the stem. Gould (p.103) writes: When vertical space is limited, move a dynamic to the left of the note -- never to the right, since the note has already started! \override LyricText.X-align-on-main-noteheads = ##f I think this interface (with booleans) is confusing; I would prefer a choice of symbols, something like this: \override LyricText.X-alignment-anchor = #'NoteHead \override LyricText.X-alignment-anchor = #'NoteColumn git complains about trailing whitespace here. It was already there before, but i'll remove it in the next patchset. I have this in my .vimrc: Remove trailing whitespace on write autocmd BufWritePre * :%s/\s\+$//e - Mark https://codereview.appspot.com/108270044/diff/40001/scm/define-grobs.scm File scm/define-grobs.scm (right): https://codereview.appspot.com/108270044/diff/40001/scm/define-grobs.scm#newcode589 scm/define-grobs.scm:589: (X-offset . ,ly:self-alignment-interface::aligned-on-x-parent) Not a requirement, but you might as well alphabetize the prop-list while you're there (case-insensitive, so 'X-extent comes after 'vertical-skylines). Same for the other prop-lists you modify below. https://codereview.appspot.com/108270044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \magnifyMusic stem-length enigma
On Wed, Jul 2, 2014 at 12:47 AM, David Kastrup d...@gnu.org wrote: If the beam/stems were mirror images of each other, the noteheads in the left group would be closer to the beams than the noteheads in the right group since the noteheads are attached to the right of the stems rather than being centered on them. Wow, I never knew that feature. How refined! It would be an interesting question whether one should actually disregard this in the distance calculations in order to avoid quantization introducing symmetry artifacts like this. Or perhaps do a mixed strategy: make distances that would provide the proper clearance regardless of whether the notehead would be attached to the right or the left of the stem. Of those two ideas, I prefer the second, but now that I understand the functionality, I'm willing to leave this as it is. Thanks for the clarification. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2245: always align dynamics and lyrics on main notehead (issue 108270044 by janek.lilyp...@gmail.com)
Hi, 2014-07-02 20:58 GMT+02:00 markpole...@gmail.com: Janek Warchoł wrote: While I think that it's better to always align lyrics to the main notehead, I knew that some people would prefer to do this otherwise, so the patch allows to choose how to align LyricTexts (and DynamicTexts) Okay, this is less problematic than I thought it was, and I'm slowly convincing myself that for LyricText, main-notehead-alignment is better than NoteColumn-alignment. However, for DynamicText, I think NoteColumn-alignment is preferable, especially when the main notehead is on the right of the stem. Gould (p.103) writes: When vertical space is limited, move a dynamic to the left of the note -- never to the right, since the note has already started! Hm. Sounds reasonable. On the other hand, if you have many staves with dynamics, it's better if these dynamics are aligned - and with alignment on NoteColumns, this would not happen. \override LyricText.X-align-on-main-noteheads = ##f I think this interface (with booleans) is confusing; I would prefer a choice of symbols, something like this: \override LyricText.X-alignment-anchor = #'NoteHead \override LyricText.X-alignment-anchor = #'NoteColumn Yeah, i'm also thinking about providing an interface like this in the future iterations of the alignment rewrite. However, can we push this patch as-is, and make such changes later? The thing is, there will be so many changes in the alignment code that trying to come up with a generic interface now (in the middle of work) is IMO a waste of effort, because i'd continue to rewrite such code with every next patch. I think it will be much more efficient to first get all the features in (using simple solutions), and then look at the resulting code and generalize that - when we'll know what exactly we need. git complains about trailing whitespace here. It was already there before, but i'll remove it in the next patchset. I have this in my .vimrc: Remove trailing whitespace on write autocmd BufWritePre * :%s/\s\+$//e bad luck that i'm not using vim :) https://codereview.appspot.com/108270044/diff/40001/scm/define-grobs.scm File scm/define-grobs.scm (right): https://codereview.appspot.com/108270044/diff/40001/scm/define-grobs.scm#newcode589 scm/define-grobs.scm:589: (X-offset . ,ly:self-alignment-interface::aligned-on-x-parent) Not a requirement, but you might as well alphabetize the prop-list while you're there (case-insensitive, so 'X-extent comes after 'vertical-skylines). Same for the other prop-lists you modify below. Ok, i'll remember this. best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2245: always align dynamics and lyrics on main notehead (issue 108270044 by janek.lilyp...@gmail.com)
PS 2014-07-02 20:58 GMT+02:00 markpole...@gmail.com: Okay, this is less problematic than I thought it was, and I'm slowly convincing myself that for LyricText, main-notehead-alignment is better than NoteColumn-alignment. However, for DynamicText, I think NoteColumn-alignment is preferable, especially when the main notehead is on the right of the stem. The ultimate goal that i have in my mind is to have an interface that will allow to easily say things like align this object on the main column in such cases, on the stem in other cases, and on the whole notecolumn in yet other cases. And in some cases find the average center of the noteheads and align on that.. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Bad example in Documentation since 2.17
Hello, When comparing examples in these pages, http://www.lilypond.org/doc/v2.16/Documentation/notation/unpure_002dpure-containers.html http://www.lilypond.org/doc/v2.17/Documentation/notation/unpure_002dpure-containers.html In the first measure, without the unpure-pure container, the spacing engine does not know the width of the note head and lets it collide with the accidentals. In the second measure, with unpure-pure containers, the spacing engine knows the width of the note heads and avoids the collision by lengthening the line accordingly. , I understand this is no longer true. For some reason, starting from 2.17 both measures look the same. I found this while searching for a way to change the notehead to an arbitrary glyph by its name in Feta font. BTW I have not found the way and http://lsr.dsi.unimi.it/LSR/Search is unsurprisingly down. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bad example in Documentation since 2.17
2014-07-02 21:55 GMT+02:00 Francisco Vila paconet@gmail.com: and http://lsr.dsi.unimi.it/LSR/Search is unsurprisingly down. The address changed. It's now: http://lsr.di.unimi.it/LSR/Search Cheers, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \magnifyMusic stem-length enigma
markpolesky wrote
magnifyMusic =
#(define-music-function (parser location mag mus) (number? ly:music?)
(_i Magnify the notation of @var{mus} without changing the
staff-size, using @var{mag} as a size factor. Stems, beams, and
horizontal spacing are adjusted automatically.)
#{
\set fontSize = #(magnification-font-size mag)
% gives beam-thickness=0.48 when mag=1 (like default),
% gives beam-thickness=0.35 when mag=0.63 (like CueVoice)
\temporary \override Beam.beam-thickness = #(+ 119/925 (* mag 13/37))
\temporary \override Beam.length-fraction = #mag
\temporary \override Stem.length-fraction = #mag
\temporary \override Stem.thickness = #(* 1.3 (max 1 mag))
\temporary \override Score.SpacingSpanner.spacing-increment = #(* 1.2
mag)
#mus
\set fontSize = 0
\revert Beam.beam-thickness
\revert Beam.length-fraction
\revert Stem.length-fraction
\revert Stem.thickness
\revert Score.SpacingSpanner.spacing-increment
#})
Aha! So Beam.length-fraction is how you change the spacing between beams! I
had figured out how to change beam thickness but hadn't had any luck with
spacing, and thought it couldn't be done. Should have known, given
LilyPond's phenomenal flexibility.
I just submitted a snippet to document how it's done in case anyone else
should anyone else need to make these (rarely needed) changes:
http://lsr.di.unimi.it/LSR/Item?u=1id=925
Also, just a quick thought on magnifyMusic. It would be nice to somehow
capture and restore the current fontSize for cases like this:
\new Staff \with {
fontSize = #2
} {
c'4 d' e' f'
\magnifyMusic 0.5 { c'4 d' e' f' }
c'4 d' e' f'
}
But I'm not sure how to do that... If you can access the current fontSize,
maybe it would make sense for the magnification to be relative to it?
Cheers,
-Paul
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/magnifyMusic-stem-length-enigma-tp163878p163911.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
fix Issue 2462. (issue 108280044 by janek.lilyp...@gmail.com)
This does make sense, but if you change the basic rules of a Spring (allowing the natural length to be less than the minimum-distance constraint, so it stays at the minimum length until the line is considerably stretched) you should try to make the change consistently everywhere ? https://codereview.appspot.com/108280044/diff/1/lily/spring.cc File lily/spring.cc (left): https://codereview.appspot.com/108280044/diff/1/lily/spring.cc#oldcode192 lily/spring.cc:192: distance_ = max (distance_, min_distance_); Only caller is Simple_spacer::add_rod() and it certainly seems simpler if adding a min_distance constraint (adding a 'rod') leaves the ideal spacing (the 'spring') unchanged. https://codereview.appspot.com/108280044/diff/1/lily/spring.cc File lily/spring.cc (right): https://codereview.appspot.com/108280044/diff/1/lily/spring.cc#newcode87 lily/spring.cc:87: distance_ = max (min_distance_, distance_ * r); maybe *= r; https://codereview.appspot.com/108280044/diff/1/lily/spring.cc#newcode120 lily/spring.cc:120: avg_distance = max (min_distance + 0.3, avg_distance); Logically, this would be removed as well, except that it also adds 0.3. When you tried removing this line, you said there were unwanted side-effects. What cases needed the extra 0.3 of space? It would be much better to include it in padding parameters, than to have this deeply-hidden offset. https://codereview.appspot.com/108280044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
