Re: Issue 3942: Scale slurs and ties when using \magnifyMusic. (issue 103890046)
markpole...@gmail.com writes: On 2014/06/06 09:29:03, Mark Polesky wrote: Please review this new patch. I'm not entirely sure this is the right approach, so I may need some advice here. This patch has gone through the review/countdown process without a single comment or review, but I'm not comfortable pushing it without any feedback. In the definition of \magnifyMusic (in music-functions-init.ly), I've used about 50 temporary overrides, manually entering scaled values based on the normal default values for each grob-property I'm overriding. Ideally, if the user has already modified some of those values, I'd like to base the new scaled values on the user's choices, and not base them on the LilyPond default values. If that's possible at all, I don't know how to do that. If you do a read-modify-write on properties, you have to use \applyMusic for that. https://codereview.appspot.com/103890046/ -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3951: Fix broken LSR links in docs. (issue 102410043 by markpole...@gmail.com)
I am not sure this is the best/correct method for the snippets. Shouldn't you be editing those in ../snippets/new/.. and then using makelsr.py to 'update' the snippets in the usual way? Else if someone comes and edits a snippet in new *after* this patch, all your work is undone as the 'new' snippet overwrites the original one. I am always a bit sketchy on the snippets process (when I do get it I forget to document it more coherently in the CG), but I think this won't work. https://codereview.appspot.com/102410043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES: Countdown - June 17th - 06:00 GMT
Hello, 3948 http://code.google.com/p/lilypond/issues/detail?id=3948q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Other Mark PoleskypushChange `magstep' to `font-size-magnification'. 3946 http://code.google.com/p/lilypond/issues/detail?id=3946q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement David Kastrup pushPatch: Don't define `parser' in lily.scm 3952 http://code.google.com/p/lilypond/issues/detail?id=3952q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Documentation Mark Poleskycountdown Automatically sort props within each grob-interface. 3951 http://code.google.com/p/lilypond/issues/detail?id=3951q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Documentation Mark Poleskycountdown Fix broken LSR links in docs. 3944 http://code.google.com/p/lilypond/issues/detail?id=3944q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified UglyMark Poleskycountdown Match PhrasingSlur thickness to Slur and Tie. 3950 http://code.google.com/p/lilypond/issues/detail?id=3950q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Documentation David Kastrup review Usage 1.4: \relative inside \unfold doesn't cause an extra staff anymore 3942 http://code.google.com/p/lilypond/issues/detail?id=3942q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Mark Poleskyreview Scale slurs and ties when using \magnifyMusic. 2950 http://code.google.com/p/lilypond/issues/detail?id=2950q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Documentation Phil Holmes new Two examples of a substitution function with 'padding need changing 3186 http://code.google.com/p/lilypond/issues/detail?id=3186q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified UglyJanek Warchol waiting Positioning of 8 under clef symbol in G_8 clef Bounty Jan 26 3156 http://code.google.com/p/lilypond/issues/detail?id=3156q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Mike Solomonwaiting Patch: Prevents vertical axis groups with empty skylines Feb 2013 3134 http://code.google.com/p/lilypond/issues/detail?id=3134q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Mike Solomonwaiting Patch: Removes the translate_axis call from axis-group-interface outside-staff positioning. Aug 2013 2812 http://code.google.com/p/lilypond/issues/detail?id=2812q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Documentation Keith Ohara waiting Renaming to distinguish keySignature from KeySignature Nov 11 2716
Re: Issue 3951: Fix broken LSR links in docs. (issue 102410043 bymarkpole...@gmail.com)
- Original Message - From: pkx1...@gmail.com To: markpole...@gmail.com; lemzw...@googlemail.com Cc: re...@codereview-hr.appspotmail.com; lilypond-devel@gnu.org Sent: Saturday, June 14, 2014 10:43 AM Subject: Re: Issue 3951: Fix broken LSR links in docs. (issue 102410043 bymarkpole...@gmail.com) I am not sure this is the best/correct method for the snippets. Shouldn't you be editing those in ../snippets/new/.. and then using makelsr.py to 'update' the snippets in the usual way? Else if someone comes and edits a snippet in new *after* this patch, all your work is undone as the 'new' snippet overwrites the original one. I am always a bit sketchy on the snippets process (when I do get it I forget to document it more coherently in the CG), but I think this won't work. https://codereview.appspot.com/102410043/ I would suggest correcting the links in the Documentation, but not the snippets themselves. The links in the snippets are not really visible (commented out) and, as James says, are over-written with an LSR import. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3951: Fix broken LSR links in docs. (issue 102410043 by markpole...@gmail.com)
On 2014/06/14 10:03:46, mail_philholmes.net wrote: I would suggest correcting the links in the Documentation, but not the snippets themselves. The links in the snippets are not really visible (commented out) and, as James says, are over-written with an LSR import. Fair enough. I reverted the edits within the snippets directory, then ran makelsr.py, which affected only one file: Documentation/snippets/defining-an-engraver-in-scheme--ambitus-engraver.ly All better? Thanks. - Mark https://codereview.appspot.com/102410043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Color and/or parenthesize single dots in fret-diagrams (issue 102450043 by thomasmorle...@gmail.com)
Reviewers: , Message: Please review Description: Color and/or parenthesize single dots in fret-diagrams Issue 2752 Makes it possible to color and/or parenthesize single dots in fret-diagram-verbose Introducing two properties for use in fret-diagram-details - fret-label-horizontal-offset affecting the fret-label-indication, like the existing `fret-label-vertical-offset' - paren-padding affecting the padding of the parenthesis Extending relevant reg-tests. Documenting it in NR, fretted-strings.itely Please review this at https://codereview.appspot.com/102450043/ Affected files (+233, -51 lines): M Documentation/notation/fretted-strings.itely M input/regression/fret-diagrams-dots.ly M input/regression/fret-diagrams-fingering.ly M input/regression/fret-diagrams-fret-label.ly M scm/define-grob-properties.scm M scm/fret-diagrams.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Color and/or parenthesize single dots in fret-diagrams (issue 102450043 by thomasmorle...@gmail.com)
https://codereview.appspot.com/102450043/diff/1/Documentation/notation/fretted-strings.itely File Documentation/notation/fretted-strings.itely (right): https://codereview.appspot.com/102450043/diff/1/Documentation/notation/fretted-strings.itely#newcode1002 Documentation/notation/fretted-strings.itely:1002: color. We need a new (obvious) paragraph for this new text I think, so give a line space after the previous one. The syntax is a bit uncomfortable I think. Are they really just called 'dots'? Here's my suggestion: Fingering indication dots can be colored as well as parenthesized; the parenthesis's color can also be altered independently. The example will show the subtleties of 'inversion' and 'modification'. https://codereview.appspot.com/102450043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make \upbow an empty command + Segmentation fault
ccing Dev list as I think this might be more pertinent there.
James
On 12/04/14 14:22, Felix Janda wrote:
Hi,
say I have a violin part with bowing instructions in a variable. Now I want
to use the same variable in the full orchestral score but the bowing marks
should be suppressed.
\upbow is treated by lilypond as an articulation, but the other
articulations should be unaffected by the suppressing of \upbow.
upbow={}
doesn't work because it breaks things like
a\upbow ~ a
Playing a bit with the definition of \upbow gave me a segfault.
Minimal example:
\version 2.18.0
upbow = #(make-music 'ArticulationEvent
'articulation-type upbow 'types #f)
downbow = \upbow
Anyway, how do I make a command which has no effect at all?
Cheers,
Felix
___
bug-lilypond mailing list
bug-lilyp...@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make \upbow an empty command + Segmentation fault
On 12/04/14 14:22, Felix Janda wrote:
Hi,
say I have a violin part with bowing instructions in a variable. Now I want
to use the same variable in the full orchestral score but the bowing marks
should be suppressed.
\upbow is treated by lilypond as an articulation, but the other
articulations should be unaffected by the suppressing of \upbow.
upbow={}
doesn't work because it breaks things like
a\upbow ~ a
I’m sorry I haven’t spent time to thoroughly understand your needs, but it
sounds like there is a chance that something derived from this (which I have
actually used) would help:
stripArticulation =
#(define-music-function
(parser location music) (ly:music?)
(music-filter
(lambda (m) (not (eq? (ly:music-property m 'name) 'ArticulationEvent)))
music))
Rather than redefining \upbow, use \stripBowings \yourMusic to filter out the
articulations you don’t want to see.
Another approach that might work is to put the articulations in a different
music variable attached to spacers (e.g. “s1”) and then put it in simultaneous
music like \yourMusic \yourBowings, but I can’t say much about that because
I don’t do it.
—
Dan
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make \upbow an empty command + Segmentation fault
James pkx1...@gmail.com writes:
On 12/04/14 14:22, Felix Janda wrote:
Hi,
say I have a violin part with bowing instructions in a variable. Now I want
to use the same variable in the full orchestral score but the bowing marks
should be suppressed.
\upbow is treated by lilypond as an articulation, but the other
articulations should be unaffected by the suppressing of \upbow.
upbow={}
doesn't work because it breaks things like
a\upbow ~ a
Playing a bit with the definition of \upbow gave me a segfault.
Minimal example:
\version 2.18.0
upbow = #(make-music 'ArticulationEvent
'articulation-type upbow 'types #f)
downbow = \upbow
Anyway, how do I make a command which has no effect at all?
No effect at all in general is not feasible I think, but in this case
you already know that it is used in post event position. In 2.18, you
can probably do
upbow = #(make-music 'PostEvents)
I'm not entirely sure that this will work forever as it is sort of a
hack, but it's probably going to stick around for a while.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3942: Scale slurs and ties when using \magnifyMusic. (issue 103890046 by markpole...@gmail.com)
On 2014/06/14 06:58:52, dak wrote: On 2014/06/06 09:29:03, Mark Polesky wrote: ... Ideally, if the user has already modified some of those values, I'd like to base the new scaled values on the user's choices, and not base them on the LilyPond default values. If that's possible at all, I don't know how to do that. If you do a read-modify-write on properties, you have to use \applyMusic for that. David, I'm sorry to say that I'm unable to figure this out on my own. \applyMusic is completely undocumented and the few occurrences in the source code are not illustrative enough for me. Within an \applyMusic construct, how do I access a given grob-property value, and then override it -- temporarily? Thanks. - Mark https://codereview.appspot.com/103890046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3942: Scale slurs and ties when using \magnifyMusic. (issue 103890046 by markpole...@gmail.com)
markpole...@gmail.com writes: On 2014/06/14 06:58:52, dak wrote: On 2014/06/06 09:29:03, Mark Polesky wrote: ... Ideally, if the user has already modified some of those values, I'd like to base the new scaled values on the user's choices, and not base them on the LilyPond default values. If that's possible at all, I don't know how to do that. If you do a read-modify-write on properties, you have to use \applyMusic for that. David, I'm sorry to say that I'm unable to figure this out on my own. \applyMusic is completely undocumented and the few occurrences in the source code are not illustrative enough for me. Within an \applyMusic construct, how do I access a given grob-property value, and then override it -- temporarily? It would have helped if I had written the correct command to use. It is, of course, \applyContext. The documentation does not help much, but one illustrative read/modify/write use is in scm/music-functions.scm in add-grace-property and remove-grace-property. https://codereview.appspot.com/103890046/ -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make \upbow an empty command + Segmentation fault
David Kastrup wrote:
James pkx1...@gmail.com writes:
On 12/04/14 14:22, Felix Janda wrote:
Hi,
say I have a violin part with bowing instructions in a variable. Now I want
to use the same variable in the full orchestral score but the bowing marks
should be suppressed.
\upbow is treated by lilypond as an articulation, but the other
articulations should be unaffected by the suppressing of \upbow.
upbow={}
doesn't work because it breaks things like
a\upbow ~ a
Playing a bit with the definition of \upbow gave me a segfault.
Minimal example:
\version 2.18.0
upbow = #(make-music 'ArticulationEvent
'articulation-type upbow 'types #f)
downbow = \upbow
Anyway, how do I make a command which has no effect at all?
No effect at all in general is not feasible I think, but in this case
you already know that it is used in post event position. In 2.18, you
can probably do
upbow = #(make-music 'PostEvents)
I'm not entirely sure that this will work forever as it is sort of a
hack, but it's probably going to stick around for a while.
--
David Kastrup
Thanks. That's the same thing I ended up using. (I have the faint
memory of writing a reply with this solution, but maybe I only
replied to myself...)
Felix
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
