Re: Add an expert font tree interface (issue 108700043 by perpeduumimmob...@gmail.com)
https://codereview.appspot.com/108700043/diff/80001/scm/font.scm File scm/font.scm (right): https://codereview.appspot.com/108700043/diff/80001/scm/font.scm#newcode241 scm/font.scm:241: Construct a font tree consisting of the default Feta music font and I think an explanation and clear example is needed at the end of NR 1.8.3 Fonts, instead of here. The average user will never find this. https://codereview.appspot.com/108700043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix some broken commit references. (issue 114430043 by markpole...@gmail.com)
Reviewers: ,
Message:
Hi, in this patchset on Rietveld, instead of displaying the diff, two of
the modified files just say
error: old chunk mismatch
They are
Documentation/contributor.texi
Documentation/web.texi
I rebased and reuploaded, but still got the same error. How do I
correct this?
Thanks,
Mark
Description:
In response to this thread:
http://lists.gnu.org/archive/html/lilypond-devel/2014-07/msg00297.html
Issue 4034 on tracker:
http://code.google.com/p/lilypond/issues/detail?id=4034
There are still three commits with broken references that I couldn't
figure out how to fix:
commit: 76249556809f7a916e9f2bdbe38d7bfc89a2e99d
bad refs: 145a6a5bb7315c0b38e6f7d748d191c113a8f4ae
Documentation/misc/browser-language.de.html
c9c8a55b173151df04eb864643fb740a850e4988
Documentation/misc/browser-language.es.html
15edeaaf2e91dc94cb0e8bc00d954e158936c064
Documentation/misc/browser-language.hu.html
17970a343ba9f8ae809f1b25b3ec603477aaf6d3
Documentation/misc/browser-language.ja.html
1d0752a197850c9bf1d82a468fc130a4eb8df181
Documentation/misc/browser-language.nl.html
_
commit: 8bc025dac3f085731712be31ec36acd5d08c357d
bad refs: 5239637b8f00a0307b860dac05189f297c7c198a
Documentation/zh/web/community.itexi
8052856914abafa960a0518ca8032b681c9d0588
Documentation/zh/macros.itexi
Documentation/zh/web/introduction.itexi
9402161bd6fe04e40ab205054864ebe85c5a4724
Documentation/zh/web/download.itexi
_
commit: 22aae52b7159b1beaf2b094f744773f14ba147ef
bad refs: 91b4009e0ed37deccaec5c45bfdd80ade7d574d6
Documentation/misc/announce-v2.12.de.html
b368624ce125eb38ac5e635a88c0ccf414a3937f
Documentation/misc/announce-v2.12.es.html
df1e2ce4169851a9d841e7becf9924c7421a2d83
Documentation/misc/announce-v2.12.fr.html
Please review this at https://codereview.appspot.com/114430043/
Affected files (+63, -20 lines):
Documentation/contributor.texi
M Documentation/de/texidocs/alternative-bar-numbering.texidoc
M Documentation/de/texidocs/glissandi-can-skip-grobs.texidoc
M Documentation/de/texidocs/strict-beat-beaming.texidoc
M Documentation/essay.tely
M Documentation/extending.tely
M Documentation/learning.tely
M Documentation/music-glossary.tely
M Documentation/notation.tely
M Documentation/usage.tely
Documentation/web.texi
M scm/documentation-generate.scm
Index: Documentation/contributor.texi
diff --git a/Documentation/contributor.texi b/Documentation/contributor.texi
index
f7dc2dd6e817d29ca1403c9fcf8cc145b6cbf2c8..90cd32d444241cb86878e70d5c9377f0a953824b
100644
--- a/Documentation/contributor.texi
+++ b/Documentation/contributor.texi
@@ -23,7 +23,12 @@ should only read the sections which are relevant to
them. For more
information about different jobs, see @rweb{Help us}.
@end macro
-@c `Contributor's Guide' was born 2007-09-15 with git commit 48f3356...
+@c `Contributor's Guide' was born 2007-09-15 with this commit:
+@c Add developers resources page
+@c author: John Mandereau
+@c commit: 135a5beef5c4cf893d02947cdfcb5bb90c854486
+@c file: Documentation/devel.html.in
+
@macro copyrightDeclare
Copyright @copyright{} 2007--2014 by the authors.
@end macro
Index: Documentation/de/texidocs/alternative-bar-numbering.texidoc
diff --git a/Documentation/de/texidocs/alternative-bar-numbering.texidoc
b/Documentation/de/texidocs/alternative-bar-numbering.texidoc
index
b84d88a3d97c61fb0c4eeba968f1f5efc4d72142..bcf5947fcb48bcc61b3083ed6e9e66b587529d6e
100644
--- a/Documentation/de/texidocs/alternative-bar-numbering.texidoc
+++ b/Documentation/de/texidocs/alternative-bar-numbering.texidoc
@@ -1,5 +1,5 @@
-%% Translation of GIT committish: fc1ca638e0b5f66858b9b7a073ceefc1eccb3ed2
+%% Translation of GIT committish: ebe492ca408fb0d9abf80b94c56197eef8dc2f09
texidocde = Zwei alternative Methoden können eingestellt werden,
die die Taktnummerierung beeinflussen, insbesondere bei Wiederholungen.
Index: Documentation/de/texidocs/glissandi-can-skip-grobs.texidoc
diff --git a/Documentation/de/texidocs/glissandi-can-skip-grobs.texidoc
b/Documentation/de/texidocs/glissandi-can-skip-grobs.texidoc
index
640df117ee63c98307529e3027db42634bf2afcc..8799c79097ada33712407751798c1450a2fee8d6
100644
--- a/Documentation/de/texidocs/glissandi-can-skip-grobs.texidoc
+++ b/Documentation/de/texidocs/glissandi-can-skip-grobs.texidoc
@@ -1,4 +1,4 @@
-%% Translation of GIT committish: fc1ca638e0b5f66858b9b7a073ceefc1eccb3ed2
+%% Translation of GIT committish: ebe492ca408fb0d9abf80b94c56197eef8dc2f09
texidocde = @code{NoteColumn}-Grobs können bei Glissandos übersprungen
werden.
doctitlede = Glissando kann Grobs überspringen
Index:
Issue 4039: Improvements to magnifyMusic and magnifyStaff. (issue 115480043 by markpole...@gmail.com)
Reviewers: , Message: Here are some improvements to magnifyMusic and magnifyStaff. Nothing major, but please have a look. Also, I'm still hoping to get a little more discussion on my earlier -devel thread: http://lists.gnu.org/archive/html/lilypond-devel/2014-07/msg00260.html Thanks, Mark Description: Scale tablature half-note double-stems. Scale baseline-skip and word-space props.* Add regtests. *this requires adding text-interface to InstrumentName, which is the subject of Issue 4038. Issue 4039 on tracker: http://code.google.com/p/lilypond/issues/detail?id=4039 Please review this at https://codereview.appspot.com/115480043/ Affected files (+170, -36 lines): A input/regression/magnifyMusic-tablature-double-stems.ly A input/regression/magnifyMusic-text-interface.ly A input/regression/magnifyStaff-tablature-double-stems.ly A input/regression/magnifyStaff-text-interface.ly M ly/music-functions-init.ly M scm/define-grobs.scm M scm/music-functions.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 4024: Clarify break-align symbols and space-alist args in IR. (issue 114160044 by markpole...@gmail.com)
On 2014/07/29 05:35:40, Keith wrote:
https://codereview.appspot.com/114160044/diff/1/scm/define-grob-properties.scm#newcode902
scm/define-grob-properties.scm:902: @code{right-edge}; otherwise it is
fixed.
Looking at the code, 'right-edge' would seem to be among the
otherwise it is
fixed cases. If you found differently by experiment, then experiment
rules.
You are correct. Done.
https://codereview.appspot.com/114160044/diff/1/scm/define-grob-properties.scm#newcode905
scm/define-grob-properties.scm:905: Put at least this much space
between the
left side of both grobs,
left sides
Done.
https://codereview.appspot.com/114160044/diff/1/scm/define-grob-properties.scm#newcode911
scm/define-grob-properties.scm:911: Only use with @code{first-note},
@code{next-note}, and @code{right-edge}.
Only effective communicates more information. Only use makes me
wonder or
else what?
I decided to use only compatible with, since technically some
combinations are effective even though they weren't intended to be
(see below).
https://codereview.appspot.com/114160044/diff/1/scm/define-grob-properties.scm#newcode917
scm/define-grob-properties.scm:917: the note (or edge), without
allowing them to
collide.
Again, I don't see 'right-edge' in the cases that read
minimum-fixed-space, nor
semi-fixed-space.
Ah, I see. Here's the confusion: when paired with right-edge, *all* 5
of the spacing-styles actually do something (to be clear, they all do
the same thing: they behave like extra-space, with space that doesn't
stretch). Anyway, am I correct in concluding that right-edge is only
intended to work with extra-space? I've edited the patch according to
that understanding; please review and comment again if you would.
For some reason Rietveld doesn't show the deltas from the previous patch
set (maybe because I rebased?), so you'll just have to read it again.
The only changes are in lines 891-926 here:
http://codereview.appspot.com/114160044/diff/60001/scm/define-grob-properties.scm#newcode869
Thanks for looking this over,
Mark
https://codereview.appspot.com/114160044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 4024: Clarify break-align symbols and space-alist args in IR. (issue 114160044 by markpole...@gmail.com)
Reviewers: , Message: Since no one reviewed this patch, I'm setting its status back to review. I'll push it next countdown if I all remains quiet. Thanks, Mark Description: Things take so long to understand when they're not documented! Issue 4024 on the tracker: http://code.google.com/p/lilypond/issues/detail?id=4024 Please review this at https://codereview.appspot.com/114160044/ Affected files (+123, -62 lines): M lily/break-alignment-interface.cc M scm/define-grob-properties.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Appendix - Articulations and Ornamentation - part 2 (issue 114840043 by pkx1...@gmail.com)
https://codereview.appspot.com/114840043/diff/80001/Documentation/notation/notation-appendices.itely
File Documentation/notation/notation-appendices.itely (right):
https://codereview.appspot.com/114840043/diff/80001/Documentation/notation/notation-appendices.itely#newcode1513
Documentation/notation/notation-appendices.itely:1513: attached to notes
(eg. @samp{f\accent}). Each example shows the script
(eg. @samp{f\accent} or @samp{f-}).
(see comments below)
https://codereview.appspot.com/114840043/diff/80001/Documentation/notation/notation-appendices.itely#newcode1558
Documentation/notation/notation-appendices.itely:1558: @code{\accent}
It would make sense to also include the shortcuts here too. One of
these should work, I think:
@item
@code{\accent}
@code{-}
@item @code{\accent}
@itemx @code{-}
@item
@code{\accent}@*@code{-}
https://codereview.appspot.com/114840043/diff/80001/Documentation/notation/notation-appendices.itely#newcode1568
Documentation/notation/notation-appendices.itely:1568: @code{\marcato}
@code{-^}
https://codereview.appspot.com/114840043/diff/80001/Documentation/notation/notation-appendices.itely#newcode1573
Documentation/notation/notation-appendices.itely:1573: @code{\portato}
@code{-_}
https://codereview.appspot.com/114840043/diff/80001/Documentation/notation/notation-appendices.itely#newcode1579
Documentation/notation/notation-appendices.itely:1579:
@code{\staccatissimo}
@code{-!}
https://codereview.appspot.com/114840043/diff/80001/Documentation/notation/notation-appendices.itely#newcode1584
Documentation/notation/notation-appendices.itely:1584: @code{\staccato}
@code{-.}
https://codereview.appspot.com/114840043/diff/80001/Documentation/notation/notation-appendices.itely#newcode1589
Documentation/notation/notation-appendices.itely:1589: @code{\tenuto}
@code{--}
https://codereview.appspot.com/114840043/diff/80001/Documentation/notation/notation-appendices.itely#newcode1795
Documentation/notation/notation-appendices.itely:1795: @code{\stopped}
@code{-+}
https://codereview.appspot.com/114840043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add an expert font tree interface (issue 108700043 by perpeduumimmob...@gmail.com)
https://codereview.appspot.com/108700043/diff/80001/input/regression/font-expert-selection.ly
File input/regression/font-expert-selection.ly (right):
https://codereview.appspot.com/108700043/diff/80001/input/regression/font-expert-selection.ly#newcode33
input/regression/font-expert-selection.ly:33: ;; definition,
irregardless of the name given. (Only before the score?
regardless
https://codereview.appspot.com/108700043/diff/80001/input/regression/font-expert-selection.ly#newcode66
input/regression/font-expert-selection.ly:66: #(define fonts
#(define fonts
(make-palladio-dejavu-tree
(/ myStaffSize 20)))
https://codereview.appspot.com/108700043/diff/80001/input/regression/font-expert-selection.ly#newcode77
input/regression/font-expert-selection.ly:77: \markup \huge { \sans xxx
sans xxx xxx serif xxx \typewriter xxx monospace xxx }
\markup \huge {
\sans xxx sans xxx
xxx serif xxx
\typewriter xxx monospace xxx
}
https://codereview.appspot.com/108700043/diff/80001/input/regression/font-expert-selection.ly#newcode81
input/regression/font-expert-selection.ly:81: \new Staff
`\new Staff ' is redundant, just do `\context Voice'
https://codereview.appspot.com/108700043/diff/80001/input/regression/font-expert-selection.ly#newcode90
input/regression/font-expert-selection.ly:90: \override LyricText .
font-family = #'condensed
LyricText.font-family
https://codereview.appspot.com/108700043/diff/80001/scm/font.scm
File scm/font.scm (right):
https://codereview.appspot.com/108700043/diff/80001/scm/font.scm#newcode285
scm/font.scm:285: (let ((n (make-font-tree-node 'font-encoding
'fetaMusic)))
I'd find this formatting easier to read:
(let ((n (make-font-tree-node 'font-encoding 'fetaMusic)))
(add-music-fonts n emmentaler 'feta feta-design-size-mapping
factor)
(for-each
(lambda (L)
(let* ((lily-family (list-ref L 0))
(shape (list-ref L 1))
(series (list-ref L 2))
(scale (if (= (length L) 5)
(list-ref L 4 )
1.0))
(desc (string-append (list-ref L 3)
(number-string (* scale (ly:pt
12))
(add-expert-node n lily-family shape series desc)))
font-spec-list)
n))
https://codereview.appspot.com/108700043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: NR - Pitches.itely - dodecaphonic-no-repeat text alt (issue 116990043 by pkx1...@gmail.com)
https://codereview.appspot.com/116990043/diff/1/Documentation/notation/pitches.itely
File Documentation/notation/pitches.itely (right):
https://codereview.appspot.com/116990043/diff/1/Documentation/notation/pitches.itely#newcode2446
Documentation/notation/pitches.itely:2446: suppressed for pitches
immediately repeated within the same Staff.
I'd either write staff or @code{Staff} context, but not Staff.
https://codereview.appspot.com/116990043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG: Update of Patchy instructions (issue 112280043 by pkx1...@gmail.com)
https://codereview.appspot.com/112280043/diff/40001/Documentation/contributor/administration.itexi
File Documentation/contributor/administration.itexi (right):
https://codereview.appspot.com/112280043/diff/40001/Documentation/contributor/administration.itexi#newcode354
Documentation/contributor/administration.itexi:354: branches (prefrixed
with @code{test-}) with a third branch, called
prefixed
https://codereview.appspot.com/112280043/diff/40001/Documentation/contributor/administration.itexi#newcode712
Documentation/contributor/administration.itexi:712: A previous test
attempt was unsuccesful for some reason and the scripts
unsuccessful
https://codereview.appspot.com/112280043/diff/40001/Documentation/contributor/administration.itexi#newcode783
Documentation/contributor/administration.itexi:783: merge from staging
replace tabs with spaces
https://codereview.appspot.com/112280043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: typo/oversight in align-interface.cc and page-layout-problem.cc (issue 115770043 by thomasmorle...@gmail.com)
https://codereview.appspot.com/115770043/diff/1/lily/page-layout-problem.cc File lily/page-layout-problem.cc (left): https://codereview.appspot.com/115770043/diff/1/lily/page-layout-problem.cc#oldcode38 lily/page-layout-problem.cc:38: Returns the number of footntoes associated with a given line. footntoes? Not handnfingers? https://codereview.appspot.com/115770043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 4015: Add \magnifyStaff. (issue 117830043 by markpole...@gmail.com)
On 2014/07/20 23:48:12, david.nalesnik wrote: https://codereview.appspot.com/117830043/diff/80001/ly/music-functions-init.ly#newcode721 ly/music-functions-init.ly:721: (BarLine kern) Shouldn't this now be segno-kern? Done. Regarding the naming, looks like it's a tie between `resize' and `magnify', with `magnify' slightly ahead if you count Paul's vote as split: scale: Paul resize: Paul, Marc magnify: James, David N. Unless there's more opposition, I'll probably push it as `magnify'; we can always change it later. Thanks, Mark https://codereview.appspot.com/117830043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 4015: Add \magnifyStaff. (issue 117830043 by markpole...@gmail.com)
On 2014/07/17 12:44:20, david.nalesnik wrote: https://codereview.appspot.com/117830043/diff/60001/input/regression/magnifyStaff-bar-lines.ly#newcode30 input/regression/magnifyStaff-bar-lines.ly:30: Are so many examples necessary? No. I've reduced from 5 examples to 3. https://codereview.appspot.com/117830043/diff/60001/input/regression/magnifyStaff-dots-beamlets.ly#newcode1 input/regression/magnifyStaff-dots-beamlets.ly:1: \version 2.19.11 This looks to do what it says (and is very appealing visually), but I notice that the note-spacing becomes more compressed as the magnification increases. Is this OK? Not really. I had disabled the automatic spacing for fear of Issue 3990 http://code.google.com/p/lilypond/issues/detail?id=3990 but it turns out that enabling it here is not as detrimental as it was for \magnifyMusic, so I'll leave it enabled. https://codereview.appspot.com/117830043/diff/60001/input/regression/magnifyStaff-space-alist.ly#newcode2 input/regression/magnifyStaff-space-alist.ly:2: Looks fine. I get a programming error: No spacing entry from KeyCancellation to `custos' Not sure if this is something on my end. That's a separate problem; I don't think it compromises this patch. I'll look into it. https://codereview.appspot.com/117830043/diff/60001/input/regression/magnifyStaff-space-alist.ly#newcode35 input/regression/magnifyStaff-space-alist.ly:35: Impressive display, but should there be so many examples? No. I've reduced from 5 examples to 3. While I have your attention, there was some discussion on the mailing list about changing \magnifyMusic and \magnifyStaff to \resizeMusic and \resizeStaff. Any opinion? Thanks for your comments, Mark https://codereview.appspot.com/117830043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 4015: Add \magnifyStaff. (issue 117830043 by markpole...@gmail.com)
Reviewers: , Message: Here's a new music function called \magnifyStaff (along the lines of \magnifyMusic) that scales staff sizes, staff lines, bar lines, beamlets, and horizontal spacing at the Staff context level. Staff lines are prevented from being scaled smaller than the default (and consequently, so are stems, slurs, etc., since the thickness of each is based on staff lines). This should improve the user experience for this task, which is somewhat cumbersome as it stands. I rewrote the backend to \magnifyMusic so that the two functions could share some code. The bulk of the code is in: ly/music-functions-init.ly scm/music-functions.scm scm/define-context-properties.scm You can see example usages in the modified Documentation files and regtests. This is issue 4015 on the tracker: http://code.google.com/p/lilypond/issues/detail?id=4015 Cheers, Mark Description: * Add \magnifyStaff. * Rewrite parts of the \magnifyMusic function so that it can share some scheme code with the new \magnifyStaff function. * Add regtests. * Update documentation. Please review this at https://codereview.appspot.com/117830043/ Affected files (+329, -95 lines): M Documentation/essay/engraving.itely M Documentation/music-glossary.tely M Documentation/notation/spacing.itely M Documentation/notation/staff.itely A input/regression/magnifyStaff-bar-lines.ly A input/regression/magnifyStaff-dots-beamlets.ly A input/regression/magnifyStaff-space-alist.ly A input/regression/magnifyStaff-staff-line-thickness.ly M ly/music-functions-init.ly M scm/define-context-properties.scm M scm/music-functions.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make tablature half-note stem-spacing adjustable. (issue 110960043 by markpole...@gmail.com)
Reviewers: dak,
Message:
On 2014/07/09 07:02:48, dak wrote:
https://codereview.appspot.com/110960043/diff/1/scm/define-grob-properties.scm
File scm/define-grob-properties.scm (right):
https://codereview.appspot.com/110960043/diff/1/scm/define-grob-properties.scm#newcode243
scm/define-grob-properties.scm:243: stems of a half note in tablature
when using
@code{\tabFullNotation},
@code{\\tabFullNotation}
I always get confused with that. Are there some places where
@code{\foo} is allowed and other places where it is not?
https://codereview.appspot.com/110960043/diff/1/scm/define-grob-properties.scm#newcode245
scm/define-grob-properties.scm:245: of the default @code{Staff}
staff-space
height.)
Why @code{Staff} here? Is this specific to Staff contexts only? That
would mean
that this is not in @code{TabStaff} ?
Hm. How to word this? If 'double-stem-separation were set to 1, the
horizontal distance between the stems would be the same as the vertical
distance between two staff-lines in a *regular* staff (i.e. the default
Staff.StaffSymbol.staff-space = 1). But TabStaff is not a regular
staff, since its staff-lines are further apart (i.e. the default
TabStaff.Symbol.staff-space = 1.5). If you have a better way to convey
this, let me know.
Mark
Description:
This adds a new property to the Stem grob called 'double-stem-separation
(default=0.5), that allows users to adjust the space between the
double-stemmed half-notes in tablature:
\new TabStaff {
\tabFullNotation
c4 c2 c4
\override Stem.double-stem-separation = 0.3
c4 c2 c4
}
It also centers the stems on the fret number and adjusts the X-extent
accordingly.
On the tracker:
http://code.google.com/p/lilypond/issues/detail?id=3999
Please review this at https://codereview.appspot.com/110960043/
Affected files (+16, -2 lines):
M lily/stem.cc
M scm/define-grob-properties.scm
M scm/define-grobs.scm
M scm/tablature.scm
Index: lily/stem.cc
diff --git a/lily/stem.cc b/lily/stem.cc
index
39a77a3858fea8ab3d6a7da92df1f26182830439..cc488e312570ede4a4cc6270ab46b110c0431dee
100644
--- a/lily/stem.cc
+++ b/lily/stem.cc
@@ -1152,6 +1152,7 @@ ADD_INTERFACE (Stem,
default-direction
details
direction
+ double-stem-separation
duration-log
flag
french-beaming
Index: scm/define-grob-properties.scm
diff --git a/scm/define-grob-properties.scm b/scm/define-grob-properties.scm
index
fbb9d679ac50bd06f5eda056093fe3612bfc7772..f5a673a9027816fcabd086ccc5c7c1ae69e04a7c
100644
--- a/scm/define-grob-properties.scm
+++ b/scm/define-grob-properties.scm
@@ -239,6 +239,10 @@ elements closer together.)
(dot-placement-list ,list? List consisting of
@code{(@var{description} @var{string-number} @var{fret-number}
@var{finger-number})} entries used to define fret diagrams.)
+ (double-stem-separation ,number? The distance between the two
+stems of a half note in tablature when using @code{\tabFullNotation},
+not counting the width of the stems themselves, expressed as a multiple
+of the default @code{Staff} staff-space height.)
(duration-log ,integer? The 2-log of the note head duration,
i.e., @code{0} = whole note, @code{1} = half note, etc.)
Index: scm/define-grobs.scm
diff --git a/scm/define-grobs.scm b/scm/define-grobs.scm
index
572f80f660da0c5edf008246b24ed1c0aa66dedc..84e1283028b221a71840525e0c5824b02ea74abd
100644
--- a/scm/define-grobs.scm
+++ b/scm/define-grobs.scm
@@ -2114,6 +2114,7 @@
;; and the extreme minima as abolute minimum length.
(direction . ,ly:stem::calc-direction)
+(double-stem-separation . 0.5)
(duration-log . ,stem::calc-duration-log)
(length . ,(ly:make-unpure-pure-container ly:stem::calc-length
ly:stem::pure-calc-length))
(neutral-direction . ,DOWN)
Index: scm/tablature.scm
diff --git a/scm/tablature.scm b/scm/tablature.scm
index
36b81106c1bcb0046b9f2a73f5b7f1aab842bacf..bb30664083460e223c2d124b32245c4f972ff9ef
100644
--- a/scm/tablature.scm
+++ b/scm/tablature.scm
@@ -85,7 +85,11 @@
;; is the note a (dotted) half note?
(if (= 1 (ly:grob-property grob 'duration-log))
;; yes - return double stem width
-(cons (car X-extent) (+ 0.5 (* 2 (cdr X-extent
+(let* ((single-stem-width (- (cdr X-extent) (car X-extent)))
+ (separation (ly:grob-property grob 'double-stem-separation))
+ (double-stem-width (+ single-stem-width separation))
+ (half-width (/ double-stem-width 2)))
+ (cons (- half-width) half-width))
;; no - return simple stem width
X-extent)))
@@ -95,7 +99,11 @@
;; is the note a (dotted) half note?
(if (= 1 (ly:grob-property grob 'duration-log))
;; yes - draw double stem
-(ly:stencil-combine-at-edge stem X RIGHT stem 0.5)
+(let* ((separation (ly:grob-property grob
Re: Issue 3997: \magnifyMusic: don't modify nested properties; reformat code. (issue 110840044 by markpole...@gmail.com)
On 2014/07/09 00:16:50, Mark Polesky wrote: Good idea, Harm. I started a new issue to take care of that: http://code.google.com/p/lilypond/issues/detail?id=3999 http://codereview.appspot.com/101690043/ Oops, wrong links. Tracker: http://code.google.com/p/lilypond/issues/detail?id=3999 Rietveld: http://codereview.appspot.com/110960043/ Although, come on... What were the chances that two of my current Rietveld patches would have the exact same numbers in different orders? http://codereview.appspot.com/101690043/ http://codereview.appspot.com/110960043/ https://codereview.appspot.com/110840044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 4002: Mention backslash escaping in Scheme. (issue 112040043 by markpole...@gmail.com)
Reviewers: dak,
Message:
On 2014/07/09 23:46:36, dak wrote:
https://codereview.appspot.com/112040043/diff/1/Documentation/contributor/doc-work.itexi#newcode950
Documentation/contributor/doc-work.itexi:950:
@samp{The@tie{}@@code@{@bs{}foo@}@tie{}command}). However, if a
Why write @bs{} instead of \ here?
Because we're in a @warning block.
https://codereview.appspot.com/112040043/diff/1/Documentation/contributor/doc-work.itexi#newcode951
Documentation/contributor/doc-work.itexi:951: Texinfo string is within
a block
of Scheme code, it must be
That's incorrect. Correct would be:
However, within double-quoted Scheme and/or LilyPond strings,
backslashes
(including those ending up in Texinfo markup) need to be escaped by
doubling
them.
There is no such thing as a Texinfo string, and it is not contained
in Scheme
code but rather in strings.
Okay
https://codereview.appspot.com/112040043/diff/1/Documentation/contributor/doc-work.itexi#newcode955
Documentation/contributor/doc-work.itexi:955: The
@@code@{@bs{}@bs{}foo@}
command...
That's awfully unreadable source code. I'd be tempted to use
@verbatim instead
in order to avoid all the Texinfo escapes. Also there is no point in
writing
@bs{}@bs{} instead of \\ here.
Again, I think the @bs{} is needed in a @warning block, but I'll try
verbatim.
Thanks,
Mark
Description:
Clarify confusion about `@code{\foo}' vs. `@code{\\foo}'.
Issue on tracker:
http://code.google.com/p/lilypond/issues/detail?id=4002
Please review this at https://codereview.appspot.com/112040043/
Affected files (+12, -0 lines):
M Documentation/contributor/doc-work.itexi
Index: Documentation/contributor/doc-work.itexi
diff --git a/Documentation/contributor/doc-work.itexi
b/Documentation/contributor/doc-work.itexi
index
7bf37c72e96d60cf0f20666306548f76435fbbdf..be55aa42955e51b57f4360253b7f11603d769f09
100644
--- a/Documentation/contributor/doc-work.itexi
+++ b/Documentation/contributor/doc-work.itexi
@@ -945,6 +945,18 @@ the same format as @code{@@enumerate}. Do not use
@node Special characters
@unnumberedsubsubsec Special characters
+@warning{In Texinfo, the backslash is an ordinary character, and
+is entered without escaping (e.g.
+@samp{The@tie{}@@code@{@bs{}foo@}@tie{}command}). However, if a
+Texinfo string is within a block of Scheme code, it must be
+escaped:
+@example
+(define (foo x)
+ The @@code@{@bs{}@bs{}foo@} command...
+ ...)
+@end example
+}
+
@itemize
@item
@code{--}, @code{---} --- Create an en dash (--) or an em dash
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 4002: Mention backslash escaping in Scheme. (issue 112040043 by markpole...@gmail.com)
On 2014/07/09 23:55:49, Mark Polesky wrote:
On 2014/07/09 23:46:36, dak wrote:
https://codereview.appspot.com/112040043/diff/1/Documentation/contributor/doc-work.itexi#newcode955
Documentation/contributor/doc-work.itexi:955: The
@@code@{@bs{}@bs{}foo@}
command...
That's awfully unreadable source code. I'd be tempted to
use @verbatim instead in order to avoid all the Texinfo
escapes. Also there is no point in writing @bs{}@bs{}
instead of \\ here.
No other combination of solutions worked. @warning disallows
backslashes and @verbatim blocks. Personally, I don't really mind about
the unreadable source code, as long as it's clear in the CG. Thanks for
the clarified text.
https://codereview.appspot.com/112040043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make tablature half-note stem-spacing adjustable. (issue 110960043 by markpole...@gmail.com)
On 2014/07/09 07:13:04, Mark Polesky wrote: ...But TabStaff is not a regular staff, since its staff-lines are further apart (i.e. the default TabStaff.Symbol.staff-space = 1.5). Pardon the typo; I meant TabStaff.StaffSymbol.staff-space of course. https://codereview.appspot.com/110960043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove thin-kern property. (issue 105560044 by markpole...@gmail.com)
marc wrote: OK, but 'thin-kern does not seem to be an appropriate name for this property anymore IMHO. How about 'segno-kern? (patch updated accordingly) https://codereview.appspot.com/105560044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 3997: \magnifyMusic: don't modify nested properties; reformat code. (issue 110840044 by markpole...@gmail.com)
Reviewers: ,
Message:
continued from http://codereview.appspot.com/103890046/#msg11
On 2014/07/07 18:22:09, dak wrote:
https://codereview.appspot.com/103890046/diff/250001/ly/music-functions-init.ly#newcode718
ly/music-functions-init.ly:718: \context Voice {
This would create a new Staff when using
\new TabStaff { \magnifyMusic ...
It would seem safer to use \context Bottom instead.
Wow, I didn't even know there was a context called Bottom. Anyway, this
raises a new question: How do I tweak the distance between the
half-note's two stems in tablature?
\new TabStaff {
\tabFullNotation
c2
}
Thanks,
Mark
Description:
In response to David's objections here:
http://codereview.appspot.com/103890046/#msg9
See http://code.google.com/p/lilypond/issues/detail?id=3997
Please review this at https://codereview.appspot.com/110840044/
Affected files (+42, -116 lines):
M ly/music-functions-init.ly
M scm/music-functions.scm
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Remove thin-kern property. (issue 105560044 by markpole...@gmail.com)
Reviewers: ,
Message:
Hi, I'm proposing to get rid of the BarLine.thin-kern property with this
patch, so if you're opposed, let me know.
You can see my comments/rationale here:
http://code.google.com/p/lilypond/issues/detail?id=3995
Thanks,
Mark
Description:
This removes the thin-kern property, and adds a convert-ly rule to
convert `thin-kern' to `kern', since kern does what thin-kern claimed to
do anyway, and thin-kern (AFAICT) does nothing.
See http://code.google.com/p/lilypond/issues/detail?id=3995
Please review this at https://codereview.appspot.com/105560044/
Affected files (+11, -9 lines):
M python/convertrules.py
M scm/bar-line.scm
M scm/define-grob-interfaces.scm
M scm/define-grob-properties.scm
M scm/define-grobs.scm
Index: python/convertrules.py
diff --git a/python/convertrules.py b/python/convertrules.py
index
5eb2a75bfc4f17bbcea91068518c2e928b502d99..aeb9384a5529423e8e7f279e8ce41183993d7769
100644
--- a/python/convertrules.py
+++ b/python/convertrules.py
@@ -3450,7 +3450,7 @@ def conv (str):
if m.group (1):
return m.group (0)
x = m.group (2) + m.group (4)
-
+
if m.group (3):
x = x + re.sub (r(\s*)( + symbol_list + ), fn_path_replace,
m.group (3))
@@ -3718,6 +3718,11 @@ def conv(str):
str = re.sub (r'\blocalKeySignature\b', 'localAlterations', str)
return str
+@rule ((2, 19, 10), thin-kern - kern)
+def conv(str):
+str = re.sub (r'\bthin-kern\b', 'kern', str)
+return str
+
# Guidelines to write rules (please keep this at the end of this file)
#
# - keep at most one rule per version; if several conversions should be
done,
Index: scm/bar-line.scm
diff --git a/scm/bar-line.scm b/scm/bar-line.scm
index
ff2d3f29b4a35d30cee581fa8f31ac096b06acb5..77c41f5cc04973c85c092e03ad6d96a98618b2ef
100644
--- a/scm/bar-line.scm
+++ b/scm/bar-line.scm
@@ -440,14 +440,14 @@ is not used within the routine.
the segno sign is drawn over the double bar line; otherwise, it
draws the span bar variant, i.e. without the segno sign.
(let* ((line-thickness (layout-line-thickness grob))
- (thinkern (* (ly:grob-property grob 'thin-kern 1) line-thickness))
+ (kern (* (ly:grob-property grob 'kern 1) line-thickness))
(thin-stil (make-simple-bar-line grob extent))
(double-line-stil (ly:stencil-combine-at-edge
thin-stil
X
LEFT
thin-stil
-thinkern))
+kern))
(segno (ly:font-get-glyph (ly:grob-default-font grob)
scripts.varsegno))
(stencil (ly:stencil-add
@@ -459,7 +459,7 @@ draws the span bar variant, i.e. without the segno
sign.
(cons 0 0)))
(ly:stencil-translate-axis
double-line-stil
-(* 1/2 thinkern)
+(* 1/2 kern)
X
stencil))
Index: scm/define-grob-interfaces.scm
diff --git a/scm/define-grob-interfaces.scm b/scm/define-grob-interfaces.scm
index
4ffd761607c788feef67edba4b1b1e5522bf78fb..7e5fa2283f29678d788ba9cc7d92eb2ea7d4536a
100644
--- a/scm/define-grob-interfaces.scm
+++ b/scm/define-grob-interfaces.scm
@@ -59,7 +59,6 @@ found in @file{scm/bar-line.scm}.
has-span-bar
kern
rounded
- thin-kern
thick-thickness))
(ly:add-interface
Index: scm/define-grob-properties.scm
diff --git a/scm/define-grob-properties.scm b/scm/define-grob-properties.scm
index
24e8e3298abeb0d93607832d0d1422b757e83c8d..be82bd1c0c3061777bbb8e4f37457d09d9267231
100644
--- a/scm/define-grob-properties.scm
+++ b/scm/define-grob-properties.scm
@@ -531,8 +531,8 @@ slur quants to this position, and print the respective
scores.)
;;;
(keep-inside-line ,boolean? If set, this column cannot have
objects sticking into the margin.)
- (kern ,ly:dimension? Amount of extra white space to add. For
-bar lines, this is the amount of space after a thick line.)
+ (kern ,ly:dimension? The space between bar lines in any type
+of double bar)
(knee ,boolean? Is this beam kneed?)
(knee-spacing-correction ,number? Factor for the optical
correction amount for kneed beams. Set between @code{0} for no
@@ -969,7 +969,6 @@ should use @code{LEFT}.)
@code{line-thickness}.)
(thickness ,number? Line thickness, generally measured in
@code{line-thickness}.)
- (thin-kern ,number? The space after a hair-line in a bar line.)
(tie-configuration ,list? List of @code{(@var{position} .
@var{dir})} pairs, indicating the desired tie configuration, where
@var{position} is the offset from the center of the staff in staff
Index: scm/define-grobs.scm
diff --git a/scm/define-grobs.scm b/scm/define-grobs.scm
index
ddacbcb7ec1131864197462b77ef59f7dca37b4b..c6dbd325d862ab42bc1efe35a610410dfdcb950f
Re: Remove thin-kern property. (issue 105560044 by markpole...@gmail.com)
On 2014/07/06 11:52:56, thomasmorley651 wrote: I disagree! 'kern and 'thin-kern _are_ used differently. Look at the output from: Harm, what am I missing? To my eye (compiling this with the latest snapshot), your example shows that thin-kern does nothing. - Mark https://codereview.appspot.com/105560044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove thin-kern property. (issue 105560044 by markpole...@gmail.com)
On 2014/07/06 11:52:56, thomasmorley651 wrote: I disagree! 'kern and 'thin-kern _are_ used differently. Okay, so then it's just a question of clarifying the misleading docstrings. How about this? kern The space between individual elements in any compound bar line. thin-kern The space between the two thin lines of the segno bar line symbol. I've updated the patch accordingly. https://codereview.appspot.com/105560044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3942: Scale slurs and ties when using \magnifyMusic. (issue 103890046)
On 2014/07/06 14:04:07, dak wrote: ly/music-functions-init.ly:645: Stem.thickness This is madness. Stem.thickness and its ilk don't make sense as symbols at all Okay ly/music-functions-init.ly:679: Slur.details.region-size I doubt you even have a chance of making this work. Overriding and reverting bulks of *nested* properties does not work reliably. Okay Since this patch has already been pushed, I'm moving the discussion to the new patch here: http://codereview.appspot.com/110840044 https://codereview.appspot.com/103890046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: notation-appendices.itely - added 2 Clefs (issue 104520043 by pkx1...@gmail.com)
On 2014/07/05 05:28:36, J_lowe wrote:
Okay, but \clef tab needs \new TabStaff as well
Well I've never used Tab notation before and lilypond will let you
compile
\clef tab c1
It will let you compile, but the visual output is still wrong.
So if you *always* use a \new TabStaff for \clef tab then fine, I can
just write
@code{\clef moderntab} and be done.
I'm sorry if I confused you. Your original idea of showing the \new
TabStaff in a code{} block is preferable, but you *need* to use \new
TabStaff for both tab and moderntab. Just doing \clef tab c1
(without the \new TabStaff) results in the wrong output, as I
described in comment #3. Plus you still have the excess curly braces in
the moderntab lilypond block. I think your best bet is to cut and paste
the code I provided between the asterisks in comment #3, for the last
two items.
- Mark
https://codereview.appspot.com/104520043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3991: \magnifyMusic - reluctantly surrender to issues 3987 and 3990. (issue 101690043 by markpole...@gmail.com)
Reviewers: J_lowe, pwm, Message: On 2014/07/05 14:17:23, pwm wrote: Happened to see another little simplification. ... Can be simplified: (lambda (x) x) is the same as x Not in this case; guile would complain about unbound variable x. I could have used the guile function `identity', but I opted not to since it's not documented in the guile manual. I'll rewrite it though, so that the `if' clause is inside the `lambda'. But I'll do that in the Issue 3942 patch set (http://codereview.appspot.com/103890046/). Thanks Description: http://code.google.com/p/lilypond/issues/detail?id=3991 Until issues 3987 and 3990 are fixed, \magnifyMusic is broken, so I'm turning off some of the intended functionality, and putting a note in the docs. This patch is based on another patch which hasn't been pushed yet: http://codereview.appspot.com/103890046/ That's Patch Set 1. You can click on the Delta from patch set to see what I've done. Please review this at https://codereview.appspot.com/101690043/ Affected files (+252, -19 lines): M Documentation/changes.tely M Documentation/notation/editorial.itely M ly/music-functions-init.ly M scm/music-functions.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes.tely updated - 2.19.x up to June 2014 (issue 108130043 by pkx1...@gmail.com)
https://codereview.appspot.com/108130043/diff/90001/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/108130043/diff/90001/Documentation/changes.tely#newcode68
Documentation/changes.tely:68: Add support for @code{\once}@code{\unset}
@code{\once@tie{}\unset}
https://codereview.appspot.com/108130043/diff/90001/Documentation/changes.tely#newcode71
Documentation/changes.tely:71: It is now possible to individually color
both the dots and parenthesis
parentheses
https://codereview.appspot.com/108130043/diff/90001/Documentation/changes.tely#newcode111
Documentation/changes.tely:111: space between the dot and the
parenthesis surrounding it.
parentheses
https://codereview.appspot.com/108130043/diff/90001/Documentation/changes.tely#newcode151
Documentation/changes.tely:151: \fill-line {O oOooo ooOoo oooOo
O}
I prefer this:
\fill-line \underline {↓ ↓ ↓ ↓ ↓}
https://codereview.appspot.com/108130043/diff/90001/Documentation/changes.tely#newcode156
Documentation/changes.tely:156: \justify-line {O O O O
O}
I prefer this:
\justify-line \underline {↓ ↓ ↓ ↓ ↓}
https://codereview.appspot.com/108130043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Updated Roadmap text file (issue 106160043 by pkx1...@gmail.com)
https://codereview.appspot.com/106160043/diff/20001/ROADMAP File ROADMAP (right): https://codereview.appspot.com/106160043/diff/20001/ROADMAP#newcode21 ROADMAP:21: | | Note: Snippets and Internals Reference are auto-generated | | Note: Snippets and Internals Reference are | | auto-generated during the Documentation build process. Wow, I'm fussy. Feel free to ignore me. :) https://codereview.appspot.com/106160043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: notation-appendices.itely - added 2 Clefs (issue 104520043 by pkx1...@gmail.com)
https://codereview.appspot.com/104520043/diff/1/Documentation/notation/notation-appendices.itely
File Documentation/notation/notation-appendices.itely (right):
https://codereview.appspot.com/104520043/diff/1/Documentation/notation/notation-appendices.itely#newcode1489
Documentation/notation/notation-appendices.itely:1489: @tab
For the last two entries, this makes better sense to me:
@tab
@code{\clef tab}
@tab
@lilypond[line-width=3\cm,notime,ragged-right,relative=1]
\new TabStaff {
\clef tab
c1
}
@end lilypond
@item
@code{\clef moderntab}
@tab
@lilypond[line-width=3\cm,notime,ragged-right,relative=1]
\new TabStaff {
\clef moderntab
c1
}
@end lilypond
https://codereview.appspot.com/104520043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: NR - 1.2.5 - Bar Numbers - added snippet (issue 106320046 by pkx1...@gmail.com)
https://codereview.appspot.com/106320046/diff/1/Documentation/snippets/new/printing-bar-numbers-with-changing-regular-intervals.ly File Documentation/snippets/new/printing-bar-numbers-with-changing-regular-intervals.ly (right): https://codereview.appspot.com/106320046/diff/1/Documentation/snippets/new/printing-bar-numbers-with-changing-regular-intervals.ly#newcode16 Documentation/snippets/new/printing-bar-numbers-with-changing-regular-intervals.ly:16: \override Score.BarNumber #'break-visibility = #end-of-line-invisible CG 5.4.4 says to indent ly code with two spaces. https://codereview.appspot.com/106320046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3958: Give examples of \applyContext usage. (issue 110060045 by markpole...@gmail.com)
Reviewers: janek, Keith, dak, Message: I've rewritten the \applyContext description, and this new patch is about 40% shorter than the previous one. Please review. Thanks, Mark Description: The documentation on \applyContext is pretty slim. I'm just mentioning some new tricks I recently learned, in the hopes that it will benefit future users/developers. http://code.google.com/p/lilypond/issues/detail?id=3958 Please review this at https://codereview.appspot.com/110060045/ Affected files (+120, -9 lines): M Documentation/extending/programming-interface.itely ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: notation-appendices.itely - added 2 Clefs (issue 104520043 by pkx1...@gmail.com)
On 2014/07/04 10:29:15, J_lowe wrote:
The problem is (else I would have done what you suggested) is that one
cannot
just use
\clef moderntab { c1 } and it will print like \clef tab { c1 }, so I
was trying
to show that to get that specific clef you must (so it seems) use the
\new
TabStaff { .. } construct.
Okay, but \clef tab needs \new TabStaff as well (right now it's
showing 5 lines and a whole note, instead of 6 lines and a fret number).
So then the last two items look like this:
***
@tab
@c @example does not work as expected within multitables
@code{
\new TabStaff @{ @*
@ @ \clef tab @*
@}
}
@tab
@lilypond[line-width=3\cm,notime,ragged-right,relative=1]
\new TabStaff {
\clef tab
c1
}
@end lilypond
@item
@c @example does not work as expected within multitables
@code{
\new TabStaff @{ @*
@ @ \clef moderntab @*
@}
}
@tab
@lilypond[line-width=3\cm,notime,ragged-right,relative=1]
\new TabStaff {
\clef moderntab
c1
}
@end lilypond
***
By the way, in the other items, you could remove all those excess
brackets:
@lilypond[line-width=3\cm,notime,ragged-right,relative=1]
\clef G
c1
@end lilypond
https://codereview.appspot.com/104520043/
___
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)
On 2014/07/04 20:47:24, janek wrote: Hi Mark, do you have any objections against putting this patch on countdown? No objections, but I'll leave it to someone else to give the green light since I'm not qualified to evaluate the C++ code. As i wrote, this is a transitional phase: the patch improves the situation, but i intend to make more changes when it becomes clear how they should look like. Sounds good. https://codereview.appspot.com/108270044/ ___ 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: Re: Issue 2245: always align dynamics and lyrics on main notehead (issue 108270044 by janek.lilyp...@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. No idea how easy or hard
that would be to code, but that's what I would vote for. The
corrected example given in comment #1 here looks too far to the right
to me, and so do the dynamics in the following comment:
http://code.google.com/p/lilypond/issues/detail?id=2245
- Mark
https://codereview.appspot.com/108270044/diff/40001/input/regression/text-spanner-attachment-alignment.ly
File input/regression/text-spanner-attachment-alignment.ly (right):
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.
https://codereview.appspot.com/108270044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Re: Issue 3942: Scale slurs and ties when using \magnifyMusic. (issue 103890046 by markpole...@gmail.com)
This new patch went through a countdown cycle without any reviews. I'm putting it through another cycle in case anyone would like to make comments before I push it. Thanks. - Mark https://codereview.appspot.com/103890046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: Updated Roadmap text file (issue 106160043 by pkx1...@gmail.com)
Apart from my overly fussy nitpicks, LGTM. https://codereview.appspot.com/106160043/diff/1/ROADMAP File ROADMAP (right): https://codereview.appspot.com/106160043/diff/1/ROADMAP#newcode21 ROADMAP:21: | | Note: The Snippets and Internals manual are auto-generated I might say: Note: Snippets and Internals Reference are auto-generated or at least change manual to manuals. Also, maybe indent 2 spaces, similar to the note under TRANSLATED MANUALS. https://codereview.appspot.com/106160043/diff/1/ROADMAP#newcode30 ROADMAP:30: | |-- usage/ How to execute all the programs distributed with LilyPond If you change programs distributed with to programs that come with (or just remove the all), then the file won't exceed 80 columns, if we still care about that... https://codereview.appspot.com/106160043/diff/1/ROADMAP#newcode63 ROADMAP:63: | |-- snippets/Auto-generated .ly snippets (from the LSR and ../new/.) Technically it should be ./new/ instead of ../new/. I'd also omit the final period (before the parenthesis) since we don't use it elsewhere in the file. https://codereview.appspot.com/106160043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3942: Scale slurs and ties when using \magnifyMusic. (issue 103890046 by markpole...@gmail.com)
On 2014/06/15 05:25:27, dak wrote: It would have helped if I had written the correct command to use. It is, of course, \applyContext. The documentation does not help much, but one illustrative read/modify/write use is in scm/music-functions.scm in add-grace-property and remove-grace-property. Well, I finally understand this much more than before (thank you David), but I still need someone to check my work here. I've completely overhauled the \magnifyMusic function, so now if the user has overridden any default values, those adjustments will still be respected as the size increases or decreases. I tried to code as clearly and concisely as possible, but it ended up longer than I imagined. I'm wondering if I should be defining some of the longer scheme chunks in some other file, to make the magnifyMusic definition easier to read? Also, my (scale-prop) procedure isn't the most generic thing around, though I think it fits the bill for what it is. Looking forward to getting some feedback. - Mark https://codereview.appspot.com/103890046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3951: Fix broken LSR links in docs. (issue 102410043 by markpole...@gmail.com)
Now that this patch is in the git repo, I decided to import the LSR to Git, following the instructions in CG 7.4: http://lilypond.org/doc/v2.19/Documentation/contributor/lsr-to-git However, on the last step (manually checking for unsafe files), it became abundantly clear that I am *not* the person for that task, and I wouldn't want to be responsible for some sort of catastrophic security breach, not to mention the fact that the resulting diff was 5571 lines long. At that length, it seems preferable to redirect the output to a file: xargs git diff HEAD lsr-unsafe.txt tmp So... if anyone else wants to take that on, don't let me stop you. :) - Mark https://codereview.appspot.com/102410043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3951: Fix broken LSR links in docs. (issue 102410043 by markpole...@gmail.com)
On 2014/06/14 10:03:46, mail_philholmes.net wrote: I would suggest correcting the links in the Documentation, but not the snippets themselves. The links in the snippets are not really visible (commented out) and, as James says, are over-written with an LSR import. Fair enough. I reverted the edits within the snippets directory, then ran makelsr.py, which affected only one file: Documentation/snippets/defining-an-engraver-in-scheme--ambitus-engraver.ly All better? Thanks. - Mark https://codereview.appspot.com/102410043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3942: Scale slurs and ties when using \magnifyMusic. (issue 103890046 by markpole...@gmail.com)
On 2014/06/14 06:58:52, dak wrote: On 2014/06/06 09:29:03, Mark Polesky wrote: ... Ideally, if the user has already modified some of those values, I'd like to base the new scaled values on the user's choices, and not base them on the LilyPond default values. If that's possible at all, I don't know how to do that. If you do a read-modify-write on properties, you have to use \applyMusic for that. David, I'm sorry to say that I'm unable to figure this out on my own. \applyMusic is completely undocumented and the few occurrences in the source code are not illustrative enough for me. Within an \applyMusic construct, how do I access a given grob-property value, and then override it -- temporarily? Thanks. - Mark https://codereview.appspot.com/103890046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3942: Scale slurs and ties when using \magnifyMusic. (issue 103890046)
On 2014/06/06 09:29:03, Mark Polesky wrote: Please review this new patch. I'm not entirely sure this is the right approach, so I may need some advice here. This patch has gone through the review/countdown process without a single comment or review, but I'm not comfortable pushing it without any feedback. In the definition of \magnifyMusic (in music-functions-init.ly), I've used about 50 temporary overrides, manually entering scaled values based on the normal default values for each grob-property I'm overriding. Ideally, if the user has already modified some of those values, I'd like to base the new scaled values on the user's choices, and not base them on the LilyPond default values. If that's possible at all, I don't know how to do that. Also, if anyone has any suggestions for a more elegant approach, please let me know. Thanks. - Mark https://codereview.appspot.com/103890046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 3951: Fix broken LSR links in docs. (issue 102410043 by markpole...@gmail.com)
Reviewers: , Message: I'm seeing some confusion on -user due to the broken LSR links. Here's an (unavoidably large) patch to fix the links. - Mark Description: Issue 3951: Fix broken LSR links in docs. Not sure why, but the URL for the LSR seems to have changed from: lsr.dsi.unimi.it to lsr.di.unimi.it This is a large patch because it affects something like 300 files. Here's the command I used: for i in $(git grep -l 'lsr\(@/\)*.dsi\(@/\)*.unimi\(@/\)*.it'); do sed -i 's!lsr\(@/\)*.dsi\(@/\)*.unimi\(@/\)*.it!lsr\1.di\2.unimi\3.it!' $i; done This accommodates both of the following cases: lsr.dsi.unimi.it - lsr.di.unimi.it lsr@/.dsi@/.unimi@/.it - lsr@/.di@/.unimi@/.it http://code.google.com/p/lilypond/issues/detail?id=3951 Please review this at https://codereview.appspot.com/102410043/ Affected files (+326, -326 lines): M Documentation/contributor/lsr-work.itexi M Documentation/cs/web/community.itexi M Documentation/cs/web/manuals.itexi M Documentation/de/notation/keyboards.itely M Documentation/de/web/community.itexi M Documentation/de/web/manuals.itexi M Documentation/es/notation/keyboards.itely M Documentation/es/web/community.itexi M Documentation/es/web/manuals.itexi M Documentation/es/web/news.itexi M Documentation/fr/web/community.itexi M Documentation/fr/web/manuals.itexi M Documentation/hu/web/manuals.itexi M Documentation/it/web/community.itexi M Documentation/it/web/manuals.itexi M Documentation/ja/notation/keyboards.itely M Documentation/ja/web/community.itexi M Documentation/ja/web/manuals.itexi M Documentation/nl/web/manuals.itexi M Documentation/notation/keyboards.itely M Documentation/snippets.tely M Documentation/snippets/README M Documentation/snippets/adding-ambitus-per-voice.ly M Documentation/snippets/adding-an-extra-staff.ly M Documentation/snippets/adding-an-extra-staff-at-a-line-break.ly M Documentation/snippets/adding-an-ottava-marking-to-a-single-voice.ly M Documentation/snippets/adding-bar-lines-to-chordnames-context.ly M Documentation/snippets/adding-beams,-slurs,-ties-etc.-when-using-tuplet-and-non-tuplet-rhythms.ly M Documentation/snippets/adding-drum-parts.ly M Documentation/snippets/adding-fingerings-to-a-score.ly M Documentation/snippets/adding-fingerings-to-tablatures.ly M Documentation/snippets/adding-indicators-to-staves-which-get-split-after-a-break.ly M Documentation/snippets/adding-links-to-objects.ly M Documentation/snippets/adding-parentheses-around-an-expressive-mark-or-chordal-note.ly M Documentation/snippets/adding-the-current-date-to-a-score.ly M Documentation/snippets/adding-volta-brackets-to-additional-staves.ly M Documentation/snippets/additional-voices-to-avoid-collisions.ly M Documentation/snippets/adjusting-grace-note-spacing.ly M Documentation/snippets/adjusting-lyrics-vertical-spacing.ly M Documentation/snippets/adjusting-the-shape-of-falls-and-doits.ly M Documentation/snippets/aligning-and-centering-instrument-names.ly M Documentation/snippets/aligning-bar-numbers.ly M Documentation/snippets/aligning-objects-created-with-the--mark-command.ly M Documentation/snippets/aligning-syllables-with-melisma.ly M Documentation/snippets/allowing-fingerings-to-be-printed-inside-the-staff.ly M Documentation/snippets/altering-the-length-of-beamed-stems.ly M Documentation/snippets/alternative-breve-notes.ly M Documentation/snippets/ambitus.ly M Documentation/snippets/ambitus-with-multiple-voices.ly M Documentation/snippets/analysis-brackets-above-the-staff.ly M Documentation/snippets/ancient-headword.ly M Documentation/snippets/ancient-notation-templatemodern-transcription-of-mensural-music.ly M Documentation/snippets/ancient-time-signatures.ly M Documentation/snippets/anglican-psalm-template.ly M Documentation/snippets/applying-note-head-styles-depending-on-the-step-of-the-scale.ly M Documentation/snippets/arabic-improvisation.ly M Documentation/snippets/asymmetric-slurs.ly M Documentation/snippets/automatic-beam-subdivisions.ly M Documentation/snippets/automatically-change-durations.ly M Documentation/snippets/automatically-changing-the-stem-direction-of-the-middle-note-based-on-the-melody.ly M Documentation/snippets/avoiding-collisions-with-chord-fingerings.ly M Documentation/snippets/beam-endings-in-score-context.ly M Documentation/snippets/beam-grouping-in-7-8-time.ly M Documentation/snippets/beams-across-line-breaks.ly M Documentation/snippets/blanking-staff-lines-using-the--whiteout-command.ly M Documentation/snippets/book-parts.ly M Documentation/snippets/breathing-signs.ly M Documentation/snippets/caesura-railtracks-with-fermata.ly M Documentation/snippets/center-text-below-hairpin-dynamics.ly M Documentation/snippets/changing--flageolet-mark-size.ly M Documentation/snippets/changing-a-single-notes-size-in-a-chord.ly M
Issue 3942: Scale slurs and ties when using \magnifyMusic. (issue 103890046)
Reviewers: , Message: Please review this new patch. I'm not entirely sure this is the right approach, so I may need some advice here. Thank you! - Mark Description: This is a (possibly misguided) attempt to get slurs and ties to scale properly when using \magnifyMusic. For the most part, I've just copied the appropriate grob-properties from Slur, PhrasingSlur, and Tie, and scaled them to the magnification value. The results are, well, mixed. I posted some images here: http://code.google.com/p/lilypond/issues/detail?id=3942 Also, I feel that there *must* be a more elegant way of doing this, but I can't figure it out. Any help is appreciated. Please review this at https://codereview.appspot.com/103890046/ Affected files (+188, -6 lines): A input/regression/magnifyMusic-phrasing-slurs.ly A input/regression/magnifyMusic-slurs.ly M input/regression/magnifyMusic-stem-beam-spacing.ly A input/regression/magnifyMusic-ties.ly M ly/music-functions-init.ly ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3926: Add \magnifyMusic; clarify fontSize in docs. (issue 96570043)
On 2014/05/26 01:27:49, Mark Polesky wrote: Hi all, James has reported that this patch has somehow triggered an error in the mozart-hrn-3.ly regtest, which makes no sense to me: https://code.google.com/p/lilypond/issues/detail?id=3926#c3 To anyone jumping in here, the error has been cleared up: http://code.google.com/p/lilypond/issues/detail?id=3926#c12 Patch Set 4 passes all tests. - Mark https://codereview.appspot.com/96570043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add `ly:undead?' to predicate list. (issue 93660047)
Reviewers: dak, Message: On 2014/06/01 15:10:59, dak wrote: scm/lily.scm:728: (,ly:undead? . undead object) Probably more like an undead container as the undead thing (to survive between sessions) is placed inside. Won't be helpful information to somebody reading the manual which is the reason I'm somewhat unenthusiastic including it. On the other hand, there are lots of predicates sharing that deficiency. I never thought that the tiny predicate docstrings in lily.scm were so much about documentation; we have docstrings in lily/*.cc for that (IR 4: Scheme functions) -- and those descriptions can be longer if needed for clarity. I thought that the docstrings in lily.scm are primarily there for error reporting: wrong type for argument ~a. Expecting ~a, found ~s They have the added benefit of a little clarification in the Notation appendix Predefined type predicates, but I wouldn't want the error reporting to be too wordy. In either case, if my pretty-print patch goes through, then the lilypond-exported-predicates alist will also be used to define (ly-type? x). I don't know if an undead container would ever be the default value of some grob property in the future, but if it were, I wouldn't want it mistakenly prepended with a single-quote in the IR, which is what could happen with my other patch if we leave any predicates off of the list. - Mark Description: Add `ly:undead?' to predicate list. Please review this at https://codereview.appspot.com/93660047/ Affected files (+1, -0 lines): M scm/lily.scm Index: scm/lily.scm diff --git a/scm/lily.scm b/scm/lily.scm index 5d230d8f7eb9eef7439af897fe2d6418b1a81e46..44f9f62258342c89fde8066b844b1596d94b7709 100644 --- a/scm/lily.scm +++ b/scm/lily.scm @@ -725,6 +725,7 @@ messages into errors.) (,ly:stream-event? . stream event) (,ly:translator? . translator) (,ly:translator-group? . translator group) +(,ly:undead? . undead container) (,ly:unpure-pure-container? . unpure/pure container) )) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3935: Use (pretty-print) for some IR props. (issue 95710044)
On 2014/05/31 07:13:17, dak wrote: https://codereview.appspot.com/95710044/diff/150001/scm/lily-library.scm File scm/lily-library.scm (right): https://codereview.appspot.com/95710044/diff/150001/scm/lily-library.scm#newcode948 scm/lily-library.scm:948: (define (ly-type? x) Is this significantly different from (define (ly-type? x) (any (lambda (p) ((car p) x)) lilypond-exported-predicates)) No, but you didn't reply to the latest patch set there, where I had already addressed that (although your way is still better). By the way, I submitted a bug report to guile on the (pretty-print #:width ...) question: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17657 - Mark https://codereview.appspot.com/95710044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 3935: Use (pretty-print) for some IR props. (issue 95710044)
Reviewers: , Message: Here's a new patch to tidy up the IR a little bit. Please review. - Mark Description: This patch uses (pretty-print) instead of (display) to show some IR properties, such as alists and vectors, that are really hard to read as it stands. It increases the internals.pdf page-count from 638 to 651, but I believe the increase in legibility is worth it. View some examples at: http://code.google.com/p/lilypond/issues/detail?id=3935 Please review this at https://codereview.appspot.com/95710044/ Affected files (+109, -53 lines): M scm/document-backend.scm M scm/document-context-mods.scm M scm/document-translation.scm M scm/documentation-lib.scm M scm/lily-library.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3935: Use (pretty-print) for some IR props. (issue 95710044)
https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm
File scm/documentation-lib.scm (right):
https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm#newcode112
scm/documentation-lib.scm:112: (or (vector? val) ; vector is an ly-type
On 2014/05/30 08:38:23, dak wrote:
Comment makes no sense.
Would this pseudocode suffice?
; (ly-type? vector) = #t
The problem is that we need to make sure that most LilyPond internal
datatypes don't get displayed with @verbatim, since (pretty-print)
doesn't work on them, and they'll sail right past the page/screen
margin. I'm not sure what else to call them; I'm referring to things
that look like #Mom or #simple-closure etc.
So this prevents that problem:
(not (ly-type? val))
but causes another problem, namely that vectors would end up not getting
(pretty-print), which is the point after all. Hence the conditional:
(or (vector? val) ...
If the pseudocode I proposed above is still too abstruse, I welcome your
suggestions.
https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm#newcode138
scm/documentation-lib.scm:138: (lambda (port) (pretty-print val port
#:display? #t))
On 2014/05/30 08:38:23, dak wrote:
Wouldn't #:display? #t show a partial value of string as string
without
quotes? The examples in the issue report don't contain strings, so
it's hard to
guess.
That's correct, no quotes, hence the added quotes a few lines below:
(string-append \ str \)
An example is in the BarLine node, which after processing looks like
this in internals.texi:
@item @code{glyph} (string):
@code{|}
https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm#newcode144
scm/documentation-lib.scm:144: (string-regexp-substitute \n \n
str)))
On 2014/05/30 08:38:23, dak wrote:
pretty-print has a key #:per-line-prefix. Would that be easier to
use?
Yes, thank you.
https://codereview.appspot.com/95710044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3935: Use (pretty-print) for some IR props. (issue 95710044)
On 2014/05/30 09:11:57, Mark Polesky wrote: https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm#newcode144 scm/documentation-lib.scm:144: (string-regexp-substitute \n \n str))) On 2014/05/30 08:38:23, dak wrote: pretty-print has a key #:per-line-prefix. Would that be easier to use? Yes, thank you. I spoke too soon. I don't think #:per-line-prefix will work with my code structure here. The regex substitution is there for items prepended with a single-quote, which might not end up using pretty-print. Plus then we'd have to remove the first space anyway (or replace it with the quote). Unless you have some clever way of making it work, I think I'll leave it as is. https://codereview.appspot.com/95710044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3935: Use (pretty-print) for some IR props. (issue 95710044)
On 2014/05/30 10:45:36, dak wrote: ; (ly-type? vector) = #t That's rubbish. None of the given types in ly-type? should trigger for a vector. And indeed it would appear that the definition of ly:music-list? is broken and returns #t for anything that is not a list. Your new commit still leaves this situation: (ly:music-list? '()) = #t Is that intended? Instead of trying to work around obvious bugs when one finds them, they should be reported and fixed. Well, in my defense, I didn't realize it was a bug, but thanks for the speedy fix. That's correct, no quotes, hence the added quotes a few lines below: (string-append \ str \) But you'd get (x y) to print as (x y) then, wouldn't you? Yes, I hadn't noticed that. I had added `#:display #t' because without it, even slightly long lines would get wrapped, even when (pretty-print) was given a large value of #:width: '(... (-1 . accidentals.flatflat) (3/4 . accidentals.sharp.slashslash.stemstemstem) (1/4 . accidentals.sharp.slashslash.stem) ...) Is that a bug with (pretty-print #:width ...)? Or am I misunderstanding something? Anyway, you are right; as it stands, my patch drops the double-quotes with these strings: '(... (-1 . accidentals.flatflat) (3/4 . accidentals.sharp.slashslash.stemstemstem) (1/4 . accidentals.sharp.slashslash.stem) ...) What would you suggest? Should I recurse into the prop-values to put quotes around all those inner strings? Or just accept the needless line-wrapping (which is ugly to me)? Do I need to file a guile bug? For now, I'll remove the `#:display' since it's not right. I've uploaded a new patch that incorporates your new commit and other things, including a more maintainable definition of `ly-type?'. Please check it out. Thanks! - Mark https://codereview.appspot.com/95710044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Automatically sort alist grob-properties in IR. (issue 102760044)
Reviewers: dak, https://codereview.appspot.com/102760044/diff/1/scm/document-backend.scm File scm/document-backend.scm (right): https://codereview.appspot.com/102760044/diff/1/scm/document-backend.scm#newcode22 scm/document-backend.scm:22: (apply eq? #t (map pair? x On 2014/05/28 00:00:58, dak wrote: (apply eq? #t (map pair? x)) is horribly contorted and subject to limitations in argument list length. Use (every pair? x) which has the advantage of short-circuit evaluation. Ah, that's the procedure I was looking for, thanks! Sorry, I didn't know about that one. Also, it seems like a stretch to assume that every list with pair members will tolerate sorting. Do you mean that 1) the order of keys in some alists may be significant? or 2) my code might trigger a scheme error during sorting? Regarding #1, I *am* assuming that key-order is irrelevant, but if that's misguided, let me know. Regarding #2, I thought my definition of `ly:alist?' covered that with the `else' clause: (else (ly:string? (object-string (car a)) (object-string (car b You do not even restrict this to lists with symbols in the car and explicitly sort lists with non-symbols. That seems like a bad idea. Not trying to be annoying (really), but why? https://codereview.appspot.com/102760044/diff/1/scm/lily-sort.scm File scm/lily-sort.scm (right): https://codereview.appspot.com/102760044/diff/1/scm/lily-sort.scm#newcode112 scm/lily-sort.scm:112: ((and (number? (car a)) (number? (car b))) On 2014/05/28 00:00:58, dak wrote: Can you point to any alists where the keys are numbers? This seems rather fishy to me. Accidental.glyph-name-alist: '((0 . accidentals.natural) (-1/2 . accidentals.flat) (1/2 . accidentals.sharp) (1 . accidentals.doublesharp) (-1 . accidentals.flatflat) (3/4 . accidentals.sharp.slashslash.stemstemstem) (1/4 . accidentals.sharp.slashslash.stem) (-1/4 . accidentals.mirroredflat) (-3/4 . accidentals.mirroredflat.flat)) Finally, for what it's worth, here's the list of all alist grob-properties: http://www.markpolesky.com/norobots/alist-grob-properties.txt Thanks. - Mark Description: Automatically sort alist grob-properties in IR. Also, rewrite sorting code to be easier to understand. This will ensure that grob-properties whose default values are alists (like 'details or 'glyph-name-alist) will get sorted by key before being displayed in the IR section `All layout objects'. http://code.google.com/p/lilypond/issues/detail?id=3932 Please review this at https://codereview.appspot.com/102760044/ Affected files (+67, -28 lines): M scm/document-backend.scm M scm/lily-sort.scm Index: scm/document-backend.scm diff --git a/scm/document-backend.scm b/scm/document-backend.scm index 80ba17a3ba34cd1958f80fa6b72bae234613c008..272b7f36a7ed9a592740841141476dcfcc204404 100644 --- a/scm/document-backend.scm +++ b/scm/document-backend.scm @@ -16,27 +16,50 @@ You should have received a copy of the GNU General Public License along with LilyPond. If not, see http://www.gnu.org/licenses/. -(define (sort-grob-properties x) - ;; force 'meta to the end of each prop-list - (let ((meta (assoc 'meta x))) -(append (sort (assoc-remove! x 'meta) ly:alist-ci?) -(list meta -;; properly sort all grobs, properties, and interfaces +(define (alist? x) + (and (list? x) + (apply eq? #t (map pair? x + +(define (alist-prop? x) + (alist? (cdr x))) + +(define (not-alist-prop? x) + (not (alist-prop? x))) + +(define (sort-grob-properties x) + ;; props that are alists (eg. 'details) get sorted by key. + ;; also, force 'meta to the end of each prop-list. + (let* ((meta(assoc 'meta x)) + (all-but-meta(assoc-remove! x 'meta)) + (alist-props (filter alist-prop? all-but-meta)) + (non-alist-props (filter not-alist-prop? all-but-meta)) + (sorted-alist-props + (map (lambda (x) (cons (car x) + (sort (cdr x) ly:alist-ci?))) +alist-props)) + (all-but-meta-sorted + (sort (append sorted-alist-props non-alist-props) ly:alist-ci?))) +(append all-but-meta-sorted (list meta + +;; properly sort all properties, and interfaces ;; within the all-grob-descriptions alist (for-each - (lambda (x) - (let* ((props (assoc-ref all-grob-descriptions (car x))) - (meta (assoc-ref props 'meta)) - (interfaces (assoc-ref meta 'interfaces))) - (set! all-grob-descriptions - (sort (assoc-set! all-grob-descriptions (car x) - (sort-grob-properties - (assoc-set! props 'meta - (assoc-set! meta 'interfaces - (sort interfaces ly:symbol-ci?) - ly:alist-ci? - all-grob-descriptions) + (lambda (x) + (let* ((grob-key (car
Re: Clean up code for sorting grob-properties. (issue 102760044)
David's logic has convinced me to retract the alist-sorting of the previous patch. What remains is just a minor cleanup of the sorting code, which is hopefully now easier to understand. Please review the new patch. Thanks. - Mark https://codereview.appspot.com/102760044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Clean up code for sorting grob-properties. (issue 102760044)
On 2014/05/28 21:46:55, dak wrote: Doing an assoc-set! here is inefficient inside of the loop. Instead of (for-each (lambda (grob-description) ... (set! all-grob-descriptions (assoc-set! ... one should use (set! all-grob-descriptions (map! (lambda (grob-description) ;replacement for grob description) all-grob-descriptions)) Like this? https://codereview.appspot.com/102760044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3926: Add \magnifyMusic; clarify fontSize in docs. (issue 96570043)
Hi all, James has reported that this patch has somehow triggered an error in the mozart-hrn-3.ly regtest, which makes no sense to me: https://code.google.com/p/lilypond/issues/detail?id=3926#c3 If this in fact the case, can someone help identify the error, and how I can fix it? Because I have *no* idea. Thanks. - Mark https://codereview.appspot.com/96570043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Docs: new defaults for rehearsal mark alignment (issue 13300048)
https://codereview.appspot.com/13300048/diff/9001/Documentation/changes.tely File Documentation/changes.tely (right): https://codereview.appspot.com/13300048/diff/9001/Documentation/changes.tely#newcode86 Documentation/changes.tely:86: of the clef and key signature by default. As in previous versions, the 2 spaces after sentence in texinfo. https://codereview.appspot.com/13300048/diff/9001/Documentation/changes.tely#newcode88 Documentation/changes.tely:88: @lilypond[quote,relative=2] I think we usually put an empty line before @lilypond, though I don't see it mentioned in the CG. https://codereview.appspot.com/13300048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Measure 'staff-padding' to reference points, as claimed in its docstring (issue 7005056)
https://codereview.appspot.com/7005056/diff/35015/Documentation/learning/tweaks.itely File Documentation/learning/tweaks.itely (right): https://codereview.appspot.com/7005056/diff/35015/Documentation/learning/tweaks.itely#newcode2987 Documentation/learning/tweaks.itely:2987: \override DynamicLineSpanner.staff-padding = #3 I think we should stop using the `#' for scheme numbers. http://lilypond.org/doc/v2.17/Documentation/changes/index.html This applies elsewhere in the patchset, though I'll just mention it here. https://codereview.appspot.com/7005056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Restore the default `make' target. (issue 13290047)
https://codereview.appspot.com/13290047/diff/5001/stepmake/stepmake/generic-targets.make File stepmake/stepmake/generic-targets.make (right): https://codereview.appspot.com/13290047/diff/5001/stepmake/stepmake/generic-targets.make#newcode56 stepmake/stepmake/generic-targets.make:56: @echo default same as the empty target, restricted to current directory personally, I would find this wording more intuitive: same as `make all', but restricted to the current directory Although... I guess `make local-all' and `make default' do the same thing? Maybe you could just say same as `make local-all' These are just some ideas; I'll let you and the others decide if you want to change anything at all. - Mark https://codereview.appspot.com/13290047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3514: Clean up CG Major release checklist. (issue 10759043)
Here's a revised doc patch that I started last month. Feel free to review. Thanks. - Mark https://codereview.appspot.com/10759043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3457: Add NullVoice context (using \partcombine with lyrics). (issue 11328043)
Here's a patch that adds a new context, NullVoice, to provide users with an easier way to have shared lyrics among polyphonic voices, which also allows using lyrics with \partcombine. This is a complete rewrite of a similar patch from a month ago. Please review. Thanks! - Mark https://codereview.appspot.com/11328043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3491: Add \displayMarkup command. (issue 12732043)
David Kastrup wrote: I vote to go ahead with adding \displayMarkup. Huh? Can you name a _single_ advantage that is gained by having \displayMarkup (which is only different from \displayScheme by refusing to accept a number of arguments) instead of \displayScheme? Of course not. I meant let's add \displayMarkup or \displayScheme as opposed to Harm's or Ian's more generic proposals. Also, what is the issue with my original wording? Seems clear and concise compared to the other suggestions: To prevent the markup from printing on the page, use `\void \displayScheme markup'. I didn't add a @ref to where \void was previously explained because reading 13 words is easier than following a link and finding the paragraph containing the relevant material in a separate section, which in that specific case, was buried at the very end (Extending 1.3.1 Displaying music expressions). I *did* add a @ref to the save to an external file stuff because that's more involved. I've uploaded the latest incarnation. Thanks. - Mark https://codereview.appspot.com/12732043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove 'thickness from LedgerLineSpanner interface. (issue 12945044)
Reviewers: Trevor Daniels,
Message:
On 2013/08/14 21:35:16, Trevor Daniels wrote:
Should this not be @ref{...}?
No. @rinternals{...}. See
http://lilypond.org/doc/v2.17/Documentation/contributor/syntax-survey#cross-references
- Mark
Description:
Remove 'thickness from LedgerLineSpanner interface.
Please review this at https://codereview.appspot.com/12945044/
Affected files:
M lily/ledger-line-spanner.cc
Index: lily/ledger-line-spanner.cc
diff --git a/lily/ledger-line-spanner.cc b/lily/ledger-line-spanner.cc
index
d36f908b2c81d78aae69d3b1b8136500350b961d..ed234712d35ad6735987bf00cc54719d98bdd02c
100644
--- a/lily/ledger-line-spanner.cc
+++ b/lily/ledger-line-spanner.cc
@@ -326,14 +326,15 @@ Ledger_line_spanner::print (SCM smob)
ADD_INTERFACE (Ledger_line_spanner,
This spanner draws the ledger lines of a staff. This is a
separate grob because it has to process all potential
-collisions between all note heads.,
+collisions between all note heads. The thickness of
ledger
+lines is controlled by the @code{ledger-line-thickness}
+property of the @rinternals{StaffSymbol} grob.,
/* properties */
gap
length-fraction
minimum-length-fraction
note-heads
- thickness
);
struct Ledgered_interface
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove 'thickness from LedgerLineSpanner interface. (issue 12945044)
On 2013/08/15 07:24:48, dak wrote:
That documentation states as first entry:
@ref{…} — link within current manual.
Well, shoot. That's why we have a countdown. Sorry for the
mistake. Just, um, asserting my humanity, I guess...
Anyway, I made the change.
- Mark
https://codereview.appspot.com/12945044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3491: Add \displayMarkup command. (issue 12732043)
David Kastrup wrote: Any chance to join them completely? Not yet. It's a long-term goal. And of course, there are a few things that are not easily reconciled: compare \void\displayScheme -5 with \void\displayMusic -5 Well, I played around with this, and David's example is pretty convincing. I vote to go ahead with adding \displayMarkup. I can change the doc wording to suit everyone, but I'll wait for consensus on the function itself. One thing I don't understand though: what value is there in writing a \displayScheme command that takes a scheme argument and prints a scheme expression to the console? Seems pretty redundant to me. - Mark https://codereview.appspot.com/12732043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 3491: Add \displayMarkup command. (issue 12732043)
Reviewers: ,
Message:
Hi all, here's a new patch.
- Mark
Description:
Issue 3491: http://code.google.com/p/lilypond/issues/detail?id=3491
Please review this at https://codereview.appspot.com/12732043/
Affected files:
M Documentation/extending/programming-interface.itely
M ly/music-functions-init.ly
Index: Documentation/extending/programming-interface.itely
diff --git a/Documentation/extending/programming-interface.itely
b/Documentation/extending/programming-interface.itely
index
3b5e147664bb8fa341d111448d58700493f62fb5..ca710c57b93011b6e96a19e5f8a75f363b0cbba7
100644
--- a/Documentation/extending/programming-interface.itely
+++ b/Documentation/extending/programming-interface.itely
@@ -609,21 +609,48 @@ Markups are implemented as special Scheme functions
which produce a
@subsection Markup construction in Scheme
@cindex defining markup commands
+@funindex \displayMarkup
+
+Markup expressions are internally represented in Scheme using the
+@code{markup} macro:
-The @code{markup} macro builds markup expressions in Scheme while
-providing a LilyPond-like syntax. For example,
@example
-(markup #:column (#:line (#:bold #:italic hello #:raise 0.4 world)
- #:larger #:line (foo bar baz)))
+(markup @var{expr})
+@end example
+
+The easiest way to see how this works is with the
+@code{\displayMarkup} command, which converts a markup expression
+into its equivalent Scheme expression:
+
+@example
+\displayMarkup
+\markup @{
+ \column @{
+\line @{ \bold \italic hello \raise #0.4 world @}
+\larger \line @{ foo bar baz @}
+ @}
+@}
@end example
@noindent
-is equivalent to:
+Compiling the code above will send the following to the display
+console:
+
@example
-#@{ \markup \column @{ \line @{ \bold \italic hello \raise #0.4 world
@}
- \larger \line @{ foo bar baz @} @} #@}
+(markup
+ #:line
+ (#:column
+ (#:line
+(#:bold (#:italic hello) #:raise 0.4 world)
+#:larger
+(#:line
+ (#:simple foo #:simple bar #:simple baz)
@end example
+As with the @code{\displayMusic} command, the output of
+@code{\displayMarkup} can be saved to an external file. See
+@ref{Displaying music expressions}.
+
@noindent
This example demonstrates the main translation rules between regular
LilyPond markup syntax and Scheme markup syntax. Using @code{#@{
@@ -640,7 +667,7 @@ Scheme-only solution.
@item @code{\markup-command} @tab @code{#:markup-command}
@item @code{\variable} @tab @code{variable}
@item @code{\center-column @{ @dots{} @}} @tab
-@code{#:center-column ( @dots{} )}
+@code{#:center-column ( @dots{} )}
@item @code{string} @tab @code{string}
@item @code{#scheme-arg} @tab @code{scheme-arg}
@end multitable
@@ -850,7 +877,7 @@ padding.
\override #'(box-padding . 0.6) \box @{ #text @}#@}))
@end lisp
-or, equivalently
+or, equivalently
@lisp
#(define-markup-command (double-box layout props text) (markup?)
Index: ly/music-functions-init.ly
diff --git a/ly/music-functions-init.ly b/ly/music-functions-init.ly
index
8af797115f6a730b08e4ee153c71ac939f031591..4028ad7d2452f379c9ac672a14a79272ee142d41
100644
--- a/ly/music-functions-init.ly
+++ b/ly/music-functions-init.ly
@@ -342,6 +342,12 @@ displayMusic =
(display-scheme-music music)
music)
+displayMarkup =
+#(define-void-function (parser location markup) (markup?)
+ (_i Display the internal representation of @var{markup} to the
console.)
+ (newline)
+ (display-scheme-music markup))
+
endSpanners =
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3457: Add snippet `Using \partcombine with lyrics'. (issue 11328043)
On 2013/07/18 20:47:05, dak wrote:
Folks, this is the reference manual, not obscure hacks
for adventureous geeks. If we anticipate that a task is
common enough to warrant an entry in the reference manual,
it warrants a user interface.
Fair enough.
We might or might not want to cobble this user interface
together using a technique like that, but if we are really
proud of it, we can still point out that the
implementation, to be found in xxx.ly, might be
instructive.
So what would be a nice and natural user interface, and
what pieces are missing from it?
\new Staff \with { printPartCombineTexts = ##f }
\new HiddenVoice = voiceForLyrics \sopranoNotes
\new Voice {
\key g \major
\partcombine \sopranoNotes \altoNotes
}
\new Lyrics \lyricsto voiceForLyrics \words
HiddenVoice could also be LyricsVoice I suppose, but
HiddenVoice seems more sematically flexible.
This interface could possibly also solve another problem
that I have from time to time: in chorales, when the voices
use the same lyrics but have slightly different rhythms,
sometimes it's preferable to print a lyric syllable *in
between* where it would fall in the different voices. A
hidden voice (that the lyrics could align with) could solve
that (as long as it doesn't alter the spacing of the printed
voices, that is).
As for its usefulness, for me it would be an enormous
time-saver. A lot of my LilyPond work is typesetting 4-part
choir pieces, and without this feature I often end up
entering two voices as one like this:
upperNotes = \relative d' {
d g4 { fis8( g) } \\ d4 } d a'4 d g |
d c'4 d c' d b'2
}
... just so the Lyrics context has something to align to.
Each time the voices diverge rhythmically, I have to enter a
new { ... } \\ { ... } construct, which gets tedious,
difficult to maintain, and impossible to extract the
individual parts from. If I really need to extract voices
later, then I'm stuck going through each voice adding
\voiceOne and \voiceTwo all over the place, which is no less
tedious. And then if I need to transpose it, half of the
stem directions are wrong.
So yes, I would save untold hours if I had this feature. I
can't speak for anyone else, but we might ask the other
choral-music typesetters among us for their opinion.
- Mark
https://codereview.appspot.com/11328043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3457: Add snippet `Using \partcombine with lyrics'. (issue 11328043)
On 2013/07/19 08:27:20, dak wrote:
Ok. Is the _output_ from the following what you'd consider
appropriate?
sopranoNotes = { c''2 d''4 e'' }
altoNotes = { \repeat unfold 8 { a'16 g'16 } }
words = \lyricmode { Oh my head }
\new Staff \with { printPartCombineTexts = ##f \accepts Devnull }
\new Voice {
\key g \major
\partcombine \sopranoNotes \altoNotes
}
\new Devnull = aligner { \sopranoNotes }
\new Lyrics \lyricsto aligner \words
Basically, the question is whether we can do something like NullVoice
and get
along without any engravers/properties in it.
David,
you and your elegant solutions! Yes, the output is
excellent, except there's an odd beam inconsistency in the
last beat which I don't understand. But this solution is
already a vast improvement.
However, consider this example (which doesn't work using
your Devnull method). Ideally, what I'd want is to have the
2 horizontally centered between the NoteColumn with the
alto F and the NoteColumn with the soprano B:
sopranoNotes = \relative c'' { c4. b8 c2 }
altoNotes = \relative e' { e4 f e2 }
alignerNotes = { c4~ c16 c8. c2 }
words = \lyricmode { 1 2 3 }
\new Staff \with { printPartCombineTexts = ##f \accepts Devnull }
\new Voice { \partcombine \sopranoNotes \altoNotes }
\new Devnull = aligner { \alignerNotes }
\new Lyrics \lyricsto aligner \words
I actually *can* get this to work with my adventurous geek
method, except with my method the horizontal spacing is
altered in an unsatisfactory way.
To be clear, there are two separate effects I'd like to
achieve with this one interface:
1) aligning lyrics to one of the two partcombined voices
2) aligning lyrics to a third (hidden) voice, without altering spacing
It seems to me that you've nearly solved the first effect,
and I have no idea how easy or hard the second one would be.
Thanks again.
- Mark
https://codereview.appspot.com/11328043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3457: Add snippet `Using \partcombine with lyrics'. (issue 11328043)
On 2013/07/19 10:48:43, dak wrote:
To be clear, there are two separate effects I'd like to
achieve with this one interface:
1) aligning lyrics to one of the two partcombined voices
2) aligning lyrics to a third (hidden) voice, without
altering spacing
It's more like
3) aligning lyrics to non-existing note columns.
LilyPond does not align reasonably to non-existing note
columns anyway. One could try fudging in pseudo_engravers
that create note-busy events, but you'll still have the
problem that you _either_ need to reserve space (defeating
the without altering spacing purpose) _or_ don't get
reasonable positioning.
Is there no way to extract the averages of the NoteColumn
X-positions between two voices? So given these voices:
\relative c'' { c4. b8 c2 }
\relative e' { e4 f e2 }
... then the respective X-positions, measured in beats
(pardon the oversimplification), would be:
(0 1.5 2)
(0 1 2)
The remaining calculation is trivial:
(define avg
(lambda (x . rest)
(/ (apply + (cons x rest)) (1+ (length rest)
(map avg '(0 1.5 2) '(0 1 2)) == (0 1.25 2)
Is there a way to tell the Lyrics context to align notes to
the newly calculated X-positions? I may be out of my
league, but this would be really helpful; all the
workarounds that I've come up with are really ugly. Here's
a real-world example:
http://www.markpolesky.com/norobots/Day-Is-Done.png
This happens often enough to be a real pain.
Thanks
- Mark
https://codereview.appspot.com/11328043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3457: Add snippet `Using \partcombine with lyrics'. (issue 11328043)
David,
I've been playing around with your Devnull workaround, and
it's great! An independent aligner voice works as long as
there are NoteColumns in the printed voices that it can line
up with, though this is still really useful. (I'm willing
to put aside the averaging NoteColumn X-positions thing
for the moment, and explore this direction.)
Anyway, I had to add the Slur_engraver to your Devnull
context in order to get the melismas to work right, but
already this method solves a long-standing problem: getting
all the lyric extenders to print properly when the melismas
happen at different times in different voices:
sopranoNotes = \relative e' { e8( f g a) g2 | e1 }
altoNotes = \relative c' { c2 e8( d c b) | c1 }
alignerNotes = { c8( c c c) c( c c c) | c1 }
words = \lyricmode { one __ two __ three }
\new Staff \with {
\accepts Devnull
printPartCombineTexts = ##f
}
\new Voice { \partcombine \sopranoNotes \altoNotes }
\new Devnull = aligner \with {
\consists Slur_engraver
} { \alignerNotes }
\new Lyrics \lyricsto aligner \words
However, I can't get it to work with ties, even when adding
the Tie_engraver and Tie_performer to the Devnull context.
At this point I'm stabbing in the dark. Any ideas?
sopranoNotes = \relative e' { e4. e8~ e4 e }
altoNotes = \relative e' { c4. c8~ c4 c }
alignerNotes = \sopranoNotes
words = \lyricmode { one two __ three }
\new Staff \with {
\accepts Devnull
printPartCombineTexts = ##f
}
\new Voice { \partcombine \sopranoNotes \altoNotes }
\new Devnull = aligner \with {
\consists Slur_engraver
\consists Tie_engraver
\consists Tie_performer
} { \alignerNotes }
\new Lyrics \lyricsto aligner \words
Thanks.
- Mark
https://codereview.appspot.com/11328043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 3457: Add snippet `Using \partcombine with lyrics'. (issue 11328043)
Reviewers: , Message: Hi folks, here's a patch that adds a new snippet to NR Automatic part combining: my workaround to get \partcombine to work with lyrics. Is the texidoc too long? Should I leave out how it works? http://code.google.com/p/lilypond/issues/detail?id=3457 Thanks - Mark Description: Add snippet `Using \partcombine with lyrics'. Also run makelsr.py, and add reference in NR Automatic part combining. Please review this at https://codereview.appspot.com/11328043/ Affected files: M Documentation/notation/simultaneous.itely A Documentation/snippets/new/using-partcombine-with-lyrics.ly M Documentation/snippets/simultaneous-notes.snippet-list A Documentation/snippets/using-partcombine-with-lyrics.ly M Documentation/snippets/vocal-music.snippet-list M Documentation/snippets/workaround.snippet-list ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 1337: broken links on gub page (issue 10822043)
Reviewers: , Message: Graham, this is for you. Here's a patch for the GUB repo. https://codereview.appspot.com/10822043/ Just cleaning up some old cobwebs in the tracker. Can you push it to GUB master and marked issue 1337 as fixed? http://code.google.com/p/lilypond/issues/detail?id=1337 Thanks! - Mark Description: Fix broken links on history page of the website. Courtesy of the Wayback Machine: http://archive.org/ Please review this at https://codereview.appspot.com/10822043/ Affected files: M web/history.html Index: web/history.html diff --git a/web/history.html b/web/history.html index 1163121f254fcc76657463f9624e465262f326ff..a4086cac369a0923b63a30b906772771a28fd826 100644 --- a/web/history.html +++ b/web/history.html @@ -12,7 +12,7 @@ p class=homeurlGUB span class=subtitlethe Grand Unified Builder/span /p - + ul lia class= href=.Home/a/li lia class= href=basicsBasics/a/li @@ -29,13 +29,13 @@ h2HISTORY/h2 The story starts June 1999 with a - a href=http://www.sankey.ws/contact.html;crazy guy/a with an itch - to a href=http://www.sankey.ws/gnunt.html;run LilyPond on - Windows/a. + a href=http://web.archive.org/web/20020214055014/http://sankey.ws/index.html;crazy guy/a + with an itch to + a href=http://web.archive.org/web/20020121033345/http://www.sankey.ws/gnunt.html;run LilyPond on Windows/a. - To get a href=http://www.sankey.ws/rpm.html;a feel/a for the - times, this - was a href=http://lilypond.org/download/source/v1.1/;LilyPond-1.1.47/a, + To get a href=http://web.archive.org/web/20020121033829/http://www.sankey.ws/rpm.html;a feel/a + for the times, this was + a href=http://lilypond.org/download/source/v1.1/;LilyPond-1.1.47/a, requiring Egcs 1.1, Python 1.5, Guile 1.3, discussing on help-gnu-mu...@gnu.org. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Issue 519: Warn about cross-platform font inconsistencies. (issue 10819043)
On 2013/07/01 07:27:41, J_lowe wrote: And this is why. There has been no label change on this to know that it needs to be tested before it is then reviewed, Fortunately you at least put the tracker number in the summary. So I will go and change that for you so it gets tested. Ah. I thought I was missing something! I just wasn't sure what. So, on the Issue page, I need to... 1) post a link to the patch on Rietveld 2) change Status to Started 3) change Owner to me 4) add Label Patch-new Anything else? Do I Cc it -devel or something? Or does the bug squad get automatically notified every time an issue gets updated? Also, is this procedure in the CG somewhere? I think I got it now, I tried this out here, should be good, let me know: http://code.google.com/p/lilypond/issues/detail?id=1337 Sorry to have made more work for you, I really just didn't know the procedure. Thanks. https://codereview.appspot.com/10819043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds version number to web page side bar (Issue 3367) (issue 10506043)
Also, I don't have time to compile right now, but I don't suppose it also prints a version stamp in the older docs, like 2.12 and 2.14? Otherwise it doesn't really satisfy the original request on the tracker - http://code.google.com/p/lilypond/issues/detail?id=3367 . Personally, I think the real way to solve this problem is by fixing the issue I raised here: http://lists.gnu.org/archive/html/bug-lilypond/2013-06/msg00108.html . - Mark https://codereview.appspot.com/10506043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Updates to NR sections 3 and 4 (issue 10782045)
https://codereview.appspot.com/10782045/diff/1/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
https://codereview.appspot.com/10782045/diff/1/Documentation/notation/input.itely#newcode921
Documentation/notation/input.itely:921: opus = \markup { \italic Op.
13 }
Change Op.13 to BWV 846, so it's consistent with the rest of the
examples.
https://codereview.appspot.com/10782045/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Issue 519: Warn about cross-platform font inconsistencies. (issue 10819043)
Reviewers: ,
Message:
I don't know if this qualifies for a Fixed label on Issue 519, but let
me know what you think.
http://code.google.com/p/lilypond/issues/detail?id=519
Thanks.
- Mark
Description:
Issue 519: Warn about cross-platform font inconsistencies.
Please review this at https://codereview.appspot.com/10819043/
Affected files:
M Documentation/notation/text.itely
Index: Documentation/notation/text.itely
diff --git a/Documentation/notation/text.itely
b/Documentation/notation/text.itely
index
89c82c7d217f4b4cc936ed19681c25c0b6c921f5..0799f61259ed5ba30cabf5e2fcfd54f54b3021f8
100644
--- a/Documentation/notation/text.itely
+++ b/Documentation/notation/text.itely
@@ -1402,6 +1402,14 @@ Three families of text fonts are made available: the
@emph{roman}
@emph{sans} font and the monospaced @emph{typewriter} font -- these
last two families are determined by the Pango installation.
+@warning {There are no default fonts associated with the @emph{sans}
+and @emph{typewriter} font-families. An input file that specifies
+either of these can lead to different output on different computers.
+To ensure consistent output among multiple platforms, fonts must be
+specified by name, and those fonts must be available on any system
+that processes the file. See @ref{Single entry fonts} and
+@ref{Entire document fonts}.}
+
Each family may include different shapes and series. The following
example demonstrates the ability to select alternate families, shapes,
series and sizes. The value supplied to @code{font-size} is the
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds version number to web page side bar (Issue 3367) (issue 10506043)
https://codereview.appspot.com/10506043/diff/1/python/auxiliar/postprocess_html.py
File python/auxiliar/postprocess_html.py (right):
https://codereview.appspot.com/10506043/diff/1/python/auxiliar/postprocess_html.py#newcode60
python/auxiliar/postprocess_html.py:60: sidebar_version = _doc ('
V%(package_version)s (%(branch_str)s).')
Personally I prefer a lower-case v -- it's somehow easier to read.
https://codereview.appspot.com/10506043/diff/1/python/auxiliar/postprocess_html.py#newcode367
python/auxiliar/postprocess_html.py:367:
omit whitespace
https://codereview.appspot.com/10506043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 1168: website graphical design (issue 10700044)
Reviewers: ,
Message:
Hey all,
just randomly fixing an old issue.
https://codereview.appspot.com/10700044
- Mark
Description:
Issue 1168: website graphical design
On the website home page:
Center the `squiggle' graphic.
Add vertical space between news posts.
Please review this at https://codereview.appspot.com/10700044/
Affected files:
M Documentation/css/lilypond-website.css
Index: Documentation/css/lilypond-website.css
diff --git a/Documentation/css/lilypond-website.css
b/Documentation/css/lilypond-website.css
index
9daf395dc6e6d978979b851dab0cbc001c23376c..4dc2f28352ea12366365ada5ded487cfa1ba0f08
100644
--- a/Documentation/css/lilypond-website.css
+++ b/Documentation/css/lilypond-website.css
@@ -431,10 +431,10 @@ div#quickSummary {
}
div.separator {
- background: transparent url(../pictures/squiggle.jpg) no-repeat 40% 60%;
+ background: transparent url(../pictures/squiggle.jpg) no-repeat 50% 50%;
height: 36px;
- clear: both;
padding: 10px;
+ margin: 0 13em 0 0;
}
div#news {
@@ -443,6 +443,7 @@ div#news {
}
div.news-item {
+ padding: 1em 0;
}
.news-item .subsubheading {
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Updated entry for LANG in Usage (issue 5490060)
On 2011/12/17 14:20:44, Graham Percival wrote: Try this: git grep share/lilypond apparently it's in the Learning manual, which is bad because it should be covered in Usage. or rather: it's ok to have it discussed in Learning, but only as long as the reference material is in Usage. Could you fix this? New section or subsection, maybe called Installed files, in Usage, with a reference-style discussion of stuff that's in that part of Learning. Here's another old issue. Graham, I don't understand what you wrote here, but if all we want is a relatively stable list of LANG options in the Usage manual here: http://lilypond.org/doc/v2.17/Documentation/usage/command_002dline-usage#environment-variables ...we could just point the user to the ROADMAP file, or even better put a cross reference to http://lilypond.org/doc/v2.17/Documentation/contributor/repository-directory-structure ...or we could simply list them, and then add a new checklist item for translators of new languages here: http://lilypond.org/doc/v2.17/Documentation/contributor/getting-started-with-documentation-translation#starting-translation-in-a-new-language ...requiring them to add their LANG code to the ROADMAP and to the LANG list in Usage. A little old-fashioned perhaps, and not automated, but wouldn't that be good enough? - Mark https://codereview.appspot.com/5490060/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 3190: Fix W3C compliance. (issue 10774043)
Reviewers: ,
Message:
Issue 3190 lists 2 separate problems, w3c compliance and lynx
compatibility:
http://code.google.com/p/lilypond/issues/detail?id=3190
I've fixed the w3c compliance problem, though I haven't checked the lynx
problem. If the lynx thing is still problematic, someone should open a
new issue for that.
Adding extra @multitable's was the way to go; the misaligned columns
were easily solved by explicitly giving widths to the tables in css. In
the future, if a new manual link ever gets added with a name too long to
fit, it is trivial to adjust the css rule.
There was another option of using:
@multitable {dummy text to space col 1} {same for col 2}, etc.
...but I chose to take the css route.
One last thing, another patch I posted early today edits the same file,
Documentation/css/lilypond-website.css
(https://codereview.appspot.com/10700044/). I don't know if a rebase
will be needed or what, just thought I'd mention it.
Feel free to check this.
Thanks.
- Mark
Description:
Issue 3190: Fix W3C compliance.
Fix incorrect nesting of tables in `Manuals' section of
Community Development on website.
Adjust css rules as needed.
Please review this at https://codereview.appspot.com/10774043/
Affected files:
M Documentation/css/lilypond-website.css
M Documentation/web/community.itexi
Index: Documentation/css/lilypond-website.css
diff --git a/Documentation/css/lilypond-website.css
b/Documentation/css/lilypond-website.css
index
9daf395dc6e6d978979b851dab0cbc001c23376c..8589befe429d6ae012259ec444e1a71bf8d18422
100644
--- a/Documentation/css/lilypond-website.css
+++ b/Documentation/css/lilypond-website.css
@@ -903,6 +903,7 @@ div.color4 h3 {
padding : 0em;
border-left: 2px;
margin: 0em;
+ width: 67%;
}
.normal-table table td {
Index: Documentation/web/community.itexi
diff --git a/Documentation/web/community.itexi
b/Documentation/web/community.itexi
index
b87062c7ba7c5edf0eeeab40e10fbfcec285da86..54723d77f59f016826fa53d0647ae03b28d5466a
100644
--- a/Documentation/web/community.itexi
+++ b/Documentation/web/community.itexi
@@ -785,6 +785,7 @@ manuals can be found at @url{http://lilypond.org}}
@divClass{normal-table}
@multitable @columnfractions .3 .3 .3
@headitem Introduction
+
@item
@docLinkSplit{Learning,learning,@manualDevelLearningSplit}
@tab
@@ -805,7 +806,9 @@ manuals can be found at @url{http://lilypond.org}}
@docLinkBig{Essay,essay,@manualDevelEssayBig}
@tab
@docLinkPdf{Essay,essay,@manualDevelEssayPdf}
+@end multitable
+@multitable @columnfractions .3 .3 .3
@headitem Regular
@item
@@ -828,7 +831,9 @@ manuals can be found at @url{http://lilypond.org}}
@docLinkBig{Snippets,snippets,@manualDevelSnippetsBig}
@tab
@docLinkPdf{Snippets,snippets,@manualDevelSnippetsPdf}
+@end multitable
+@multitable @columnfractions .3 .3 .3
@headitem Infrequent
@item
@@ -858,15 +863,17 @@ manuals can be found at @url{http://lilypond.org}}
@docLinkBig{Internals,internals,@manualDevelInternalsBig}
@tab
@docLinkPdf{Internals,internals,@manualDevelInternalsPdf}
+@end multitable
@ifset web_version
+@multitable @columnfractions .3
@headitem Downloadable
@item
@doctarballDevel
+@end multitable
@end ifset
-@end multitable
@divEnd
@divEnd
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Directs displaying-grob-ancestry.ly to stderr (issue 5905052)
Hey guys, I don't want to be presumptuous here, but is there any chance I can be credited for the original idea? Or is that not typically done in the snippets directory? http://lists.gnu.org/archive/html/lilypond-devel/2009-07/msg00590.html Figuring that out was a proud moment for me! Hope you're all well. - Mark http://codereview.appspot.com/5905052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR rewrite of 3.2 Titles and Headers (issue4124056)
Thanks again to everyone here for helping to finish what I
started. I'll leave the style/content issues to the rest of
you; the comments below are just nitpicks.
- Mark
http://codereview.appspot.com/4124056/diff/18001/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
http://codereview.appspot.com/4124056/diff/18001/Documentation/notation/input.itely#newcode670
Documentation/notation/input.itely:670: fields at opposite ends of the
same line.To force titles to start on a
Use 2 spaces between sentences.
http://codereview.appspot.com/4124056/diff/18001/Documentation/notation/input.itely#newcode689
Documentation/notation/input.itely:689: the top and bottom of pages,
separate from the main text of a book. They
Use 2 spaces between sentences.
http://codereview.appspot.com/4124056/diff/18001/Documentation/notation/input.itely#newcode701
Documentation/notation/input.itely:701: defined in
@file{ly/titling-init.ly}. By default:
Use 2 spaces between sentences.
http://codereview.appspot.com/4124056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Rewrite NR 3.2 Titles and headers. (issue3667041)
Reviewers: , Message: Hey guys. Here's a complete rewrite of NR 3.2 Titles and headers. Please comment. You can disregard the first couple of patch sets, and go straight to the First Draft one. Thanks. - Mark Description: Rewrite NR 3.2 Titles and headers. Please review this at http://codereview.appspot.com/3667041/ Affected files: M Documentation/notation/input.itely M ly/titling-init.ly ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Clean up declarations-init.ly, paper-defaults-init.ly. (issue3465041)
I ran `make check' and this patch doesn't break anything, so I'll just push it. - Mark http://codereview.appspot.com/3465041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR 4: Minor edits. (issue3406041)
Pushed and closed. Thanks guys. - Mark http://codereview.appspot.com/3406041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Clean up declarations-init.ly, paper-defaults-init.ly. (issue3465041)
Reviewers: , Message: Here's a patch following the discussion here: http://lists.gnu.org/archive/html/lilypond-devel/2010-12/msg00034.html - Mark Description: Clean up declarations-init.ly, paper-defaults-init.ly. Please review this at http://codereview.appspot.com/3465041/ Affected files: M ly/declarations-init.ly M ly/paper-defaults-init.ly ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR 4: Minor edits. (issue3406041)
Hey guys, I made some requested changes. How does this look? - Mark http://codereview.appspot.com/3406041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: NR 4: Minor edits. (issue3406041)
Reviewers: , Message: Here's a patch to clean up the NR spacing chapter a little more. Does everything look okay? Thanks. - Mark Description: Doc: NR 4: Minor edits. Please review this at http://codereview.appspot.com/3406041/ Affected files: M Documentation/notation/spacing.itely ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove head- and foot-separation. (issue3199041)
On 2010/11/20 08:44:51, Trevor Daniels wrote: LGTM Patch pushed and issue closed. http://codereview.appspot.com/3199041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR 4.1: Reorganize, clarify details. (issue2758042)
On 2010/11/21 08:55:01, Trevor Daniels wrote: Looks good to go to me Trevor Patch pushed and issue closed. Thanks to everyone who helped out. This is a big change and I'm glad to see it finished! - Mark http://codereview.appspot.com/2758042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove head- and foot-separation. (issue3199041)
On 2010/11/20 01:23:07, Keith wrote: Misplaced underscore tag for translation? Oops. Fixed, thanks. On 2010/11/20 00:12:19, Graham Percival wrote: I would rather wait another 23.5 hours, to give people in all timezones (regardless of geographic location; I'm living in Pacific Standard Time at the moment) a chance to object. Alright, Graham, I'll push this some time after 23:49 GMT 2010-11-20 if no one objects by then! - Mark http://codereview.appspot.com/3199041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR 4.1: Reorganize, clarify details. (issue2758042)
Patch set 7. We're down to nitpicks here... I can't really think of a good way to break this up, except into 2 commits, the 2nd being far larger than the first. 1) Organize paper-defaults-init.ly. 2) Doc: NR 4.1, 4.2: Reorganize, clarify details. -- Reorganize node structure. Organize \paper variables. Revise variable descriptions. Explain \paper and \layout blocks. Improve examples. Clean up. The second commit will be almost 1600 lines long. Okay to push? - Mark http://codereview.appspot.com/2758042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove head- and foot-separation. (issue3199041)
Okay, this small patch is finished. Graham, would you like me to wait to push this for any reason? - Mark http://codereview.appspot.com/3199041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Remove head- and foot-separation. (issue3199041)
Reviewers: , Message: If I understand correctly, head-separation and foot-separation are gone. This patch just removes the vestiges from scm/ and ly/, but I suppose we should provide a convert-ly rule? So, in an earlier patch by Alexander... http://codereview.appspot.com/1710046/diff/19001/Documentation/notation/spacing.itely ...he suggests that (using the updated names), head-separation = #x should become top-system-spacing #'padding = #x and that foot-separation = #x should become last-bottom-spacing #'padding = #x Is that precisely how the conversion should be made? Can someone verify this? Should I push this patch or wait for a convert-ly rule? Thanks. - Mark Description: Remove head- and foot-separation. Please review this at http://codereview.appspot.com/3199041/ Affected files: M Documentation/notation/spacing.itely M input/regression/page-layout.ly M input/regression/paper-default-margins-a6.ly M input/regression/paper-default-margins-def.ly M ly/paper-defaults-init.ly M scm/paper.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR 4.1: Reorganize, clarify details. (issue2758042)
Hi guys, Patch set 5 finally makes the changes that Carl requested from the beginning: it's better to refer to a file where default values are defined, than to list them in the property descriptions. I've now done this, and I think this thing is ready to commit. However, I'd like to point out that I tried to organize paper-defaults-init.ly a little bit, and I need to know if I recklessly broke anything there by changing the order of the declarations. Can someone confirm that it's fine? Also, I should probably break this up into several smaller commits since it's more than 1600 lines long. - Mark http://codereview.appspot.com/2758042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove head- and foot-separation. (issue3199041)
On 2010/11/18 17:51:55, Graham Percival wrote: I'm getting a bit confused with all the renamings, reorganizations, etc., and I can't be the only one. Could we slow things down slightly? I'd like to see only one spacing patch on the table at once, and leaving 24 hours after the final draft of each patch for comments from people in all time zones. For this specific patch, 1) have people agreed to this specific naming change? 2) if the convert-ly change isn't part of this commit, it should be in the next commit. I think you should wait until you have both patches ready and approved, before pushing either of them. Graham, this patch is not about changing the names of head- and foot-separation. Those variables are already gone; they're bleedin' demised. When they ceased to be, the functionality they provided was presumably achievable using the new spacing alists, but a convert-ly rule to automate this was never written. This patch is about cleaning up the outdated code, and could also be about adding a convert-ly rule that should have been put there a while ago. There's nothing to vote on or debate about; I just don't know the proper conversion. Once someone verifies the right way to duplicate the old functionality, I can add the convert-ly rule to this patch and be done with it. - Mark http://codereview.appspot.com/3199041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR 4.1: Reorganize, clarify details. (issue2758042)
Patch set 4 uploaded. - Mark http://codereview.appspot.com/2758042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR 4.1: Reorganize, clarify details. (issue2758042)
Guys, I totally reorganized things yet again, and added a lot of useful info. I am aware that many of your previous comments have not been addressed yet (I'm not ignoring them). But I'd like to know what you guys think of the new text and organization. This is still a work in progress Thanks. - Mark http://codereview.appspot.com/2758042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR 4.4.1: Clean up property descriptions. (issue3089042)
Thanks, Trevor. Okay to push this now? - Mark http://codereview.appspot.com/3089042/diff/1/Documentation/notation/spacing.itely File Documentation/notation/spacing.itely (right): http://codereview.appspot.com/3089042/diff/1/Documentation/notation/spacing.itely#newcode1672 Documentation/notation/spacing.itely:1672: unset, for ungrouped staves and for grouped staves that do not On 2010/11/14 09:13:36, Trevor Daniels wrote: Still difficult to parse. How about two sentences: ... when it is unset. Applies to ungrouped staves ... Done. http://codereview.appspot.com/3089042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: NR 4.4.1: Clean up property descriptions. (issue3089042)
Reviewers: , Message: Just some clean-ups to NR 4.4.1 Flexible vertical spacing within systems. Any objections? Okay to push? - Mark Description: Doc: NR 4.4.1: Clean up property descriptions. Please review this at http://codereview.appspot.com/3089042/ Affected files: M Documentation/notation/spacing.itely ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Corrections and additions to NR 4.1.2, Page formatting. (issue1710046)
On 2010/11/13 17:33:47, Graham Percival wrote: This patch cannot be applied to current master. Please withdraw the patch, or rewrite it to match the post-renaming spacing docs. If you opt to rewrite it, then Mark Polesky can help you. Graham, I don't want to be a spoilsport, but I have a patch of my own that I'm pretty sure takes care of everything involved here (and more): http://codereview.appspot.com/2758042/ I seem to recall that Alexander has been aware of this for a while and is fine with it. There are already 17 comments on my patch, and I'll probably get around to a revised patch set soon-ish. Are we under a time crunch or anything? The two NR sections I'd like to finish before the next stable release are: NR 4.1 Paper and pages NR 4.4.1 Flexible vertical spacing within systems Of these two, NR 4.4.1 is almost done (if you want to comment on the last bit, see http://codereview.appspot.com/3089042/). But NR 4.1 still needs some work, so let me know what the time pressure is here. Except for renaming 'space to 'basic-distance (which I think Joe will take care of), all of the other syntax changes are done. But the doc patches mentioned above are still pending revision and/or approval. - Mark http://codereview.appspot.com/1710046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
