Re: LSR updates: was: polychords: a working solution
- Original Message - From: Thomas Morley thomasmorle...@googlemail.com To: David Nalesnik david.nales...@gmail.com seems the work is done. LSR is on 2.14 Thanks a lot for all your help!! Harm I'm catching up on the LSR emails, but thanks to both of you for the work you've done here. Looking forward to 2.16 -- Phil Holmes ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi David, Am 5. März 2012 01:07 schrieb David Nalesnik david.nales...@gmail.com: Hi Harm, I've just read the new description. Very nice! Of course you're aware: doing a good job means that more work of this kind will be offered. :) Ha, no problem. Oh, by the way, forgot to mention that I added to the actual snippet itself. Couldn't resist :) -David seems the work is done. LSR is on 2.14 Thanks a lot for all your help!! Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
- Original Message - From: Thomas Morley thomasmorle...@googlemail.com To: David Nalesnik david.nales...@gmail.com Cc: lilypond-user lilypond-user@gnu.org Sent: Saturday, March 03, 2012 11:14 PM Subject: Re: LSR updates: was: polychords: a working solution Hi David, 2012/3/3 David Nalesnik david.nales...@gmail.com: Hi Harm, I attached a tarball with all fixed files (hope it's not to big). Perhaps you could test compiling them. IIRC you use windows, it should make no difference, but who knows ... Everything compiles :) All I get are warnings with a few of the files. I've attached the trimmed-down results. I'll get back to you soon about the text you want me to look at. -David thanks for your effort. I know about most of the warnings. I think they can be disregarded. But I'm a little bit puzzled about these: warning: No glyph found for alteration: 54/125 (etc) warning: Could not find glyph-name for alteration 17/1000 warning: Incomplete keyAlterationOrder for key signature warning: MIDI channel wrapped around warning: remapping modulo 16 I never saw them before during my testings. And I can't appraise them. === Sebastiano would welcome an updated tarball. Please send it to vi...@dsi.unimi.it Thanks. -- Phil Holmes ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Phil, On 4 March 2012 18:30, Phil Holmes m...@philholmes.net wrote: - Original Message - From: Thomas Morley thomasmorle...@googlemail.com To: David Nalesnik david.nales...@gmail.com Cc: lilypond-user lilypond-user@gnu.org Sent: Saturday, March 03, 2012 11:14 PM Subject: Re: LSR updates: was: polychords: a working solution ... warning: MIDI channel wrapped around warning: remapping modulo 16 I never saw them before during my testings. And I can't appraise them. LIAR! http://lists.gnu.org/archive/html/lilypond-devel/2011-06/msg00833.html ;) I think if look in the Archives you might find the others too. -- -- James ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi James, 2012/3/4 James pkx1...@gmail.com: Phil, On 4 March 2012 18:30, Phil Holmes m...@philholmes.net wrote: - Original Message - From: Thomas Morley thomasmorle...@googlemail.com To: David Nalesnik david.nales...@gmail.com Cc: lilypond-user lilypond-user@gnu.org Sent: Saturday, March 03, 2012 11:14 PM Subject: Re: LSR updates: was: polychords: a working solution ... warning: MIDI channel wrapped around warning: remapping modulo 16 I never saw them before during my testings. And I can't appraise them. LIAR! http://lists.gnu.org/archive/html/lilypond-devel/2011-06/msg00833.html ;) I think if look in the Archives you might find the others too. -- -- James the point is, that I can't reproduce the warnings. So, I don't know whether LSR-updating is blocked by them or not. What do you think? Cheers, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
- Original Message - From: Thomas Morley thomasmorle...@googlemail.com To: James pkx1...@gmail.com Cc: Phil Holmes m...@philholmes.net; David Nalesnik david.nales...@gmail.com; lilypond-user lilypond-user@gnu.org Sent: Sunday, March 04, 2012 8:52 PM Subject: Re: LSR updates: was: polychords: a working solution Hi James, 2012/3/4 James pkx1...@gmail.com: Phil, On 4 March 2012 18:30, Phil Holmes m...@philholmes.net wrote: - Original Message - From: Thomas Morley thomasmorle...@googlemail.com To: David Nalesnik david.nales...@gmail.com Cc: lilypond-user lilypond-user@gnu.org Sent: Saturday, March 03, 2012 11:14 PM Subject: Re: LSR updates: was: polychords: a working solution ... warning: MIDI channel wrapped around warning: remapping modulo 16 I never saw them before during my testings. And I can't appraise them. LIAR! http://lists.gnu.org/archive/html/lilypond-devel/2011-06/msg00833.html ;) I think if look in the Archives you might find the others too. -- -- James the point is, that I can't reproduce the warnings. So, I don't know whether LSR-updating is blocked by them or not. What do you think? Cheers, Harm I'm not certain, but my expectation would be that warnings would not stop snippets from being displayed, so I would ignore them. -- Phil Holmes ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi, On Sun, Mar 4, 2012 at 3:05 PM, Phil Holmes m...@philholmes.net wrote: - Original Message - From: Thomas Morley thomasmorle...@googlemail.com** To: James pkx1...@gmail.com Cc: Phil Holmes m...@philholmes.net; David Nalesnik david.nales...@gmail.com; lilypond-user lilypond-user@gnu.org Sent: Sunday, March 04, 2012 8:52 PM Subject: Re: LSR updates: was: polychords: a working solution Hi James, 2012/3/4 James pkx1...@gmail.com: Phil, On 4 March 2012 18:30, Phil Holmes m...@philholmes.net wrote: - Original Message - From: Thomas Morley thomasmorle...@googlemail.com** To: David Nalesnik david.nales...@gmail.com Cc: lilypond-user lilypond-user@gnu.org Sent: Saturday, March 03, 2012 11:14 PM Subject: Re: LSR updates: was: polychords: a working solution ... warning: MIDI channel wrapped around warning: remapping modulo 16 I never saw them before during my testings. And I can't appraise them. LIAR! http://lists.gnu.org/archive/**html/lilypond-devel/2011-06/** msg00833.htmlhttp://lists.gnu.org/archive/html/lilypond-devel/2011-06/msg00833.html ;) I think if look in the Archives you might find the others too. -- -- James I initially ran the entire set of updated files in one go using lilypond *.ly 2stderr.log This appears to be the problem--thank you for the link, James: I would have never suspected that this could create problems. I went ahead and ran the files producing the strange results individually, and lo and behold! the warnings are gone. Here's my summary: **no warnings when compiled alone** `different-color-note-heads-in-one-staff.ly’ `filtering-parts-from-the-command-line.ly’ `hymn-template-wilhelmus-van-nassouwe.ly' `incipit.ly' `markup-accacciaturas.ly' `positioning-segno-and-coda-without-line-break.ly' `using-the-input-tag-property-to-create-musical-outlines.ly' Sorry for any confusion! -David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi David, 2012/3/4 David Nalesnik david.nales...@gmail.com: Hi, On Sun, Mar 4, 2012 at 3:05 PM, Phil Holmes m...@philholmes.net wrote: - Original Message - From: Thomas Morley thomasmorle...@googlemail.com To: James pkx1...@gmail.com Cc: Phil Holmes m...@philholmes.net; David Nalesnik david.nales...@gmail.com; lilypond-user lilypond-user@gnu.org Sent: Sunday, March 04, 2012 8:52 PM Subject: Re: LSR updates: was: polychords: a working solution Hi James, 2012/3/4 James pkx1...@gmail.com: Phil, On 4 March 2012 18:30, Phil Holmes m...@philholmes.net wrote: - Original Message - From: Thomas Morley thomasmorle...@googlemail.com To: David Nalesnik david.nales...@gmail.com Cc: lilypond-user lilypond-user@gnu.org Sent: Saturday, March 03, 2012 11:14 PM Subject: Re: LSR updates: was: polychords: a working solution ... warning: MIDI channel wrapped around warning: remapping modulo 16 I never saw them before during my testings. And I can't appraise them. LIAR! http://lists.gnu.org/archive/html/lilypond-devel/2011-06/msg00833.html ;) I think if look in the Archives you might find the others too. -- -- James I initially ran the entire set of updated files in one go using lilypond *.ly 2stderr.log This appears to be the problem--thank you for the link, James: I would have never suspected that this could create problems. I went ahead and ran the files producing the strange results individually, and lo and behold! the warnings are gone. Here's my summary: **no warnings when compiled alone** `different-color-note-heads-in-one-staff.ly’ `filtering-parts-from-the-command-line.ly’ `hymn-template-wilhelmus-van-nassouwe.ly' `incipit.ly' `markup-accacciaturas.ly' `positioning-segno-and-coda-without-line-break.ly' `using-the-input-tag-property-to-create-musical-outlines.ly' Sorry for any confusion! -David I just downloaded the LSR.tarball from today and ran a last successful test. I'd like to send it to Sebastiano. Shall we postpone the change of the description for increasing-spacing-between-staves.ly? (2.16. seems to be coming soon.) Cheers, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
On Mon, Mar 05, 2012 at 12:07:09AM +0100, Thomas Morley wrote: I just downloaded the LSR.tarball from today and ran a last successful test. I'd like to send it to Sebastiano. Please do. Shall we postpone the change of the description for increasing-spacing-between-staves.ly? No; if there's only one snippet left to alter, just stick that on your todo pile and fix it in the web interface after the entire thing is running 2.14. (2.16. seems to be coming soon.) I doubt it. Certainly don't hold your breath waiting for it. - Graham ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi, On Sun, Mar 4, 2012 at 5:16 PM, Graham Percival gra...@percival-music.cawrote: On Mon, Mar 05, 2012 at 12:07:09AM +0100, Thomas Morley wrote: I just downloaded the LSR.tarball from today and ran a last successful test. I'd like to send it to Sebastiano. Please do. Shall we postpone the change of the description for increasing-spacing-between-staves.ly? No; if there's only one snippet left to alter, just stick that on your todo pile and fix it in the web interface after the entire thing is running 2.14. I just finished rewriting the description a moment ago. I'll fix it once the update is through. -David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi David, 2012/3/5 David Nalesnik david.nales...@gmail.com: Hi, On Sun, Mar 4, 2012 at 5:16 PM, Graham Percival gra...@percival-music.ca wrote: On Mon, Mar 05, 2012 at 12:07:09AM +0100, Thomas Morley wrote: I just downloaded the LSR.tarball from today and ran a last successful test. I'd like to send it to Sebastiano. Please do. Shall we postpone the change of the description for increasing-spacing-between-staves.ly? No; if there's only one snippet left to alter, just stick that on your todo pile and fix it in the web interface after the entire thing is running 2.14. I just finished rewriting the description a moment ago. I'll fix it once the update is through. Sorry, I've just sent a tarball to Sebastiano. I hope that all is correct. THANKS A LOT FOR ALL YOUR HELP!! Best, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi Harm, I just finished rewriting the description a moment ago. I'll fix it once the update is through. Anyway, I suppose I should add the file to the conversation. Please look through it and see if it's accurate, and I'll take care of adding it when the LSR is running 2.14.2. Oh, and congratulations on everything you've accomplished!!! -David increasing-spacing-between-staves.ly Description: Binary data ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi Harm, On Sun, Mar 4, 2012 at 5:50 PM, Thomas Morley thomasmorle...@googlemail.com wrote: Hi David, Sorry, I've just sent a tarball to Sebastiano. I hope that all is correct. Everything compiles, and you fixed a number of things that didn't need fixing--that has to be good enough :) THANKS A LOT FOR ALL YOUR HELP!! You did the lion's share here, you really did, and this only got rolling because of you. (And I thought you said somewhere above that you would do anything but organize :) ) Best, David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi David, 2012/3/5 David Nalesnik david.nales...@gmail.com: Hi Harm, I just finished rewriting the description a moment ago. I'll fix it once the update is through. Anyway, I suppose I should add the file to the conversation. Please look through it and see if it's accurate, and I'll take care of adding it when the LSR is running 2.14.2. I've just read the new description. Very nice! Of course you're aware: doing a good job means that more work of this kind will be offered. :) Cheers, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi again, 2012/3/5 David Nalesnik david.nales...@gmail.com: Hi Harm, On Sun, Mar 4, 2012 at 5:50 PM, Thomas Morley thomasmorle...@googlemail.com wrote: Hi David, Sorry, I've just sent a tarball to Sebastiano. I hope that all is correct. Everything compiles, and you fixed a number of things that didn't need fixing--that has to be good enough :) hope so. Cheers, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi Harm,
I attached a tarball with all fixed files (hope it's not to big).
Perhaps you could test compiling them. IIRC you use windows, it should
make no difference, but who knows ...
Everything compiles :) All I get are warnings with a few of the files.
I've attached the trimmed-down results.
I'll get back to you soon about the text you want me to look at.
-David
GNU LilyPond 2.14.2
`adding-a-figured-bass-above-or-below-the-notes.ly'
OK
`adding-fingerings-to-tablatures.ly'
OK
`adjusting-lyrics-vertical-spacing.ly'
OK
`affecting-items-only-on-the-left-or-rigth-of-a-linebreak-barlines,-keysignatures,-clefs-etc..ly'
OK
`altering-the-number-of-stems-in-a-beam.ly'
OK
_
`ancient-accidentals.ly'
A number of warnings of this type:
ancient-accidentals.ly:27:6: warning: Could not find glyph-name for alteration 1
cisis^\markup { \typewriter vaticana } cis c ces ceses
ancient-accidentals.ly:25:55: warning: Could not find glyph-name for alteration
-1
cisis^\markup { \typewriter medicaea } cis c ces
ceses
ancient-accidentals.ly:29:55: warning: Could not find glyph-name for alteration
-1
cisis^\markup { \typewriter mensural } cis c ces
ceses
[...]
`automatic-beam-subdivisions.ly'
OK
`automatic-beams-two-per-two-in-4-4-or-2-2-time-signature.ly'
OK
`beam-endings-in-score-context.ly'
OK
`beam-grouping-in-7-8-time.ly'
OK
`changing-the-time-signature-without-affecting-the-beaming.ly'
OK
`chord-names-and-lyrics-without-a-staff.ly'
A number of warnings of this type:
chord-names-and-lyrics-without-a-staff.ly:14:20: warning: Lyric syllable does
not have note. Use \lyricsto or associatedVoice.
text = \lyricmode {
Ho ho, ho ho ho. Ha ha, ha. }
warning: staff-affinities should only decrease
`chords-headword.ly'
OK
`clip-systems.ly'
OK
`coloring-individual-staff-lines.ly'
OK
`combining-pedal-notes-with-clef-changes.ly'
OK
___
`combining-two-parts-on-the-same-staff.ly'
combining-two-parts-on-the-same-staff.ly:26:8: warning: already have slur
a4 c4.
( g8) a4 |
combining-two-parts-on-the-same-staff.ly:26:8: warning: already have slur
a4 c4.
( g8) a4 |
combining-two-parts-on-the-same-staff.ly:32:12: warning: cannot end slur
g4 e4.( d8
) c4 |
combining-two-parts-on-the-same-staff.ly:32:12: warning: cannot end slur
g4 e4.( d8
) c4 |
combining-two-parts-on-the-same-staff.ly:33:14: warning: cannot end slur
r2 g'4( f8 e
) |
combining-two-parts-on-the-same-staff.ly:33:14: warning: cannot end slur
r2 g'4( f8 e
) |
`complex-compound-time-signatures.ly'
OK
`conducting-signs,-measure-grouping-signs.ly'
OK
`consecutive-tremolos.ly'
OK
__
`creating-a-schenker-graph.ly'
creating-a-schenker-graph.ly:94:22: warning: weird stem size, check for narrow
beams
fis' g'
a'
creating-a-schenker-graph.ly:101:12: warning: weird stem size, check for narrow
beams
b'
_
`cross-staff-chords---beaming-problems-workaround.ly'
OK
`custom-tuning-and-midi.ly'
OK
___
Processing `defining-predefined-fretboards-for-other-instruments.ly'
warning: Cannot find glyph
warning: Cannot find glyph
warning: Cannot find glyph
___
___
`different-colored-note-heads-in-one-staff.ly'
lots of warnings:
warning: Incomplete keyAlterationOrder for key signature
warning: No glyph found for alteration: 54/125
_
`displaying-bar-numbers-on-a-separate-staff.ly'
OK
`displaying-complex-chords.ly'
OK
`filtering-parts-from-the-command-line.ly'
A number of these:
warning: Could not find glyph-name for alteration 17/1000
`function-to-create-wygiwym-chord-names.ly'
OK
`hiding-staves-with-rests-only-for-some-all-voices.ly'
OK
`how-to-define-autobeamsettings-in-the--layout-block.ly'
OK
`how-to-improve-automatic-beam-groups-when-frequently-using--time.ly'
OK
`how-to-show-a-staff-and-ledger-lines-without-notes.ly'
OK
___
Re: LSR updates: was: polychords: a working solution
Hi David, 2012/3/3 David Nalesnik david.nales...@gmail.com: Hi Harm, I attached a tarball with all fixed files (hope it's not to big). Perhaps you could test compiling them. IIRC you use windows, it should make no difference, but who knows ... Everything compiles :) All I get are warnings with a few of the files. I've attached the trimmed-down results. I'll get back to you soon about the text you want me to look at. -David thanks for your effort. I know about most of the warnings. I think they can be disregarded. But I'm a little bit puzzled about these: warning: No glyph found for alteration: 54/125 (etc) warning: Could not find glyph-name for alteration 17/1000 warning: Incomplete keyAlterationOrder for key signature warning: MIDI channel wrapped around warning: remapping modulo 16 I never saw them before during my testings. And I can't appraise them. Best, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi Harm, On Wed, Feb 29, 2012 at 6:57 PM, Thomas Morley thomasmorle...@googlemail.com wrote: Converting some files gave: Not smart enough to convert minimum-Y-extent. Vertical spacing no longer depends on the Y-extent of a VerticalAxisGroup. Please refer to the manual for details, and update manually. (or sth similiar). Could be fixed. I changed my mind about these files and fixed them too. Thank you so much for all your effort in this! One file gives me problems: forcing-fixed-distance-between-staves.ly Currently I don't know how to receive the promised results with the 2.14.2-commands. Suggestions? The following section of the NR explains how to do this: http://www.lilypond.org/doc/v2.14/Documentation/notation/explicit-staff-and-system-positioning It wouldn't be a problem to convert the snippet using these guidelines, but because of the duplication, maybe it should just be deleted? -David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi David, 2012/3/1 David Nalesnik david.nales...@gmail.com: Hi Harm, On Wed, Feb 29, 2012 at 6:57 PM, Thomas Morley thomasmorle...@googlemail.com wrote: Converting some files gave: Not smart enough to convert minimum-Y-extent. Vertical spacing no longer depends on the Y-extent of a VerticalAxisGroup. Please refer to the manual for details, and update manually. (or sth similiar). Could be fixed. I changed my mind about these files and fixed them too. Thank you so much for all your effort in this! One file gives me problems: forcing-fixed-distance-between-staves.ly Currently I don't know how to receive the promised results with the 2.14.2-commands. Suggestions? The following section of the NR explains how to do this: http://www.lilypond.org/doc/v2.14/Documentation/notation/explicit-staff-and-system-positioning It wouldn't be a problem to convert the snippet using these guidelines, of course! Must have been very tired to overlook them. But nevertheless, I didn't manage to reproduce the last shown feature of that file: staves swapped around but because of the duplication, maybe it should just be deleted? staves swapped around are not shown in the NR. So if we can make it work, the snippet is worth to keep. Many thanks for all your help! Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi Harm, staves swapped around are not shown in the NR. So if we can make it work, the snippet is worth to keep. I haven't been able to make this work either. Whenever I use negative values as in the original snippet I get programming errors such as insane spring distance requested, ignoring it. I can put one staff directly on top of the other, but that's as far as it goes. I can't imagine the use of reversing staves by this method. (After all, you can simply reverse their order in the StaffGroup block.) -David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi,
2012/2/29 Thomas Morley thomasmorle...@googlemail.com:
TODO
Convert:
Converting some files gave:
Not smart enough to convert minimum-Y-extent.
Vertical spacing no longer depends on the Y-extent of a VerticalAxisGroup.
Please refer to the manual for details, and update manually.
(or sth similiar).
Could be fixed.
I changed my mind about these files and fixed them too.
I used a little script after the script from CG 7.7 Updating LSR to a
new version to ease the process:
#!/bin/bash
for LILYFILE in *.ly
do
STEM=$(basename $LILYFILE .ly);
echo running $LILYFILE...;
convert-ly -e -t2.14.2 $LILYFILE $STEM.txt;
done
One file gives me problems: forcing-fixed-distance-between-staves.ly
converting-log:
convert-ly (GNU LilyPond) 2.15.30
convert-ly: Processing `forcing-fixed-distance-between-staves.ly'...
Applying conversion: 2.12.3, 2.13.0, 2.13.1, 2.13.4,
Not smart enough to convert alignment-offsets.
alignment-offsets has been changed to alignment-distances:
you must now specify the distances between staves rather than the
offset of staves.
Please refer to the manual for details, and update manually.
2.13.10, 2.13.16, 2.13.18, 2.13.20, 2.13.27, 2.13.29, 2.13.31,
2.13.36, 2.13.39,
2.13.40, 2.13.42, 2.13.44, 2.13.46, 2.13.48, 2.13.51, 2.14.0
Well, it compiles without warning but it does nothing (as opposed to 2.12.3).
Currently I don't know how to receive the promised results with the
2.14.2-commands.
Suggestions?
Thanks,
Harm
\version 2.12.2
\header {
texidoc =
Since the staves in a PianoStaff context no longer have a fixed
distance set as default, this can result in wide variations in system
spacing.If you need to prevent the spacing engine from varying the
distance between staves (not just piano staves), you can override the
property @code{line-break-system-details} in the
@code{NonMusicalPaperColumn} object. In the first example, we override
the @code{NonMusicalPaperColumn} object in the score's context block;
the result is completely fixed vertical distance throughout the score.
In the second example, the override is applied on the fly at different
points (but always at line breaks) throughout the score; the result is
precisely controlled -- but varying -- amounts of vertical space for
each system, plus the option (see final system) of swapping the staves
around. Note that in this case, overriding @code{NonMusicalPaperColumn}
inline with note entry requires the special @code{\\overrideProperty}
command.
doctitle = Forcing fixed distance between staves
}
\book {
\score {
\new PianoStaff
\new Staff {
c'1^Fixed distance: fourteen staff spaces for every system
\break
\repeat unfold 5 { c'1 \break }
}
\new Staff {
\clef bass
\repeat unfold 6 { c'1 }
}
\layout {
\context {
\Score
\override NonMusicalPaperColumn
#'line-break-system-details = #'((alignment-offsets . (0 -14)))
}
}
}
\score {
\new StaffGroup
\new Staff {
\overrideProperty #Score.NonMusicalPaperColumn
#'line-break-system-details #'((alignment-offsets . (0 -10)))
c'1^Ten staff spaces
\break
\overrideProperty #Score.NonMusicalPaperColumn
#'line-break-system-details #'((alignment-offsets . (0 -20)))
c'1^Twenty staff spaces
\break
\overrideProperty #Score.NonMusicalPaperColumn
#'line-break-system-details #'((alignment-offsets . (0 -30)))
c'1^Thirty staff spaces
\break
\overrideProperty #Score.NonMusicalPaperColumn
#'line-break-system-details #'((alignment-offsets . (0 10)))
c'1^Ten staff spaces again, with staves swapped around
}
\new Staff {
\clef bass
c'1
c'1
c'1
c'1
}
}
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
- Original Message - From: Thomas Morley thomasmorle...@googlemail.com If you agree, what to do now? I'll see how Sebastiano (maintainer of the LSR) is progressing on looking at updating the binary on the LSR. -- Phil Holmes ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi Phil, 2012/2/28 Thomas Morley thomasmorle...@googlemail.com: Hi Phil, in the LSR-tarball I found the directory correction-wanted, shall I fix these files too? (I'd think, some of them should be deleted) I didn't look in the other directories. It seems they contain only sorted duplicates. Or am I wrong? Cheers, Harm I just downloaded the latest tarball from the LSR and tested our work: No failed file. No ERROR One error: reported here: http://lists.gnu.org/archive/html/bug-lilypond/2012-02/msg01036.html 8 files gave a warning (but they did it in 2.12.3 too, or the warning is related to known bug, so I'd suggest to end the work on these files) Seems I can see the light at the end of the tunnel. :) Possible list of further work: TODO Convert: Converting some files gave: Not smart enough to convert minimum-Y-extent. Vertical spacing no longer depends on the Y-extent of a VerticalAxisGroup. Please refer to the manual for details, and update manually. (or sth similiar). Could be fixed. Files: Including-a-file-only-once.ly David Kastrup wrote: #(define-public toplevel-module-define-public! #f) #(define-public toplevel-module-ref #f) Those can be replaced by their straightforward counterpart. But I couldn't find them. use-custom-fonts-flat-b-and-sharp-#-symbols-for-chords.ly David Kastrup wrote: What are people's feelings about the rather bland compatibility fix of just catching a wrong-number-of-args error and try calling without that arg? Possibly lowercasing the result manually afterwards (if the flag is set), but that may not work with arbitrary markups. If we don't want to encourage a mixture of code styles flying around, we can still emit a warning. Of course, this snippet itself should be changed, but we could help with compatibility in that manner. I'm not sure how to proceed. woodwind-diagrams-key-lists.ly Failed! Don't know what to do with it! Deleted for now! The only thing I could imagine to carry on, is to fix the files where convert-ly gave Not smart enough ..., but I'd suggest to postpone it. If you agree, what to do now? Best, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi David, 2012/2/27 David Nalesnik david.nales...@gmail.com: I realize that it's not necessary for an update that warnings be fixed, so feel free to ignore this :) reducing the quantity of warnings is fine. I changed the file according to your suggestion. Thanks, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
- Original Message - From: Thomas Morley thomasmorle...@googlemail.com To: Phil Holmes m...@philholmes.net Cc: lilypond-user lilypond-user@gnu.org Sent: Sunday, February 26, 2012 10:30 PM Subject: Re: LSR updates: was: polychords: a working solution Hi Phil, this step from CG 7.7 Updating LSR to a new version 2. Copy relevant snippets (i.e., snippets whose version is equal to or less than the new version of LilyPond) from ‘Documentation/snippets/new/’ into the tarball. is outstanding. I don't know how to extract them other than manually and this would be worse. How to do? Best, Harm == Have you got them from the source tarball? -- Phil Holmes ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi Phil,
2012/2/27 Phil Holmes m...@philholmes.net:
- Original Message - From: Thomas Morley
thomasmorle...@googlemail.com
To: Phil Holmes m...@philholmes.net
Cc: lilypond-user lilypond-user@gnu.org
Sent: Sunday, February 26, 2012 10:30 PM
Subject: Re: LSR updates: was: polychords: a working solution
Hi Phil,
this step from CG 7.7 Updating LSR to a new version
2. Copy relevant snippets (i.e., snippets whose version is equal to
or less than the new version of LilyPond) from
‘Documentation/snippets/new/’ into the tarball.
is outstanding.
I don't know how to extract them other than manually and this would be
worse. How to do?
Best,
Harm
==
Have you got them from the source tarball?
--
Phil Holmes
got them. (Please hold in mind that I don't compile lilypond myself,
so I had to look around. Found it on
http://lilypond.org/development.html - Source:
lilypond-2.15.30.tar.gz. Might be worth a new doc-addition)
But there is a not compiling file in it!
woodwind-diagrams-key-lists.ly gives:
woodwind-diagrams-key-lists.ly:16:1: error: GUILE signaled an error
for the expression beginning here
#
(print-keys-verbose 'piccolo (current-error-port))
Wrong number of arguments to #procedure print-keys-verbose (instrument)
etc.
Well, the description says: The list will be displayed
in the log file, but not in the music. If output to the console
is wanted, omit the @code{(current-error-port)} from the commands.
and it works when omitting (current-error-port) but I don't know what
to do else!
File attached.
Cheers,
Harm
\version 2.14.0
\header {
lsrtags = winds
texidoc=
The snippet below produces a list of all possible keys and key
settings for woodwind diagrams as defined in
@file{scm/define-woodwind-diagrams.scm}. The list will be displayed
in the log file, but not in the music. If output to the console
is wanted, omit the @code{(current-error-port)} from the commands.
doctitle = Woodwind diagrams key lists
}
#(print-keys-verbose 'piccolo (current-error-port))
#(print-keys-verbose 'flute (current-error-port))
#(print-keys-verbose 'flute-b-extension (current-error-port))
#(print-keys-verbose 'tin-whistle (current-error-port))
#(print-keys-verbose 'oboe (current-error-port))
#(print-keys-verbose 'clarinet (current-error-port))
#(print-keys-verbose 'bass-clarinet (current-error-port))
#(print-keys-verbose 'low-bass-clarinet (current-error-port))
#(print-keys-verbose 'saxophone (current-error-port))
#(print-keys-verbose 'soprano-saxophone (current-error-port))
#(print-keys-verbose 'alto-saxophone (current-error-port))
#(print-keys-verbose 'tenor-saxophone (current-error-port))
#(print-keys-verbose 'baritone-saxophone (current-error-port))
#(print-keys-verbose 'bassoon (current-error-port))
#(print-keys-verbose 'contrabassoon (current-error-port))
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi Phil, in the LSR-tarball I found the directory correction-wanted, shall I fix these files too? (I'd think, some of them should be deleted) I didn't look in the other directories. It seems they contain only sorted duplicates. Or am I wrong? Cheers, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi,
in repeat-with-upbeat-and-different-durations-in-the-alternatives.ly (
= http://lsr.dsi.unimi.it/LSR/Item?id=490 ) I want to avoid the
warning, but I can't find a proper fix. All I can think of is crude
and ugly:
{
\repeat volta 2 {
\partial 4
e'4
c'2
}
\alternative {
{
f'4
}
{
\partial 2
a'2
}
}
c'1
}
%--- very crude and ugly work-around:
{
\repeat volta 2 {
\partial 4
e'4
c'2
}
\alternative {
{
f'4
}
{
\set Timing.measureLength = #(ly:make-moment 1 4)
\once \override NoteHead #'duration-log = #1
a'4
\unset Timing.measureLength
}
}
c'1
}
Suggestions?
Cheers,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi,
in the preventing-final-mark-from-removing-final-tuplet.ly (=
http://lsr.dsi.unimi.it/LSR/Item?id=705 ) I noticed a bug with \set
tupletFullLength and \mark while using 2.14.2 and 2.15.30.
log:
warning: Found infinity or nan in output. Substituting 0.0
Made a bug-report about it.
For now I use a shorter mark.
Cheers,
Harm
\version 2.14.0
\header {
texidoc =
The addition of a final @code{mark} can result in the loss of a final
tuplet marking. This can be overcome by setting @code{TupletBracket
#'full-length-to-extent} to @code{false}.
doctitle = Preventing final mark from removing final tuplet
}
\new Staff {
\set tupletFullLength = ##t
\time 1/8
\times 2/3 { c'16 c'16 c'16 }
\times 2/3 { c'16 c'16 c'16 }
\times 2/3 { c'16 c'16 c'16 }
\override Score.RehearsalMark #'break-visibility = #'#(#t #t #t)
\override Score.RehearsalMark #'direction = #DOWN
\override Score.RehearsalMark #'self-alignment-X = #RIGHT
\mark 1234
% due to a bug the following line is commented
% \mark Composed Feb 2007 - Feb 2008
}
\new Staff {
\set tupletFullLength = ##t
\override TupletBracket #'full-length-to-extent = ##f
\time 1/8
\times 2/3 { c'16 c'16 c'16 }
\times 2/3 { c'16 c'16 c'16 }
\times 2/3 { c'16 c'16 c'16 }
\override Score.RehearsalMark #'break-visibility = #'#(#t #t #t)
\override Score.RehearsalMark #'direction = #DOWN
\override Score.RehearsalMark #'self-alignment-X = #RIGHT
\mark 1234
% due to a bug the following line is commented
% \mark Composed Feb 2007 - Feb 2008
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi Harm,
On Sun, Feb 26, 2012 at 10:59 AM, Thomas Morley
thomasmorle...@googlemail.com wrote:
Hi,
in repeat-with-upbeat-and-different-durations-in-the-alternatives.ly (
= http://lsr.dsi.unimi.it/LSR/Item?id=490 ) I want to avoid the
warning, but I can't find a proper fix. All I can think of is crude
and ugly:
[...]
Suggestions?
This seems to do the trick:
{
\repeat volta 2 {
\partial 4
e'4
\set Timing.measureLength = #(ly:make-moment 5 4)
c'2
}
\alternative {
{
f'4
}
{
a'2
}
}
\unset Timing.measureLength
c'1
}
-David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi David, 2012/2/26 David Nalesnik david.nales...@gmail.com: This seems to do the trick: [...] many thanks for this and for your and David Kastrup's work on this intractable filtering-parts-from-the-command-line.ly file. Best, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi Harm, On Sun, Feb 26, 2012 at 12:28 PM, Thomas Morley thomasmorle...@googlemail.com wrote: many thanks for this and for your and David Kastrup's work on this intractable filtering-parts-from-the-command-line.ly file. My pleasure! So, are there any other snippets that need looking at? It looks like all the non-compiling ones have been accounted for, and now you've moved on to those that give warnings. Are there any of those I could look at? -David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi Phil, this step from CG 7.7 Updating LSR to a new version 2. Copy relevant snippets (i.e., snippets whose version is equal to or less than the new version of LilyPond) from ‘Documentation/snippets/new/’ into the tarball. is outstanding. I don't know how to extract them other than manually and this would be worse. How to do? Best, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi,
2012/2/24 Thomas Morley thomasmorle...@googlemail.com:
Well, I have to do some clean up, but apart from this last file the
main work seems to be done, so far normal users can do.
Or missed I something?
Thanks,
Harm
I detected several other problematic files. :(
One of them is beams-across-line-breaks.ly.
It is part of the NR 1.2.4 , too. So I will delete it from LSR. But it
doesn't compile without warning:
programming error: Disagree on common x. Skipping collisions in beam scoring.
continuing, cross fingers
I'll make a bug-report about it.
Cheers,
Harm
\version 2.14.2
\header {
texidoc =
Line breaks are normally forbidden when beams cross bar lines. This
behavior can be changed as shown:
doctitle = Beams across line breaks
}
\relative c'' {
\override Voice.Beam #'breakable = ##t
c8 c[ c] c[ c] c[ c] c[ \break
c8] c[ c] c[ c] c[ c] c
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
2012/2/25 Thomas Morley thomasmorle...@googlemail.com: I detected several other problematic files. :( Next: adding-a-figured-bass-above-or-below-the-notes.ly The command \once \override Staff.BassFigureAlignmentPositioning #'direction = #CENTER gives a log-warning (but worked in 2.12.3): programming error: direction unknown, but aligned-side wanted continuing, cross fingers If noone objects I delete this command from the file. Harm adding-a-figured-bass-above-or-below-the-notes.pdf Description: Adobe PDF document ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
2012/2/25 Thomas Morley thomasmorle...@googlemail.com:
2012/2/25 Thomas Morley thomasmorle...@googlemail.com:
I detected several other problematic files. :(
Next:
adding-a-figured-bass-above-or-below-the-notes.ly
The command \once \override Staff.BassFigureAlignmentPositioning
#'direction = #CENTER gives a log-warning (but worked in 2.12.3):
programming error: direction unknown, but aligned-side wanted
continuing, cross fingers
If noone objects I delete this command from the file.
Harm
Sorry, attached the wrong file.
\version 2.14.2
\header {
texidoc =
When writing a figured bass, you can place the figures above or below
the bass notes, by defining the @code{BassFigureAlignmentPositioning
#'direction} property (exclusively in a @code{Staff} context). Choices
are @code{#UP} (or @code{#1}), @code{#CENTER} (or @code{#0}) and
@code{#DOWN} (or @code{#-1}).
This property can be changed as many times as you wish. Use
@code{\\once \\override} if you don't want the override to apply to the
whole score.
doctitle = Adding a figured bass above or below the notes
}
bass = {
\clef bass
g4 b, c d
e d8 c d2
}
continuo = \figuremode {
_4 68
\once \override Staff.BassFigureAlignmentPositioning #'direction = #CENTER
5/8 _4
\bassFigureStaffAlignmentUp
_+ 4 6
\set Staff.useBassFigureExtenders = ##t
\bassFigureStaffAlignmentDown
44. 48 _+4
}
\score {
\new Staff = bassStaff \bass
\context Staff = bassStaff \continuo
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Phil, On Fri, Feb 24, 2012 at 7:45 AM, Phil Hézaine philippe.heza...@free.frwrote: If it could help, compile fine here on 2.15.22 with the number version added. Thanks for trying this out, but I believe you're running the version with the dummy Scheme lines I added. (I just tried it with 2.15.22 in its original form, and it doesn't work.) -David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Thomas Morley thomasmorle...@googlemail.com writes: Hi, 2012/2/19 Thomas Morley thomasmorle...@googlemail.com: use-custom-fonts-flat-b-and-sharp-#-symbols-for-chords.ly I simply added added lowercase? To the definition of my-chord-name-pop-markup Of course lowercase? Is of no use here. A better fix would be more invasive. I made some additions. Now \set chordNameLowercaseMinor = ##t and \set chordNoteNamer = #note-name-german-markup is possible. Shall I integrate it or use the simple fix? What are people's feelings about the rather bland compatibility fix of just catching a wrong-number-of-args error and try calling without that arg? Possibly lowercasing the result manually afterwards (if the flag is set), but that may not work with arbitrary markups. If we don't want to encourage a mixture of code styles flying around, we can still emit a warning. Of course, this snippet itself should be changed, but we could help with compatibility in that manner. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
David, Thank you for your detailed explanations earlier in this thread. On Fri, Feb 24, 2012 at 9:26 AM, David Kastrup d...@gnu.org wrote: #(newline) creates output. If you really want a filler of that sort, #(begin) is likely simplest. I've made this substitution and fixed the unnecessary macro definition. In my opinion, it makes sense to use the ugly dummy lines as they can be easily removed in versions where they aren't necessary. My goal here is simply to get the snippet working in 2.14.2 without being overly invasive. Thanks, David filtering-parts-from-the-command-line.ly Description: Binary data ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Le 25/02/2012 15:54, David Nalesnik a écrit : Thanks for trying this out, but I believe you're running the version with the dummy Scheme lines I added. (I just tried it with 2.15.22 in its original form, and it doesn't work.) -David Oh! You're right. I got all muddled up! Apologies for wasting your time. I simply wanted to say *your* file is compiling fine with 2.15.22 Phil. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
David Nalesnik david.nales...@gmail.com writes:
Hi,
On Thu, Feb 23, 2012 at 9:27 PM, David Kastrup d...@gnu.org wrote:
I think it was something like \lyricsto xxx \music
\musicfunction
... and it would likely already do to write \lyricsto xxx {
\music }
\musicfunction ...
I wasn't able to apply this to the snippet,
Sigh.
\lyricsto chorus \new Lyrics \txtChorus
\lyricsto verse \new Lyrics \txtVerseI
\ifTargetIn ...
Put the \txtChorus (for symmetry) and \txtVerseI into braces. Oh, and
while you are at this snippet: the define-macro at the start is
ridiculous. Maybe something to do with the module structure of 2.12.
Replace it with a define (and remove backquote and commata).
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
David, On Fri, Feb 24, 2012 at 12:44 AM, David Kastrup d...@gnu.org wrote: David Nalesnik david.nales...@gmail.com writes: I wasn't able to apply this to the snippet, Sigh. \lyricsto chorus \new Lyrics \txtChorus \lyricsto verse \new Lyrics \txtVerseI \ifTargetIn ... Sorry for being unclear: I did do what you suggested and it didn't fix the problem. Doing the replacements yields this string of errors: GNU LilyPond 2.14.2 Processing `filtering-parts-from-the-command-line.ly' Parsing... filtering-parts-from-the-command-line.ly:168:16: error: syntax error, unexpected SCM_TOKEN, expecting EXPECT_MARKUP or EXPECT_MUSIC or EXPECT_SCM or EXPECT_NO_MORE_ARGS \ifTargetIn #'(song) filtering-parts-from-the-command-line.ly:172:16: error: syntax error, unexpected SCM_TOKEN, expecting EXPECT_MARKUP or EXPECT_MUSIC or EXPECT_SCM or EXPECT_NO_MORE_ARGS \ifTargetIn #'(default) \new Staff filtering-parts-from-the-command-line.ly:173:20: error: syntax error, unexpected LYRICS_STRING, expecting EXPECT_MARKUP or EXPECT_MUSIC or EXPECT_SCM or EXPECT_NO_MORE_ARGS \global \clef bass (etc.) while you are at this snippet: the define-macro at the start is ridiculous. Maybe something to do with the module structure of 2.12. Replace it with a define (and remove backquote and commata). Thank you--I will do this. Best, David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
David Nalesnik david.nales...@gmail.com writes: David, On Fri, Feb 24, 2012 at 12:44 AM, David Kastrup d...@gnu.org wrote: David Nalesnik david.nales...@gmail.com writes: I wasn't able to apply this to the snippet, Sigh. \lyricsto chorus \new Lyrics \txtChorus \lyricsto verse \new Lyrics \txtVerseI \ifTargetIn ... Sorry for being unclear: I did do what you suggested and it didn't fix the problem. Doing the replacements yields this string of errors: GNU LilyPond 2.14.2 Processing `filtering-parts-from-the-command-line.ly' Parsing... filtering-parts-from-the-command-line.ly:168:16: error: syntax error, unexpected SCM_TOKEN, expecting EXPECT_MARKUP or EXPECT_MUSIC or EXPECT_SCM or EXPECT_NO_MORE_ARGS \ifTargetIn #'(song) The problem is caused because \new Lyrics switches modes by pushing on a lexer state stack and popping it when getting out again. Music functions in the lexer are converted into a MUSIC_FUNCTION token and a sequence of argument tokens pushed into a separate place, and then the lexer enters into extratoken state. The problem is that \new Lyrics pops its stack when the parser is sure that the lyrics have ended, and this is when it has seen the MUSIC_FUNCTION token. When it pops the lexer stack, consequently it pops the extratoken state instead of the lyrics state, and chaos ensues. I would have thought that enclosing the lyrics in braces was enough for the parser not to consider a lookahead token before deciding to pop the lyrics stack, but I probably overlooked something. Probably multiple \lyricsto are combined in some manner, so the lookahead token is needed to see whether there is another \lyricsto coming up. Ok, then my analysis was not good enough. One could enclose the whole \lyricsto construct in braces (from the outside), but then we are getting into the really ugly domain instead of the innocent modifications realm. Personally, I would aim for getting everything moved to 2.16. It seems somewhat pointless to do all the effort just to be lagging still a year behind, but of course that depends on the views of the LSR maintainer. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Le 24/02/2012 05:54, David Nalesnik a écrit :
Hi,
On Thu, Feb 23, 2012 at 9:27 PM, David Kastrupd...@gnu.org wrote:
I think it was something like \lyricsto xxx \music \musicfunction
... and it would likely already do to write \lyricsto xxx { \music }
\musicfunction ...
I wasn't able to apply this to the snippet, but I managed to make the
snippet compile with 2.14.2 by adding a #(newline) within each \score block
(see attached).
-David
If it could help, compile fine here on 2.15.22 with the number version
added.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Phil Hézaine philippe.heza...@free.fr writes:
Le 24/02/2012 05:54, David Nalesnik a écrit :
Hi,
On Thu, Feb 23, 2012 at 9:27 PM, David Kastrupd...@gnu.org wrote:
I think it was something like \lyricsto xxx \music \musicfunction
... and it would likely already do to write \lyricsto xxx { \music }
\musicfunction ...
I wasn't able to apply this to the snippet, but I managed to make the
snippet compile with 2.14.2 by adding a #(newline) within each \score block
(see attached).
-David
If it could help, compile fine here on 2.15.22 with the number version
added.
#(newline) creates output. If you really want a filler of that sort,
#(begin) is likely simplest.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi,
2012/2/19 Thomas Morley thomasmorle...@googlemail.com:
use-custom-fonts-flat-b-and-sharp-#-symbols-for-chords.ly
I simply added added lowercase? To the definition of
my-chord-name-pop-markup
Of course lowercase? Is of no use here. A better fix would be more invasive.
I made some additions. Now \set chordNameLowercaseMinor = ##t and \set
chordNoteNamer = #note-name-german-markup is possible.
Shall I integrate it or use the simple fix?
Cheers,
Harm
\version 2.14.0
% correct markup for b and # (use symbols from current font...)
chordFlat = \markup { \hspace #0.2 \fontsize #-1 \raise #0.3 b }
chordSharp = \markup { \hspace #0.1 \fontsize #-1 \raise #0.3 # }
% define custom chords
myPopChordsMusic =
{
c es ges bes-\markup { m \super { 7/ \chordFlat 5 } }
c e g bes dis'-\markup { \super { 7/ \chordSharp 9 } }
% ... define all other possible chords here...
}
% Add to existing exceptions
myPopChordsAdd = #(append (sequential-music-to-chord-exceptions myPopChordsMusic #t) ignatzekExceptions)
#(define (conditional-string-downcase str condition)
(if condition
(string-downcase str)
str))
% fix accidentals with some Scheme (using the current font's symbols)
#(define (my-chord-name-pop-markup pitch lowercase?)
(let* ((alt (ly:pitch-alteration pitch)))
(make-line-markup
(list
(make-simple-markup
(conditional-string-downcase
(vector-ref #(C D E F G A B) (ly:pitch-notename pitch))
lowercase?))
;; If it's natural, do nothing
(if (= alt 0)
(make-line-markup (list empty-markup))
(if (= alt FLAT)
;; Otherwise, handle adding the flat symbol
(make-line-markup
(list
(make-hspace-markup 0.3)
(make-small-markup (make-raise-markup 0.7
(make-text-markup b)
;; or handle adding the sharp symbol
(make-line-markup
(list
(make-hspace-markup 0.1)
(make-small-markup (make-raise-markup 0.7
(make-text-markup #)))
semiGermanChords = {
\set chordRootNamer = #(chord-name-german-markup #f)
\set chordNoteNamer = #note-name-german-markup
}
\new Score
{
\new ChordNames
{
% for demonstration purposes, use Arial as font
% this does not look very nice, but shows the functionality
\override ChordNames . ChordName #'font-name = #Arial
% use our new chord definitions (including the new accidentals)
\set chordNameExceptions = #myPopChordsAdd
% use our new markup chord naming functions to get the new accidentals
\set chordRootNamer = #my-chord-name-pop-markup
\chordmode { cis1:m7.5- s1*2 des1:7.9+ }
% in addition you may want to use some of these commands:
\set chordNameLowercaseMinor = ##t
\set chordNoteNamer = #note-name-german-markup
\chordmode { s1*2 cis1:m7.5-/b b:7/b s1*2 des1:7.9+ }
}
}
% % use like this:
%
% {
% popChords =
% {
% \set chordNameExceptions = #myPopChordsAdd
% \set chordRootNamer = #my-chord-name-pop-markup
% }
% }
%
% % or like this:
%
% \layout
% {
% \context
% {
% \Score
% chordNameExceptions = #myPopChordsAdd
% chordRootNamer = #my-chord-name-pop-markup
% }
% }
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi David N, David K, 2012/2/21 David Nalesnik david.nales...@gmail.com: David, On Tue, Feb 21, 2012 at 11:10 AM, David Kastrup d...@gnu.org wrote: Sorry for the unnecessary work caused by not thinking about this sufficiently from your point of view. And sorry for the it does not take a genius tone of my previous message that was uncalled for, stupid and offensive. Quite alright--I learned something valuable and I have a lot still to learn! (One of which is learning how to work with multiple versions resident on my computer, one of them being the very latest.) -David just back, I've read your discussion about converting. And I've to confess using the 2.14.2-convert-ly, too. To avoid such misunderstanding in the future I'll make a request about a doc addition to the CG on bug-lilypond. Thanks, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi David, 2012/2/21 David Kastrup d...@gnu.org: Thomas Morley thomasmorle...@googlemail.com writes: I didn't manage to fix: filtering-parts-from-the-command-line.ly You just did not try hard enough. It was a really obscure bug in the lexer. I'll commit a fix to staging once make check goes through. not sure I understand. Do you mean: Work harder and you'll have success.? If yes, ok, I'll do or try, at least. Or do you mean, that I've no realistic chance because of the lexer-bug? I think I need a beer. Only one? :) Thanks, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
On Thu, Feb 23, 2012 at 11:37:12PM +0100, Thomas Morley wrote: Hi David, 2012/2/21 David Kastrup d...@gnu.org: You just did not try hard enough. It was a really obscure bug in the lexer. I'll commit a fix to staging once make check goes through. not sure I understand. David's trying to be funny. He does this from time to time; it's a bit embarrassing, but just nod and smile. ^ | +-- by the way, the above was me trying to be funny. Nod and smile. Or do you mean, that I've no realistic chance because of the lexer-bug? It means that you had no chance due to that bug. David has fixed the bug, so stay tuned for 2.15.31 whenever it comes out. - Graham ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi Graham, 2012/2/24 Graham Percival gra...@percival-music.ca: On Thu, Feb 23, 2012 at 11:37:12PM +0100, Thomas Morley wrote: Hi David, 2012/2/21 David Kastrup d...@gnu.org: You just did not try hard enough. It was a really obscure bug in the lexer. I'll commit a fix to staging once make check goes through. not sure I understand. David's trying to be funny. He does this from time to time; it's a bit embarrassing, but just nod and smile. ^ | +-- by the way, the above was me trying to be funny. Nod and smile. lol Or do you mean, that I've no realistic chance because of the lexer-bug? It means that you had no chance due to that bug. David has fixed the bug, so stay tuned for 2.15.31 whenever it comes out. Well, I have to do some clean up, but apart from this last file the main work seems to be done, so far normal users can do. Or missed I something? Thanks, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi, It means that you had no chance due to that bug. David has fixed the bug, so stay tuned for 2.15.31 whenever it comes out. Possibly stupid question: does this mean that the LSR update will need to bypass 2.14.2 and wait for stable 2.16? -David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
David Nalesnik david.nales...@gmail.com writes:
Hi,
It means that you had no chance due to that bug. David has
fixed
the bug, so stay tuned for 2.15.31 whenever it comes out.
Possibly stupid question: does this mean that the LSR update will need
to bypass 2.14.2 and wait for stable 2.16?
I don't know when it was that the bug appeared. If it turns out that
this is a problem, it should be reasonably easy to rewrite the snippet
in a manner that does not trigger the bug.
I think it was something like \lyricsto xxx \music \musicfunction
... and it would likely already do to write \lyricsto xxx { \music }
\musicfunction ...
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Thomas Morley thomasmorle...@googlemail.com writes: Hi David, 2012/2/21 David Kastrup d...@gnu.org: Thomas Morley thomasmorle...@googlemail.com writes: I didn't manage to fix: filtering-parts-from-the-command-line.ly You just did not try hard enough. It was a really obscure bug in the lexer. I'll commit a fix to staging once make check goes through. not sure I understand. Do you mean: Work harder and you'll have success.? If yes, ok, I'll do or try, at least. Well, that _is_ the basic meaning, but the reward is so far removed from the start of the effort that this is more a joke than anything else. Or do you mean, that I've no realistic chance because of the lexer-bug? That would be hubris from me. I would have been surprised, but of course people have a realistic chance of surprising me. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi,
On Thu, Feb 23, 2012 at 9:27 PM, David Kastrup d...@gnu.org wrote:
I think it was something like \lyricsto xxx \music \musicfunction
... and it would likely already do to write \lyricsto xxx { \music }
\musicfunction ...
I wasn't able to apply this to the snippet, but I managed to make the
snippet compile with 2.14.2 by adding a #(newline) within each \score block
(see attached).
-David
filtering-parts-from-the-command-line.ly
Description: Binary data
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
David, On Mon, Feb 20, 2012 at 5:01 AM, David Kastrup d...@gnu.org wrote: Thomas Morley thomasmorle...@googlemail.com writes: 2012/2/19 David Kastrup d...@gnu.org: Furthermore, I realized, that there seems to be no conversion rule for the following 2.12.3-definitions: From 2.12.3: \scm\lily-library.scm (define (interval-translate iv amount) (cons (+ amount (car iv)) (+ amount (cdr iv It's used in snippets? Ugh. Probably easiest to put that back in and document it, then. Is there a known replacement? This function is found in 2.14.2 in \scm\lily-library.scm and could work: (define (cons-map f x) map F to contents of X (cons (f (car x)) (f (cdr x But any need for this or interval-translate is restricted to one line of the snippet, so maybe it would be better simply to expand that line? -David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
David Nalesnik david.nales...@gmail.com writes: David, On Mon, Feb 20, 2012 at 5:01 AM, David Kastrup d...@gnu.org wrote: Thomas Morley thomasmorle...@googlemail.com writes: 2012/2/19 David Kastrup d...@gnu.org: Furthermore, I realized, that there seems to be no conversion rule for the following 2.12.3-definitions: From 2.12.3: \scm\lily-library.scm (define (interval-translate iv amount) (cons (+ amount (car iv)) (+ amount (cdr iv It's used in snippets? Ugh. Probably easiest to put that back in and document it, then. Is there a known replacement? This function is found in 2.14.2 in \scm\lily-library.scm and could work: (define (cons-map f x) map F to contents of X (cons (f (car x)) (f (cdr x But any need for this or interval-translate is restricted to one line of the snippet, so maybe it would be better simply to expand that line? Uh, convertrules.py converts interval-translate to coord-translate so where is the actual problem? -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
David, On Tue, Feb 21, 2012 at 9:24 AM, David Kastrup d...@gnu.org wrote: Uh, convertrules.py converts interval-translate to coord-translate so where is the actual problem? Certainly coord-translate is the natural fix (thank you!), but when I run convert-ly and the snippet is updated to 2.14.0, this replacement isn't made. I looked and didn't find a rule for it in convertrules.py for 2.14.2. -David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
David Nalesnik david.nales...@gmail.com writes:
David,
On Tue, Feb 21, 2012 at 9:24 AM, David Kastrup d...@gnu.org wrote:
Uh, convertrules.py converts interval-translate to coord-translate
so
where is the actual problem?
Certainly coord-translate is the natural fix (thank you!), but when I
run convert-ly and the snippet is updated to 2.14.0, this replacement
isn't made. I looked and didn't find a rule for it in convertrules.py
for 2.14.2.
fc335d9e python/convertrules.py (Neil Puttock 2011-08-18 00:01:32 +0100
2953) @rule ((2, 13, 27),
fc335d9e python/convertrules.py (Neil Puttock 2011-08-18 00:01:32 +0100
2954)(interval-translate - coord-translate))
fc335d9e python/convertrules.py (Neil Puttock 2011-08-18 00:01:32 +0100
2955) def conv (str):
fc335d9e python/convertrules.py (Neil Puttock 2011-08-18 00:01:32 +0100
2956) str = re.sub ('interval-translate', 'coord-translate', str)
fc335d9e python/convertrules.py (Neil Puttock 2011-08-18 00:01:32 +0100
2957) return str
fc335d9e python/convertrules.py (Neil Puttock 2011-08-18 00:01:32 +0100
2958)
Apparently added as a rule in 2.15.9. Is there a reason you are not
using the _current_ convert-ly to do the conversion? It is not to be
expected that old versions do a better job than current versions at
converting old versions.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
David Kastrup d...@gnu.org writes:
David Nalesnik david.nales...@gmail.com writes:
David,
On Tue, Feb 21, 2012 at 9:24 AM, David Kastrup d...@gnu.org wrote:
Uh, convertrules.py converts interval-translate to coord-translate
so
where is the actual problem?
Certainly coord-translate is the natural fix (thank you!), but when I
run convert-ly and the snippet is updated to 2.14.0, this replacement
isn't made. I looked and didn't find a rule for it in convertrules.py
for 2.14.2.
fc335d9e python/convertrules.py (Neil Puttock 2011-08-18 00:01:32
+0100 2953) @rule ((2, 13, 27),
fc335d9e python/convertrules.py (Neil Puttock 2011-08-18 00:01:32
+0100 2954) (interval-translate - coord-translate))
fc335d9e python/convertrules.py (Neil Puttock 2011-08-18 00:01:32
+0100 2955) def conv (str):
fc335d9e python/convertrules.py (Neil Puttock 2011-08-18 00:01:32
+0100 2956) str = re.sub ('interval-translate', 'coord-translate',
str)
fc335d9e python/convertrules.py (Neil Puttock 2011-08-18 00:01:32
+0100 2957) return str
fc335d9e python/convertrules.py (Neil Puttock 2011-08-18 00:01:32
+0100 2958)
Apparently added as a rule in 2.15.9. Is there a reason you are not
using the _current_ convert-ly to do the conversion? It is not to be
expected that old versions do a better job than current versions at
converting old versions.
I mean, we are talking about _improving_ the convert-ly rules such that
they will presumably work for upgrading 2.12.
Of course, that is utterly pointless if you are using the 2.14.2
convert-ly for conversion. If you are not going to use the newest
convert-ly, any fixes that are made to convert-ly will be totally
useless.
So please check with the _current_ convert-ly. It has an option
-t, --to=VERSION convert to VERSION [default: 2.15.31]
for telling it at which version to stop. You don't need to let it run
all through to 2.15.31.
And conversions that fail with _that_ convert-ly are worth further
investigation.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Thomas Morley thomasmorle...@googlemail.com writes:
Hi David,
2012/2/20 David Kastrup d...@gnu.org:
Thomas Morley thomasmorle...@googlemail.com writes:
Hi David, Phil,
I'll be offline for two days, perhaps three. (Visiting a funeral, ~800
km away from my home)
May I ask you to continue the updating work?
I'm just going to take a look at the snippet you analyzed.
Ok, I am now rather annoyed. I was totally sure that somebody mentioned
\put-adjacent in the context of convertrules, and now doing a web search
I find that it was merely used as an example for localized messages and
nobody had a problem with it not doing any conversion.
It is a 2.11.55 rule. Now I fixed the conversion. Suggestions what I
am going to do with it? Bother with checking it in? Anybody with a
test case?
diff --git a/python/convertrules.py b/python/convertrules.py
index 3ed1d18..5541fec 100644
--- a/python/convertrules.py
+++ b/python/convertrules.py
@@ -45,6 +45,32 @@ def rule (version, message):
conversions.append ((version, f, message))
return dec
+# various helper functions creating regexps
+
+def paren_matcher (n):
+# poor man's matched paren scanning, gives up
+# after n+1 levels. Matches any string with balanced
+# parens inside; add the outer parens yourself if needed.
+# Nongreedy.
+return r[^()]*?(?:\(*n+r[^()]*?+r\)[^()]*?)*?*n
+return
+
+def brace_matcher (n):
+# poor man's matched brace scanning, gives up
+# after n+1 levels. Matches any string with balanced
+# braces inside; add the outer braces yourself if needed.
+# Nongreedy.
+return r[^{}]*?(?:{*n+r[^{}]*?+r}[^{}]*?)*?*n
+
+matchstring = r'(?:[^\\]|\\.)*'
+matcharg = (r\s+(?:[$#]['`]?\s*(?:[a-zA-Z]\S*| + matchstring + r|\(
++ paren_matcher(20) + r\))| + matchstring + r|\\[a-z_A-Z]+))
+matchmarkup = (r'(?:\\markup\s*(?:{' + brace_matcher (20) +r'}|' +
+ matchstring + r'|(?:\\[a-z_A-Z][a-z_A-Z-]*(?:' + matcharg +
+ r')*?\s*)*(?:' + matchstring + |{ + brace_matcher (20) +
+ }))| + matchstring + ))
+
+
@rule ((0, 1, 9), _ ('\\header { key = concat + with + operator }'))
def conv(str):
@@ -2747,11 +2773,8 @@ def conv (str):
\\put-adjacent markup axis dir markup - \\put-adjacent axis dir markup markup)
def conv (str):
str = re.sub (r#\(set-octavation (-*[0-9]+)\), r\\ottava #\1, str)
-if re.search ('put-adjacent', str):
-stderr_write (NOT_SMART % _ (\\put-adjacent argument order))
-stderr_write (_ (Axis and direction now come before markups:\n))
-stderr_write (_ (\\put-adjacent axis dir markup markup.))
-stderr_write (\n)
+str = re.sub (r\\put-adjacent( + matchmarkup + )( + matcharg*2 + ),
+ r\\put-adjacent\2\1, str)
return str
@rule ((2, 11, 57), \\center-align - \\center-column, \\hcenter - \\center-align)
@@ -3211,14 +3234,6 @@ def conv (str):
stderr_write (UPDATE_MANUALLY)
return str
-def paren_matcher (n):
-# poor man's matched paren scanning, gives up
-# after n+1 levels. Matches any string with balanced
-# parens inside; add the outer parens yourself if needed.
-# Nongreedy.
-return r[^()]*?(?:\(*n+r[^()]*?+r\)[^()]*?)*?*n
-return
-
def undollar_scm (m):
return re.sub (r\$(.?), r\1, m.group (0))
@@ -3289,21 +3304,6 @@ def conv (str):
r\1\\accidentalStyle, str)
return str
-def brace_matcher (n):
-# poor man's matched brace scanning, gives up
-# after n+1 levels. Matches any string with balanced
-# braces inside; add the outer braces yourself if needed.
-# Nongreedy.
-return r[^{}]*?(?:{*n+r[^{}]*?+r}[^{}]*?)*?*n
-
-matchstring = r'(?:[^\\]|\\.)*'
-matcharg = (r\s+(?:[$#]['`]?\s*(?:[a-zA-Z]\S*| + matchstring + r|\(
-+ paren_matcher(20) + r\))| + matchstring + r|\\[a-z_A-Z]+))
-matchmarkup = (r'(?:\\markup\s*(?:{' + brace_matcher (20) +r'}|' +
- matchstring + r'|(?:\\[a-z_A-Z][a-z_A-Z-]*(?:' + matcharg +
- r')*?\s*)*(?:' + matchstring + |{ + brace_matcher (20) +
- }))| + matchstring + ))
-
@rule((2, 15, 25), r\(auto)?Footnote(Grob)? - \footnote)
def conv (str):
# The following replacement includes the final markup argument in
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
David,
On Tue, Feb 21, 2012 at 10:37 AM, David Kastrup d...@gnu.org wrote:
David Kastrup d...@gnu.org writes:
David Nalesnik david.nales...@gmail.com writes:
David,
On Tue, Feb 21, 2012 at 9:24 AM, David Kastrup d...@gnu.org wrote:
Uh, convertrules.py converts interval-translate to coord-translate
so
where is the actual problem?
Certainly coord-translate is the natural fix (thank you!), but when I
run convert-ly and the snippet is updated to 2.14.0, this replacement
isn't made. I looked and didn't find a rule for it in convertrules.py
for 2.14.2.
fc335d9e python/convertrules.py (Neil Puttock 2011-08-18 00:01:32
+0100 2953) @rule ((2, 13, 27),
fc335d9e python/convertrules.py (Neil Puttock 2011-08-18 00:01:32
+0100 2954) (interval-translate - coord-translate))
fc335d9e python/convertrules.py (Neil Puttock 2011-08-18 00:01:32
+0100 2955) def conv (str):
fc335d9e python/convertrules.py (Neil Puttock 2011-08-18 00:01:32
+0100 2956) str = re.sub ('interval-translate', 'coord-translate',
str)
fc335d9e python/convertrules.py (Neil Puttock 2011-08-18 00:01:32
+0100 2957) return str
fc335d9e python/convertrules.py (Neil Puttock 2011-08-18 00:01:32
+0100 2958)
Apparently added as a rule in 2.15.9. Is there a reason you are not
using the _current_ convert-ly to do the conversion? It is not to be
expected that old versions do a better job than current versions at
converting old versions.
I mean, we are talking about _improving_ the convert-ly rules such that
they will presumably work for upgrading 2.12.
Of course, that is utterly pointless if you are using the 2.14.2
convert-ly for conversion. If you are not going to use the newest
convert-ly, any fixes that are made to convert-ly will be totally
useless.
So please check with the _current_ convert-ly. It has an option
-t, --to=VERSION convert to VERSION [default: 2.15.31]
for telling it at which version to stop. You don't need to let it run
all through to 2.15.31.
And conversions that fail with _that_ convert-ly are worth further
investigation.
--
David Kastrup
Thank you very much for this information--I didn't know about this option.
-David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
David Nalesnik david.nales...@gmail.com writes: On Tue, Feb 21, 2012 at 10:37 AM, David Kastrup d...@gnu.org wrote: So please check with the _current_ convert-ly. It has an option -t, --to=VERSION convert to VERSION [default: 2.15.31] for telling it at which version to stop. You don't need to let it run all through to 2.15.31. Any conversions that fail with _that_ convert-ly are worth further investigation. Thank you very much for this information--I didn't know about this option. Sorry for the unnecessary work caused by not thinking about this sufficiently from your point of view. And sorry for the it does not take a genius tone of my previous message that was uncalled for, stupid and offensive. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
David, On Tue, Feb 21, 2012 at 11:10 AM, David Kastrup d...@gnu.org wrote: Sorry for the unnecessary work caused by not thinking about this sufficiently from your point of view. And sorry for the it does not take a genius tone of my previous message that was uncalled for, stupid and offensive. Quite alright--I learned something valuable and I have a lot still to learn! (One of which is learning how to work with multiple versions resident on my computer, one of them being the very latest.) -David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Thomas Morley thomasmorle...@googlemail.com writes: I didn't manage to fix: filtering-parts-from-the-command-line.ly You just did not try hard enough. It was a really obscure bug in the lexer. I'll commit a fix to staging once make check goes through. I think I need a beer. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi David, Phil,
2012/2/20 David Nalesnik david.nales...@gmail.com:
Hi again,
On Sun, Feb 19, 2012 at 9:03 PM, David Nalesnik david.nales...@gmail.com
wrote:
Hi Harm,
On Sun, Feb 19, 2012 at 11:51 AM, Thomas Morley
thomasmorle...@googlemail.com wrote:
I didn't manage to fix:
mixed-meter---automatic-compound-time-signatures.ly
A little more exploring led me to \compoundMeter...
This snippet shouldn't be necessary anymore.
It can be replaced with:
{
%\compoundMeter #'((3 2 2 3 8)) ;; numerators over a single denominator
\compoundMeter #'((3 8) (2 8) (2 8) (3 8)) ;; each numerator with its own
denominator, as in the snippet
\repeat unfold 10 c'8 \repeat unfold 20 c'16
}
-David
many thanks for your work on the mixed-meter-file.
I had a look at complex-compound-time-signatures.ly ( =
http://lsr.dsi.unimi.it/LSR/Item?id=743 ) and I'd agree:
mixed-meter---automatic-compound-time-signatures.ly should be deleted.
Sorry for not comparing them before.
Now we have an updated
mixed-meter---automatic-compound-time-signatures.ly and we realized
that it could be deleted.
Phil: What to do with this file and the other deleting candidates
mentioned by Carl?
So, only one file left: filtering-parts-from-the-command-line.ly
Thanks,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Thomas Morley thomasmorle...@googlemail.com writes: 2012/2/19 David Kastrup d...@gnu.org: So if it is not too much work to collect triplets of version #, before, after convert-ly, after correct change, it might be a nice base for looking how to improve the convertrules file. as an example I use: overriding-automatic-beam-settings.ly I atached the original-file, the after-convert-ly-file and the manual upgraded file. I'll take a look. Furthermore, I realized, that there seems to be no conversion rule for the following 2.12.3-definitions: From 2.12.3: \scm\lily-library.scm (define (interval-translate iv amount) (cons (+ amount (car iv)) (+ amount (cdr iv It's used in snippets? Ugh. Probably easiest to put that back in and document it, then. Is there a known replacement? From 2.12.3: \ly\markup-init.ly #(define-public toplevel-module-define-public! #f) #(define-public toplevel-module-ref #f) Those can be replaced by their straightforward counterpart. Where are they used? And of course any 2.14.2-chordRootNamer-definition expects two arguments now. I've no idea how that could be covered by converting rules. Give a before/after example. It might be more reliable to actually just let the function deal with it via an optional argument, but it is not inconceivable to write conversion rules either. If you take a look at convertrules.py, you'll see that I did some rather heavy lifting inside of Scheme constructs for dealing with ly:export. It is not the same as doing compatibility in Scheme itself, but it was sufficient for the LilyPond repository. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi David,
2012/2/20 David Kastrup d...@gnu.org:
Furthermore, I realized, that there seems to be no conversion rule for
the following 2.12.3-definitions:
From 2.12.3: \scm\lily-library.scm
(define (interval-translate iv amount)
(cons (+ amount (car iv))
(+ amount (cdr iv
It's used in snippets? Ugh.
http://lsr.dsi.unimi.it/LSR/Item?id=700 by Neil Puttock
Probably easiest to put that back in and
document it, then.
I reintegrated the interval-translate-definition into the file
-attached my manual update
Is there a known replacement?
Don't know.
From 2.12.3: \ly\markup-init.ly
#(define-public toplevel-module-define-public! #f)
#(define-public toplevel-module-ref #f)
Those can be replaced by their straightforward counterpart. Where are
they used?
http://lsr.dsi.unimi.it/LSR/Item?id=657
I reintegrated the old definitions, too. -attached my manual update
I don't know about their counterpart.
And of course any 2.14.2-chordRootNamer-definition expects two
arguments now. I've no idea how that could be covered by converting
rules.
Give a before/after example. It might be more reliable to actually just
let the function deal with it via an optional argument,
In http://lsr.dsi.unimi.it/LSR/Search?q=chordRootNamer I simple added
the non-functional argument lowercase? to the definition. - attached
my manual update
Or should I try to competely rewrite this snippet due to the new possibillities?
but it is not
inconceivable to write conversion rules either. If you take a look at
convertrules.py, you'll see that I did some rather heavy lifting inside
of Scheme constructs for dealing with ly:export. It is not the same as
doing compatibility in Scheme itself, but it was sufficient for the
LilyPond repository.
Will have a look at it.
Cheers,
Harm
\version 2.14.0
\header {
texidoc =
Staff lines can be colored independently by overriding the default
stencil for @code{StaffSymbol}.
The @code{StaffSymbol} callback @code{color-staff-lines} takes a set of
colors (using LilyPond's predefined colors or the functions
@code{x11-color} and @code{rgb-color}) which are applied to each staff
line in turn starting with the fifth line (for a standard staff), or
each item in the list for custom staves defined with
@code{line-positions}. To signal that a particular line between
colored lines should remain black, use @code{#f}.
doctitle = Coloring individual staff lines
}
%LSR This snippet was contributed by Neil Puttock
#(define-public ((color-staff-lines . rest) grob)
(define (index-cell cell dir)
(if (equal? dir RIGHT)
(cdr cell)
(car cell)))
(define (index-set-cell! x dir val)
(case dir
((-1) (set-car! x val))
((1) (set-cdr! x val
Definition added!
(define (interval-translate iv amount)
(cons (+ amount (car iv))
(+ amount (cdr iv
(let* ((common (ly:grob-system grob))
(span-points '(0 . 0))
(thickness (* (ly:grob-property grob 'thickness 1.0)
(ly:output-def-lookup (ly:grob-layout grob) 'line-thickness)))
(width (ly:grob-property grob 'width))
(line-positions (ly:grob-property grob 'line-positions))
(staff-space (ly:grob-property grob 'staff-space 1))
(line-stencil #f)
(total-lines empty-stencil)
;; use a local copy of colors list, since
;; stencil creation mutates list
(colors rest))
(for-each
(lambda (dir)
(if (and (= dir RIGHT)
(number? width))
(set-cdr! span-points width)
(let* ((bound (ly:spanner-bound grob dir))
(bound-ext (ly:grob-extent bound bound X)))
(index-set-cell! span-points dir
(ly:grob-relative-coordinate bound common X))
(if (and (not (ly:item-break-dir bound))
(not (interval-empty? bound-ext)))
(index-set-cell! span-points dir
(+ (index-cell span-points dir)
(index-cell bound-ext dir))
(index-set-cell! span-points dir (- (index-cell span-points dir)
(* dir thickness 0.5
(list LEFT RIGHT))
(set! span-points
(interval-translate span-points
(- (ly:grob-relative-coordinate grob common X
(set! line-stencil
(make-line-stencil thickness (car span-points) 0 (cdr span-points) 0))
(if (pair? line-positions)
(for-each (lambda (position)
(let ((color (if (pair? colors)
(car colors)
#f)))
(set! total-lines
(ly:stencil-add
total-lines
Re: LSR updates: was: polychords: a working solution
- Original Message - From: Thomas Morley thomasmorle...@googlemail.com Phil: What to do with this file and the other deleting candidates mentioned by Carl? Keep a record of it and we'll get rid of it as part of the upgrade. -- Phil Holmes ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi David, Phil, I'll be offline for two days, perhaps three. (Visiting a funeral, ~800 km away from my home) May I ask you to continue the updating work? Best, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Thomas Morley thomasmorle...@googlemail.com writes: Hi David, Phil, I'll be offline for two days, perhaps three. (Visiting a funeral, ~800 km away from my home) May I ask you to continue the updating work? I'm just going to take a look at the snippet you analyzed. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi Harm, On Mon, Feb 20, 2012 at 2:25 PM, Thomas Morley thomasmorle...@googlemail.com wrote: I'll be offline for two days, perhaps three. (Visiting a funeral, ~800 km away from my home) May I ask you to continue the updating work? Sure, I'll be happy to do what I can. I can certainly look through what you've done with the corrected snippets. Thank you so much for what you've done!! -David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi David, 2012/2/20 David Kastrup d...@gnu.org: Thomas Morley thomasmorle...@googlemail.com writes: Hi David, Phil, I'll be offline for two days, perhaps three. (Visiting a funeral, ~800 km away from my home) May I ask you to continue the updating work? I'm just going to take a look at the snippet you analyzed. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user Thanks! Best, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi David, 2012/2/20 David Nalesnik david.nales...@gmail.com: Hi Harm, On Mon, Feb 20, 2012 at 2:25 PM, Thomas Morley thomasmorle...@googlemail.com wrote: I'll be offline for two days, perhaps three. (Visiting a funeral, ~800 km away from my home) May I ask you to continue the updating work? Sure, I'll be happy to do what I can. I can certainly look through what you've done with the corrected snippets. Thanks! There is one file without update remaining: filtering-parts-from-the-command-line.ly ( = http://lsr.dsi.unimi.it/LSR/Search?q=filtering+parts+from+the+command+line ) Would be nice every user interested in updating LSR could work on this. Best, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Apologies for top-posting - I'm having problems with the way my Windows machine is quoting text. Also apologies, Thomas, for the late reply, and pointing you to a page yesterday that you'd already read! It was getting past my bedtime and I wasn't reading too accurately. It looks like what you've done is exactly right for preparing for updating the LSR. I think you have 2 options: 1) wait until we know that the LSR will be moved to 2.14 before doing anything else; or 2) correct the syntax of the files you know have errors ready for that move. Which you do is up to you - bear in mind that if you go for 2), then it's possible that the work will be wasted if we struggle to get the LSR updated. However, you will at least be prepared. A few other comments to let you understand the LSR as well as I do - which isn't huge. It's used for 2 things, really - the online searchable index, and also to create snippets that can be put in the documents. These are tagged with docs in the LSR and are then included in the documentation package by copying them over and running makeLSR on them. That's where the snippets in the URL you showed from Savannah come from - they're a subset of the full LSR. When one of the docs snippets is known not to work on the latest development version, a working version is created in snippets/new, and this is used in the build system in preference to the original. This is therefore a further indication of which snippets won't work, although only of the ones tagged 'docs' HTH Phil Holmes - Original Message - From: Thomas Morley thomasmorle...@googlemail.com To: Phil Holmes m...@philholmes.net Cc: Graham Percival gra...@percival-music.ca; lilypond-user@gnu.org Sent: Saturday, February 18, 2012 9:09 PM Subject: Re: polychords: a working solution Hi Phil, 2012/2/18 Phil Holmes m...@philholmes.net: I'd approach this from a different direction. First of all - have a look at http://lilypond.org/doc/v2.15/Documentation/contributor/updating-lsr-to-a-new-version I read it before and now again. But please hold in mind, that I'm a newbie with this kind of task. It might happen that I don't understand something or even worse misunderstand. As it stands now, I believe the files we know won't work under the current development version are in Documentation/snippets/new: when makeLSR is run, these over-write the snippets downloaded from the LSR. Do youn mean the files from http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=tree;f=Documentation/snippets/new;h=5fc4874511a90a821ab3ee0f5eecf13efdd82b77;hb=HEAD ? I think it would be worth you comparing your results with the files in /new. Summary: I filtered the following (not compiling) files from LSR with: grep failed *.txt altering-the-number-of-stems-in-a-beam.ly automatic-beams-two-per-two-in-4-4-or-2-2-time-signature.ly beam-endings-in-score-context.ly beam-grouping-in-7-8-time.ly compound-time-signatures.ly conducting-signs,-measure-grouping-signs.ly filtering-parts-from-the-command-line.ly grouping-beats.ly how-to-define-autobeamsettings-in-the—layout-block.ly including-a-file-only-once.ly overriding-automatic-beam-settings.ly reverting-default-beam-endings.ly specifying-context-with-beatgrouping.ly template-for-multiple-instruments,-prints-a-score-and-parts.ly I filtered the following (not compiling) files from LSR with: grep ERROR *txt coloring-individual-staff-lines.ly defining-predefined-fretboards-for-other-instruments.ly letter-tablature-formatting.ly mixed-meter---automatic-compound-time-signatures.ly obtaining-a-tablature-for-open-tuning-and-or-normal-tuning.ly positioning-tuplet-numbers-close-to-kneed-beams.ly use-custom-fonts-flat-b-and-sharp-#-symbols-for-chords.ly In / Documentation / snippets / new / I found: beam-endings-in-score-context.ly beam-grouping-in-7-8-time.ly compound-time-signatures.ly conducting-signs,-measure-grouping-signs.ly grouping-beats.ly reverting-default-beam-endings.ly defining-predefined-fretboards-for-other-instruments.ly letter-tablature-formatting.ly Not in / Documentation / snippets / new / are: altering-the-number-of-stems-in-a-beam.ly automatic-beams-two-per-two-in-4-4-or-2-2-time-signature.ly filtering-parts-from-the-command-line.ly how-to-define-autobeamsettings-in-the—layout-block.ly including-a-file-only-once.ly overriding-automatic-beam-settings.ly specifying-context-with-beatgrouping.ly template-for-multiple-instruments,-prints-a-score-and-parts.ly coloring-individual-staff-lines.ly mixed-meter---automatic-compound-time-signatures.ly obtaining-a-tablature-for-open-tuning-and-or-normal-tuning.ly positioning-tuplet-numbers-close-to-kneed-beams.ly use-custom-fonts-flat-b-and-sharp-#-symbols-for-chords.ly Hope that I overlooked nothing. Am I right that only these files need manual upgrade? Thanks for your enthusiasm - I'll definitely be asking for your help, but I think the first task is to get agreement to upgrade the
Re: LSR updates: was: polychords: a working solution
Hi Harm, On Sun, Feb 19, 2012 at 8:32 AM, Phil Holmes m...@philholmes.net wrote: 2) correct the syntax of the files you know have errors ready for that move. Which you do is up to you - bear in mind that if you go for 2), then it's possible that the work will be wasted if we struggle to get the LSR updated. However, you will at least be prepared. If you'd like to go the route of updating syntax in the problem files to 2.14, then I'll be happy to take on part of the task. Just let me know! -David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
I first suggested to put the column code because I think it would be probably useful. The polychord snippets would need a little more work, as I advance in the theory class, i'll know which cases are pertinent to add, but still it could be a good example. I didn't realized there were two places you could find examples. I noticed that there were duplicates in the LSR, and there may be snippets that still works but can now be done easier with new lillypond functionalities. What about archiving somewhere the LSR for the old versions (could be without graphic) for people staying on older versions? Or maybe we could keep examples that fail to upgrade and let users (like me) correct them when then fall upon them (to the risk that LSR could be populated with a growing pile of non working on last version snippets). The LSR in my opinion is better alive than perfect :). In the short term: what about updating the LSR directly to 2.16 which is to be released soon (well, you never know :) ) ? Jean-Alexis ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi David,
2012/2/19 David Nalesnik david.nales...@gmail.com:
Hi Harm,
On Sun, Feb 19, 2012 at 8:32 AM, Phil Holmes m...@philholmes.net wrote:
2) correct the syntax of the files you know have errors ready for that
move. Which you do is up to you - bear in mind that if you go for 2), then
it's possible that the work will be wasted if we struggle to get the LSR
updated. However, you will at least be prepared.
If you'd like to go the route of updating syntax in the problem files to
2.14, then I'll be happy to take on part of the task. Just let me know!
-David
I fixed already following files:
Altering-the-number-of-stems-in-a-beam.ly
I changed the old override-auto-beam-setting.
automatic-beams-two-per-two-in-4-4-or-2-2-time-signature.ly
I changed the old override-auto-beam-setting.
coloring-individual-staff-lines.ly
I added the definition for interval-translate from 2.12.3
Better use an other fix?
how-to-define-autobeamsettings-in-the—layout-block.ly
I changed the autoBeamSettings.
Including-a-file-only-once.ly
I reimplemented the relevant definitions from 2.12.3
Better use an other fix?
Obtaining-a-tablature-for-open-tuning-and-or-normal-tuning.ly
I replaced the number-lists with pitches-lists.
Better implementation with makeStringTuning?
TODO handle the log-warning: warning: no such internal option: open-tuning
TODO change the description
overriding-automatic-beam-settings.ly
I changed the old override-auto-beam-setting and a comment.
Positioning-tuplet-numbers-close-to-kneed-beams.ly
I changed 'thickness to 'beam-thickness as the author suggested (line 64).
specifying-context-with-beatgrouping.ly
I changed beatGrouping to beatStructure
Suggestion: New Title: doctitle = Specifying context with beatStructure
template-for-multiple-instruments,-prints-a-score-and-parts.ly
I changed the old override-auto-beam-setting.
use-custom-fonts-flat-b-and-sharp-#-symbols-for-chords.ly
I simply added added lowercase? To the definition of my-chord-name-pop-markup
Of course lowercase? Is of no use here. A better fix would be more invasive.
I didn't manage to fix:
filtering-parts-from-the-command-line.ly
mixed-meter---automatic-compound-time-signatures.ly
May I ask you and any other interested user for review and perhaps
ideas for the remaining files?
Thanks,
Harm
fixed-lsr-snippets.tar.gz
Description: GNU Zip compressed data
\version 2.14.0
\header {
texidoc =
This snippet defines a function, mixedMeter, that can be used to make
subdivided time signatures. It automatically sets the measure length
and beam grouping correctly. For now, the implementation is really
ugly. Hopefully somebody can clean up.
If the function is saved in mixed-meter.ly then the given example would
be entered as
\\include \mixed-meter.ly\ @{
\\mixedMeter #'(3 2 2 3 8)
\\repeat unfold 10 c'8 \\repeat unfold 20 c'16 @}
doctitle = Mixed Meter - automatic compound time signatures
}
#(ly:load markup.scm)
#(define (compound-time . args)
(let* ((revargs (reverse args))
(num (car revargs))
(dens (reverse (cdr revargs
(make-override-markup
'(baseline-skip . 0)
(make-number-markup
(make-line-markup
(cons
(make-column-markup (list (car dens) num))
(map (lambda (den)
(make-line-markup (list
(make-vcenter-markup +)
(make-column-markup (list den num)
(cdr dens
#(define (sum-list lst) (if (pair? lst)
(+ (car lst) (sum-list (cdr lst)))
0))
#(ly:load auto-beam.scm)
#(define (make-auto-beam-setting setting num den . rest)
(context-spec-music
(make-apply-context (lambda (c)
(override-property-setting
c 'autoBeamSettings
setting (ly:make-moment num den
(if (and (pair? rest) (symbol? (car rest)))
(car rest)
'Voice)))
mixedMeter =
#(define-music-function (parser location args) (pair?)
#{
#(let* ((revargs (reverse $args))
(num (car revargs))
(dens (reverse (cdr revargs
(letrec ((make-auto-beam-settings (lambda (lst accum)
(if (pair? lst)
(begin
(cons
(make-auto-beam-setting `(end * * ,(sum-list dens) ,num) accum num)
(make-auto-beam-settings (cdr lst) (+ accum (car lst)
'()
(ly:export (make-music
'SequentialMusic
'elements
(make-auto-beam-settings (cdr dens) (car dens))
\override Staff.TimeSignature #'stencil = #ly:text-interface::print
\override Staff.TimeSignature #'text = #(apply compound-time (map number-string $args))
\set Staff.beatGrouping = #(reverse (cdr (reverse $args)))
\set Timing.measureLength = #(ly:make-moment (sum-list (cdr (reverse $args))) (car (reverse $args)))
\set Timing.beatLength = #(ly:make-moment 1 (car (reverse $args)))
#} )
%%% CUT HERE!
{
\mixedMeter #'(3 2 2 3 8)
\repeat unfold 10 c'8 \repeat unfold 20 c'16
}
\version 2.14.0
\header {
texidoc =
If you need to create scores for different audiences from the same
sources you need to filter
Re: LSR updates: was: polychords: a working solution
Thomas Morley thomasmorle...@googlemail.com writes: Hi David, 2012/2/19 David Nalesnik david.nales...@gmail.com: Hi Harm, On Sun, Feb 19, 2012 at 8:32 AM, Phil Holmes m...@philholmes.net wrote: 2) correct the syntax of the files you know have errors ready for that move. Which you do is up to you - bear in mind that if you go for 2), then it's possible that the work will be wasted if we struggle to get the LSR updated. However, you will at least be prepared. If you'd like to go the route of updating syntax in the problem files to 2.14, then I'll be happy to take on part of the task. Just let me know! -David I fixed already following files: Altering-the-number-of-stems-in-a-beam.ly I changed the old override-auto-beam-setting. automatic-beams-two-per-two-in-4-4-or-2-2-time-signature.ly I changed the old override-auto-beam-setting. coloring-individual-staff-lines.ly I added the definition for interval-translate from 2.12.3 Better use an other fix? [...] Did you try using convert-ly? If it works, the fix is likely somewhat related to the right behavior according to whoever wrote the convertrules. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi Phil, 2012/2/19 Phil Holmes m...@philholmes.net: It looks like what you've done is exactly right for preparing for updating the LSR. I think you have 2 options: 1) wait until we know that the LSR will be moved to 2.14 before doing anything else; or 2) correct the syntax of the files you know have errors ready for that move. Which you do is up to you - bear in mind that if you go for 2), then it's possible that the work will be wasted if we struggle to get the LSR updated. However, you will at least be prepared. I started with 2) A few other comments to let you understand the LSR as well as I do - which isn't huge. It's used for 2 things, really - the online searchable index, and also to create snippets that can be put in the documents. These are tagged with docs in the LSR and are then included in the documentation package by copying them over and running makeLSR on them. That's where the snippets in the URL you showed from Savannah come from - they're a subset of the full LSR. When one of the docs snippets is known not to work on the latest development version, a working version is created in snippets/new, and this is used in the build system in preference to the original. This is therefore a further indication of which snippets won't work, although only of the ones tagged 'docs' Thanks for clarification. More questions. :) In the LSR-download I found several sub-directories like: all ancient-notation automatic-notation etc I only worked on the files from all. Correct? Or should I have a look in the other directories? Once the files are fixed completely, what to do with them? Cheers, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi David, 2012/2/19 David Kastrup d...@gnu.org: Thomas Morley thomasmorle...@googlemail.com writes: Hi David, 2012/2/19 David Nalesnik david.nales...@gmail.com: Hi Harm, On Sun, Feb 19, 2012 at 8:32 AM, Phil Holmes m...@philholmes.net wrote: 2) correct the syntax of the files you know have errors ready for that move. Which you do is up to you - bear in mind that if you go for 2), then it's possible that the work will be wasted if we struggle to get the LSR updated. However, you will at least be prepared. If you'd like to go the route of updating syntax in the problem files to 2.14, then I'll be happy to take on part of the task. Just let me know! -David I fixed already following files: Altering-the-number-of-stems-in-a-beam.ly I changed the old override-auto-beam-setting. automatic-beams-two-per-two-in-4-4-or-2-2-time-signature.ly I changed the old override-auto-beam-setting. coloring-individual-staff-lines.ly I added the definition for interval-translate from 2.12.3 Better use an other fix? [...] Did you try using convert-ly? yes. But without complete success in the mentioned files. Cheers, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Thomas Morley thomasmorle...@googlemail.com writes: 2012/2/19 David Kastrup d...@gnu.org: Did you try using convert-ly? yes. But without complete success in the mentioned files. It may also be an idea to use this as input for improving the convert-ly rules. After all, they will presumably get exercised a lot more when the next stable version gets out and/or the LSR moves on. So if it is not too much work to collect triplets of version #, before, after convert-ly, after correct change, it might be a nice base for looking how to improve the convertrules file. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
On Sun, Feb 19, 2012 at 07:27:31PM +0100, David Kastrup wrote: So if it is not too much work to collect triplets of version #, before, after convert-ly, after correct change, it might be a nice base for looking how to improve the convertrules file. David, are you volunteering to produce patches for convert-ly? If not, let's not ask Thomas to do something which would be useless. Other than possibly yourself, there is no appetite for spending energy on convert-ly. There's no point collecting bug reports about it. - Graham ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Graham Percival gra...@percival-music.ca writes: On Sun, Feb 19, 2012 at 07:27:31PM +0100, David Kastrup wrote: So if it is not too much work to collect triplets of version #, before, after convert-ly, after correct change, it might be a nice base for looking how to improve the convertrules file. David, are you volunteering to produce patches for convert-ly? If they are reasonably simple to do. If not, let's not ask Thomas to do something which would be useless. Other than possibly yourself, there is no appetite for spending energy on convert-ly. There's no point collecting bug reports about it. There is no appetite for spending energy on users asking about a gazillion files in Mutopia that stopped working, either. It's not that we have much of a choice. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
On 2/19/12 10:51 AM, Thomas Morley thomasmorle...@googlemail.com wrote: Hi David, 2012/2/19 David Nalesnik david.nales...@gmail.com: Hi Harm, On Sun, Feb 19, 2012 at 8:32 AM, Phil Holmes m...@philholmes.net wrote: 2) correct the syntax of the files you know have errors ready for that move. Which you do is up to you - bear in mind that if you go for 2), then it's possible that the work will be wasted if we struggle to get the LSR updated. However, you will at least be prepared. If you'd like to go the route of updating syntax in the problem files to 2.14, then I'll be happy to take on part of the task. Just let me know! -David I fixed already following files: Altering-the-number-of-stems-in-a-beam.ly I changed the old override-auto-beam-setting. automatic-beams-two-per-two-in-4-4-or-2-2-time-signature.ly I changed the old override-auto-beam-setting. coloring-individual-staff-lines.ly I added the definition for interval-translate from 2.12.3 Better use an other fix? how-to-define-autobeamsettings-in-the‹layout-block.ly I changed the autoBeamSettings. Including-a-file-only-once.ly I reimplemented the relevant definitions from 2.12.3 Better use an other fix? Obtaining-a-tablature-for-open-tuning-and-or-normal-tuning.ly This snippet may be no longer needed due to changes in tablature. I replaced the number-lists with pitches-lists. Better implementation with makeStringTuning? TODO handle the log-warning: warning: no such internal option: open-tuning TODO change the description overriding-automatic-beam-settings.ly I changed the old override-auto-beam-setting and a comment. I think that this snippet is no longer needed because of the new autobeam syntax which is in the docs. Positioning-tuplet-numbers-close-to-kneed-beams.ly I changed 'thickness to 'beam-thickness as the author suggested (line 64). specifying-context-with-beatgrouping.ly I changed beatGrouping to beatStructure Suggestion: New Title: doctitle = Specifying context with beatStructure I believe this is also covered adequately in the docs. template-for-multiple-instruments,-prints-a-score-and-parts.ly I changed the old override-auto-beam-setting. use-custom-fonts-flat-b-and-sharp-#-symbols-for-chords.ly I simply added added lowercase? To the definition of my-chord-name-pop-markup Of course lowercase? Is of no use here. A better fix would be more invasive. I didn't manage to fix: filtering-parts-from-the-command-line.ly mixed-meter---automatic-compound-time-signatures.ly May I ask you and any other interested user for review and perhaps ideas for the remaining files? Thanks for your work on this. Carl ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi David,
2012/2/19 David Kastrup d...@gnu.org:
So if it is not too much work to collect triplets of version #, before,
after convert-ly, after correct change, it might be a nice base for
looking how to improve the convertrules file.
as an example I use: overriding-automatic-beam-settings.ly
I atached the original-file, the after-convert-ly-file and the manual
upgraded file.
This is the converting-log-message:
convert-ly -e overriding-automatic-beam-settings.ly
convert-ly (GNU LilyPond) 2.14.2
Processing `overriding-automatic-beam-settings.ly'...
Applying conversion: 2.12.3, 2.13.0, 2.13.1, 2.13.4,
Not smart enough to convert override-auto-beam-setting.
Autobeam settings are now overriden with \overrideBeamSettings.
Please refer to the manual for details, and update manually.2.13.10,
2.13.16, 2.13.18, 2.13.20, 2.13.29, 2.13.31, 2.13.36, 2.13.39,
2.13.40, 2.13.42, 2.13.44, 2.13.46, 2.13.48, 2.13.51, 2.14.0
Furthermore, I realized, that there seems to be no conversion rule for
the following 2.12.3-definitions:
From 2.12.3: \scm\lily-library.scm
(define (interval-translate iv amount)
(cons (+ amount (car iv))
(+ amount (cdr iv
From 2.12.3: \ly\markup-init.ly
#(define-public toplevel-module-define-public! #f)
#(define-public toplevel-module-ref #f)
#(let ((toplevel-module (current-module)))
(set! toplevel-module-define-public!
(lambda (symbol value)
(module-define! toplevel-module symbol value)
(module-export! toplevel-module (list symbol
(set! toplevel-module-ref
(lambda (symbol)
(module-ref toplevel-module symbol
#(defmacro-public define-public-toplevel
(first-arg . rest)
Define a public variable or function in the toplevel module:
(define-public-toplevel variable-name value)
or:
(define-public-toplevel (function-name . args)
..body..)
(if (symbol? first-arg)
;; (define-public-toplevel symbol value)
(let ((symbol first-arg)
(value (car rest)))
`(toplevel-module-define-public! ',symbol ,value))
;; (define-public-toplevel (function-name . args) . body)
(let ((function-name (car first-arg))
(arg-list (cdr first-arg))
(body rest))
`(toplevel-module-define-public!
',function-name
(let ((proc (lambda ,arg-list
,@body)))
(set-procedure-property! proc
'name
',function-name)
proc)
And of course any 2.14.2-chordRootNamer-definition expects two
arguments now. I've no idea how that could be covered by converting
rules.
Best,
Harm
\version 2.14.0
\header {
texidoc =
You can override the automatic beaming settings.
The auto-beamer, which can be overridden, will only engrave beams that
end before encountering of
* a rest,
* another, manually entered beam, or
* a bar line.
The @code{autoBeaming} can also be turned off.
doctitle = Overriding automatic beam settings
}
\score{
\relative c''{
\time 2/4
%{
the default for 2/4 (see scm/auto-beam.scm)
| | | |--|
x| x| x| x| x|
%}
c8 c c c16 c
%{
user override
--
| | | |--|
x| x| x| x| x|
%}
% one beam per measure
#(override-auto-beam-setting '(end * * * *) 1 2)
c8 c c c16 c
% from here on consider ending beam every 1/4 note
#(override-auto-beam-setting '(end * * * *) 1 4)
c8 c c c16 c
% manually override autobeam with weird beaming
c8 c[ c] c16 c
% no autobeaming
\set autoBeaming = ##f
c8 c c c16 c
}
}
\version 2.14.0
\header {
texidoc =
You can override the automatic beaming settings.
The auto-beamer, which can be overridden, will only engrave beams that
end before encountering of
* a rest,
* another, manually entered beam, or
* a bar line.
The @code{autoBeaming} can also be turned off.
doctitle = Overriding automatic beam settings
}
\score{
\relative c''{
\time 2/4
%{
the default for 2/4 (see scm/auto-beam.scm)
| | | |--|
x| x| x| x| x|
%}
c8 c c c16 c
%{
user override
--
| | | |--|
x| x| x| x| x|
%}
% one beam per measure
#(override-auto-beam-setting '(end * * * *) 1 2)
c8 c c c16 c
% from here on consider ending beam every 1/4 note
#(override-auto-beam-setting '(end * * * *) 1 4)
c8 c c c16 c
% manually override autobeam with weird beaming
c8 c[ c] c16 c
% no autobeaming
\set autoBeaming = ##f
c8 c c c16 c
}
}
\version 2.14.0
\header {
texidoc =
You can override the automatic beaming settings.
The auto-beamer, which can be overridden, will only engrave beams that
end before encountering of
* a rest,
* another, manually entered beam, or
* a bar line.
The @code{autoBeaming} can also be turned off.
doctitle =
Re: LSR updates: was: polychords: a working solution
Hi Harm, On Sun, Feb 19, 2012 at 11:51 AM, Thomas Morley thomasmorle...@googlemail.com wrote: I didn't manage to fix: mixed-meter---automatic-compound-time-signatures.ly I took a look at this file, and I came up with the attached. What I've done seems to work just fine, but given the substantial changes, I'm a bit unsure of what I've done. Could you (and interested parties reading this) try this out? One question I have concerns the lines which are commented out (which are updates of lines in the original snippet). Uncommenting them doesn't affect the output of the example. Are they at all necessary? Thanks, David mixed-meter---automatic-compound-time-signatures.ly Description: Binary data ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR updates: was: polychords: a working solution
Hi again,
On Sun, Feb 19, 2012 at 9:03 PM, David Nalesnik david.nales...@gmail.comwrote:
Hi Harm,
On Sun, Feb 19, 2012 at 11:51 AM, Thomas Morley
thomasmorle...@googlemail.com wrote:
I didn't manage to fix:
mixed-meter---automatic-compound-time-signatures.ly
A little more exploring led me to \compoundMeter...
This snippet shouldn't be necessary anymore.
It can be replaced with:
{
%\compoundMeter #'((3 2 2 3 8)) ;; numerators over a single denominator
\compoundMeter #'((3 8) (2 8) (2 8) (3 8)) ;; each numerator with its own
denominator, as in the snippet
\repeat unfold 10 c'8 \repeat unfold 20 c'16
}
-David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
