Re: Beam collision engraver weirdness
This does the trick.
\score {
\new PianoStaff <<
\new Staff = "one" \relative c'{
\autoBeamOff
\stemUp c8 c \change Staff=two \stemUp c c
c c c c
\change Staff=one
\stemDown c8 c \change Staff=two \stemUp c c
r2
\stemDown c8[ c \change Staff=one \stemDown c c]
r2
\change Staff=two
\stemUp c8[ c \change Staff=one \stemDown c] c
r2
}
\new Staff = "two" \relative c'{
\clef bass
s1
s1
s1
s1
} >>
\layout {
\context {
\Score
\consists "Beam_collision_engraver"
}
\context {
\Staff
\remove "Beam_collision_engraver"
}
}
}
This kludge up messing up big scores royally, however.
The solution in my old code was to turn off collision avoidance for cross staff
beams. If you think that is an acceptable solution, I can implement it.
Cheers,
MS
On Feb 28, 2011, at 8:59 PM, Han-Wen Nienhuys wrote:
> Hey mike,
>
> have a look at the .ly below
>
> In this case, the 2nd beam and a note from the 2nd beam get added to
> the 1st beam. Can you make sure this does not happen?
>
> thanks,
>
>
>
> \context PianoStaff <<
> \new Staff = "one" \relative c'{
>\autoBeamOff
>\stemUp c8 c \change Staff=two \stemUp c c
>c c c c
>\change Staff=one
>\stemDown c8 c \change Staff=two \stemUp c c
>r2
>\stemDown c8[ c \change Staff=one \stemDown c c]
>r2
>\change Staff=two
>\stemUp c8[ c \change Staff=one \stemDown c] c
>r2
> }
> \new Staff = "two" \relative c'{
>\clef bass
>s1
>s1
>s1
>s1
> }
>>>
>
> --
> Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Beam collision engraver weirdness
Hey mike,
have a look at the .ly below
In this case, the 2nd beam and a note from the 2nd beam get added to
the 1st beam. Can you make sure this does not happen?
thanks,
\context PianoStaff <<
\new Staff = "one" \relative c'{
\autoBeamOff
\stemUp c8 c \change Staff=two \stemUp c c
c c c c
\change Staff=one
\stemDown c8 c \change Staff=two \stemUp c c
r2
\stemDown c8[ c \change Staff=one \stemDown c c]
r2
\change Staff=two
\stemUp c8[ c \change Staff=one \stemDown c] c
r2
}
\new Staff = "two" \relative c'{
\clef bass
s1
s1
s1
s1
}
>>
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduces algorithm time by prefinding footnoted grobs (issue4213042)
http://codereview.appspot.com/4213042/diff/35006/lily/footnote-engraver.cc
File lily/footnote-engraver.cc (right):
http://codereview.appspot.com/4213042/diff/35006/lily/footnote-engraver.cc#newcode67
lily/footnote-engraver.cc:67: b->set_property ("footnote-text",
event->get_property ("footnote-text"));
On 2011/02/28 23:39:45, Neil Puttock wrote:
remove and add default in define-grobs.scm via
`grob::calc-property-by-copy'
Done.
http://codereview.appspot.com/4213042/diff/35006/lily/footnote-engraver.cc#newcode68
lily/footnote-engraver.cc:68: b->set_property ("text",
event->get_property ("text"));
On 2011/02/28 23:39:45, Neil Puttock wrote:
remove
Done.
http://codereview.appspot.com/4213042/diff/35006/lily/footnote-engraver.cc#newcode79
lily/footnote-engraver.cc:79: Grob *b = make_item ("FootnoteItem",
event->self_scm ());
On 2011/02/28 23:39:45, Neil Puttock wrote:
remove and add default in define-grobs.scm via
`grob::calc-property-by-copy'
Done.
http://codereview.appspot.com/4213042/diff/35006/lily/footnote-engraver.cc#newcode80
lily/footnote-engraver.cc:80: b->set_property ("footnote-text",
event->get_property ("footnote-text"));
On 2011/02/28 23:39:45, Neil Puttock wrote:
remove
Done.
http://codereview.appspot.com/4213042/diff/35006/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):
http://codereview.appspot.com/4213042/diff/35006/ly/music-functions-init.ly#newcode355
ly/music-functions-init.ly:355: 'footnote-text footnote))
On 2011/02/28 23:39:45, Neil Puttock wrote:
add 'footnote-text to define-music-properties.scm
Done.
http://codereview.appspot.com/4213042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduces algorithm time by prefinding footnoted grobs (issue4213042)
http://codereview.appspot.com/4213042/diff/35006/lily/footnote-engraver.cc
File lily/footnote-engraver.cc (right):
http://codereview.appspot.com/4213042/diff/35006/lily/footnote-engraver.cc#newcode67
lily/footnote-engraver.cc:67: b->set_property ("footnote-text",
event->get_property ("footnote-text"));
remove and add default in define-grobs.scm via
`grob::calc-property-by-copy'
http://codereview.appspot.com/4213042/diff/35006/lily/footnote-engraver.cc#newcode68
lily/footnote-engraver.cc:68: b->set_property ("text",
event->get_property ("text"));
remove
http://codereview.appspot.com/4213042/diff/35006/lily/footnote-engraver.cc#newcode79
lily/footnote-engraver.cc:79: Grob *b = make_item ("FootnoteItem",
event->self_scm ());
remove and add default in define-grobs.scm via
`grob::calc-property-by-copy'
http://codereview.appspot.com/4213042/diff/35006/lily/footnote-engraver.cc#newcode80
lily/footnote-engraver.cc:80: b->set_property ("footnote-text",
event->get_property ("footnote-text"));
remove
http://codereview.appspot.com/4213042/diff/35006/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):
http://codereview.appspot.com/4213042/diff/35006/ly/music-functions-init.ly#newcode355
ly/music-functions-init.ly:355: 'footnote-text footnote))
add 'footnote-text to define-music-properties.scm
http://codereview.appspot.com/4213042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduces algorithm time by prefinding footnoted grobs (issue4213042)
http://codereview.appspot.com/4213042/diff/44001/lily/balloon.cc
File lily/balloon.cc (right):
http://codereview.appspot.com/4213042/diff/44001/lily/balloon.cc#newcode77
lily/balloon.cc:77: Grob *commonx = bounds[LEFT]->common_refpoint
(bounds[RIGHT], X_AXIS);
On 2011/02/28 23:04:21, Neil Puttock wrote:
You might as well say
Grob *commonx = me->get_bound (LEFT);
since bounds[LEFT] is guaranteed to be the same as bounds[RIGHT]
Done.
http://codereview.appspot.com/4213042/diff/44001/lily/system.cc
File lily/system.cc (right):
http://codereview.appspot.com/4213042/diff/44001/lily/system.cc#newcode301
lily/system.cc:301: system->footnotes_ = get_footnotes_in_range (st,
end);
On 2011/02/28 23:04:21, Neil Puttock wrote:
While this ensures we're only considering footnotes in this system, it
doesn't
know whether a particular footnote is set on a grob which might later
disappear
due to break-visibility settings.
Here's an example:
\relative c' {
\footnoteGrob #'Clef #'(0 . -1) "clef" "1. Clef"
c1
}
\layout {
\context {
\Staff
\consists "Footnote_engraver"
}
}
-> produces three footnotes for the visible clef and its suicided
middle- and
end-of-line versions
Fixed.
http://codereview.appspot.com/4213042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduces algorithm time by prefinding footnoted grobs (issue4213042)
http://codereview.appspot.com/4213042/diff/44001/lily/balloon.cc
File lily/balloon.cc (right):
http://codereview.appspot.com/4213042/diff/44001/lily/balloon.cc#newcode77
lily/balloon.cc:77: Grob *commonx = bounds[LEFT]->common_refpoint
(bounds[RIGHT], X_AXIS);
You might as well say
Grob *commonx = me->get_bound (LEFT);
since bounds[LEFT] is guaranteed to be the same as bounds[RIGHT]
http://codereview.appspot.com/4213042/diff/44001/lily/system.cc
File lily/system.cc (right):
http://codereview.appspot.com/4213042/diff/44001/lily/system.cc#newcode301
lily/system.cc:301: system->footnotes_ = get_footnotes_in_range (st,
end);
While this ensures we're only considering footnotes in this system, it
doesn't know whether a particular footnote is set on a grob which might
later disappear due to break-visibility settings.
Here's an example:
\relative c' {
\footnoteGrob #'Clef #'(0 . -1) "clef" "1. Clef"
c1
}
\layout {
\context {
\Staff
\consists "Footnote_engraver"
}
}
-> produces three footnotes for the visible clef and its suicided
middle- and end-of-line versions
http://codereview.appspot.com/4213042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduces algorithm time by prefinding footnoted grobs (issue4213042)
On Feb 28, 2011, at 5:42 PM, Neil Puttock wrote: > On 28 February 2011 00:32, wrote: > >> For now, I'm just gonna remove this kludge and leave it as is. It means >> that certain spanners may budge when annotations are attached to them, >> but I'll need more time to figure out a sustainable way to get the axis >> engraver to ignore the height of these annotations. My initial hunch >> after reading your comment was to set cross-staff to #t, but this >> segfaults on any spanner that has a line break. > > Why can't you just set Y-extent to #f (like BalloonTextItem does)? > cross-staff winds up doing the trick - it wasn't cross staff that segfaulted, but something else (see below). I can use either (cross-staff . #t) , (Y-extent . #f) , or both depending on what floats people's boats. >> This segfault for cross staff may reveal some problems with the way that >> the FootnoteSpanner is being treated in the axis engraver - any >> thoughts? > > Can you post an example which segfaults? Sorry - I've since fixed it in line 65-66 of balloon.cc . Sometimes, parent-spanner is not set (this likely comes from the FoonoteSpanner getting broken into pieces and, for whatever reason, not getting passed a parent spanner property. That or the parent spanner no longer exists). This is part of a larger problem, which is that in the current implementation, the parent-spanner is not yet broken into pieces when passed to Balloon::print_spanner. This means that the annotation cannot apply to anything but the first spanner of a series. I am reticent to trigger line breaking of the parent-spanner, and I'm not even certain that I'd know how in a lilypondaic way. If anyone has ideas on how to make this more flexible, I'd be happy to hear what you have to say! > >> I think I do need it - a pretty print to the command line shows that the >> parent of these spanners is a PaperColumn when the print function is >> called in spite of the fact that I set it to be a spanner, whereas >> "parent-spanner" doesn't change. Somewhere in the code, this guy's >> parents are getting reset. > > I can't say I've noticed this. Every example I tested had the correct > Y-parent. > You're right...I was reading the code incorrectly. >> http://codereview.appspot.com/4213042/diff/34032/lily/footnote-engraver.cc#newcode119 >> lily/footnote-engraver.cc:119: "Footnote ", >> On 2011/02/27 22:42:24, Neil Puttock wrote: >>> >>> "Footnote " >>> "FootnoteSpanner ", >> >>> Perhaps rename Footnote FootnoteItem. >> >> I don't mind renaming it, but could you give a reason for doing so? > > It makes the distinction between the two types clearer (and ties in > with BalloonTextItem/ParenthesesItem). Done - I misunderstood your original suggestion. > >> http://codereview.appspot.com/4213042/diff/34032/scm/define-markup-commands.scm >> File scm/define-markup-commands.scm (right): >> >> http://codereview.appspot.com/4213042/diff/34032/scm/define-markup-commands.scm#newcode142 >> scm/define-markup-commands.scm:142: (define-markup-command (draw-hline >> layout props) >> On 2011/02/27 22:42:24, Neil Puttock wrote: >>> >>> still needs simplifying via draw-line >> >> I'm still not quite sure how to do this - do you want me to change the >> thickness property of props and then call draw-line? > > See my comment on your sixth patchset (it comes with an example > implementation). > Done. Cheers, MS___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduces algorithm time by prefinding footnoted grobs (issue4213042)
On 28 February 2011 00:32, wrote: > For now, I'm just gonna remove this kludge and leave it as is. It means > that certain spanners may budge when annotations are attached to them, > but I'll need more time to figure out a sustainable way to get the axis > engraver to ignore the height of these annotations. My initial hunch > after reading your comment was to set cross-staff to #t, but this > segfaults on any spanner that has a line break. Why can't you just set Y-extent to #f (like BalloonTextItem does)? > This segfault for cross staff may reveal some problems with the way that > the FootnoteSpanner is being treated in the axis engraver - any > thoughts? Can you post an example which segfaults? > I think I do need it - a pretty print to the command line shows that the > parent of these spanners is a PaperColumn when the print function is > called in spite of the fact that I set it to be a spanner, whereas > "parent-spanner" doesn't change. Somewhere in the code, this guy's > parents are getting reset. I can't say I've noticed this. Every example I tested had the correct Y-parent. > http://codereview.appspot.com/4213042/diff/34032/lily/footnote-engraver.cc#newcode119 > lily/footnote-engraver.cc:119: "Footnote ", > On 2011/02/27 22:42:24, Neil Puttock wrote: >> >> "Footnote " >> "FootnoteSpanner ", > >> Perhaps rename Footnote FootnoteItem. > > I don't mind renaming it, but could you give a reason for doing so? It makes the distinction between the two types clearer (and ties in with BalloonTextItem/ParenthesesItem). > http://codereview.appspot.com/4213042/diff/34032/scm/define-markup-commands.scm > File scm/define-markup-commands.scm (right): > > http://codereview.appspot.com/4213042/diff/34032/scm/define-markup-commands.scm#newcode142 > scm/define-markup-commands.scm:142: (define-markup-command (draw-hline > layout props) > On 2011/02/27 22:42:24, Neil Puttock wrote: >> >> still needs simplifying via draw-line > > I'm still not quite sure how to do this - do you want me to change the > thickness property of props and then call draw-line? See my comment on your sixth patchset (it comes with an example implementation). Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduces algorithm time by prefinding footnoted grobs (issue4213042)
On 28 February 2011 21:06, m...@apollinemike.com wrote: > I found a problem w/ my footnote work. Check out the 2nd example in bad.ly > and bad.pdf . Why do you think the annotation is placed so far to the left > here but not in other cases? You're setting the spanner bounds to a NonMusicalPaperColumn when there's a barline, so the refpoint is the column at the start of the system rather than the PaperColumn before the first note. > It is based off of the most recent version of my patch on Rietveld. footnote-engraver.cc appears to have gone AWOL. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: harmonics and slides (issue4186049)
Am 28.02.2011 um 22:14 schrieb James Lowe: > Patrick > > -Original Message- > From: > Reply-To: , , > , , lilypond-devel > , > Date: Mon, 28 Feb 2011 21:00:15 + > To: , , > > Cc: , lilypond-devel > > Subject: Re: Doc: harmonics and slides (issue4186049) > >> BTW I accidentally created another issue number (4245047). Sorry for >> that. How can I delete it? > > If you look on the right hand side where you can 'download' the patch set, > there should be a 'delete..' link there. There is a 'delete link' for 4186049 but not for 4245047. At least I can't see/find it. Thanks, patrick > > James > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: harmonics and slides (issue4186049)
Patrick -Original Message- From: Reply-To: , , , , lilypond-devel , Date: Mon, 28 Feb 2011 21:00:15 + To: , , Cc: , lilypond-devel Subject: Re: Doc: harmonics and slides (issue4186049) >BTW I accidentally created another issue number (4245047). Sorry for >that. How can I delete it? If you look on the right hand side where you can 'download' the patch set, there should be a 'delete..' link there. James ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: harmonics and slides (issue4186049)
Hi all, here is a revised patch. I hope everything is ok now. I don't know why two files I did not alter are part of this patch: hymn-template.ly and partcombine-and-autobeamoff.ly. BTW I accidentally created another issue number (4245047). Sorry for that. How can I delete it? Thanks for your help! patrick http://codereview.appspot.com/4186049/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: harmonics and slides (issue4186049)
Am 28.02.2011 um 14:21 schrieb pkx1...@gmail.com: > One comment. > > Thanks for your time. > > > http://codereview.appspot.com/4186049/diff/6002/Documentation/notation/fretted-strings.itely > File Documentation/notation/fretted-strings.itely (right): > > http://codereview.appspot.com/4186049/diff/6002/Documentation/notation/fretted-strings.itely#newcode427 > Documentation/notation/fretted-strings.itely:427: @end lilypond > Apologies for my ignorance on fretted music, but is there a reason we > need both the \ottava #1 and the \clef "treble_8" functions in this? > > That is, can we omit one/all of them and still make the example make > sense? Hm, we could omit all of them but this might be confusing for guitarists. Guitarists normally read music as if there were a "treble_8" even when there is a "treble"-clef. I probably included the \ottava #1 in one of my first snippets to avoid very high notes. But in this case it is not really necessary, indeed! Thanks, patrick > > I know it seems trivial but it does make the @lilypond even simpler and > more compact. > > http://codereview.appspot.com/4186049/ > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR @Knownissues for Grace Notes in many Voices (issue4250044)
LGTM http://codereview.appspot.com/4250044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: NR @Knownissues for Grace Notes in many Voices (issue4250044)
Reviewers: ,
Message:
This is a patch from Phil. I've made some minor formatting changes to
bring it in line with the CG.
http://codereview.appspot.com/4250044
Description:
Doc: NR @Knownissues for Grace Notes in many Voices
This is http://code.google.com/p/lilypond/issues/detail?id=667
Adding a known issue to the grace notes section to show how to
overcome grace notes confusing voice settings.
Please review this at http://codereview.appspot.com/4250044/
Affected files:
M Documentation/notation/rhythms.itely
Index: Documentation/notation/rhythms.itely
diff --git a/Documentation/notation/rhythms.itely
b/Documentation/notation/rhythms.itely
index
40fc4ec61091c45c040027ace5b0a9321f986ee9..ec1913fb58d2ee458bd0cf8b194810896acbb4ab
100644
--- a/Documentation/notation/rhythms.itely
+++ b/Documentation/notation/rhythms.itely
@@ -3212,10 +3212,40 @@ durations in the other staves. For the above
example
>>
@end lilypond
+
+@knownissues
+The use of grace notes within voice contexts confuses the way the
+voice is typeset. This can be overcome by inserting a rest or note
+between the voice command and the grace note.
+
+@lilypond[quote,verbatim]
+accMusic = {
+ \acciaccatura { f8 } e8 r8 \acciaccatura { f8 } e8 r4
+}
+
+\new Staff {
+ <<
+\new Voice {
+ \relative c'' {
+r8 r8 \voiceOne \accMusic \oneVoice r8 |
+r8 \voiceOne r8 \accMusic \oneVoice r8 |
+ }
+}
+\new Voice {
+ \relative c' {
+s8 s8 \voiceTwo \accMusic \oneVoice s8 |
+s8 \voiceTwo r8 \accMusic \oneVoice s8 |
+ }
+}
+ >>
+}
+@end lilypond
+
Grace sections should only be used within sequential music
expressions. Nesting or juxtaposing grace sections is not
supported, and might produce crashes or other errors.
+
@node Aligning to cadenzas
@unnumberedsubsubsec Aligning to cadenzas
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: add [pagesize=xyz] option. (issue4239048)
Le 28/02/2011 18:27, Phil Holmes disait : - Original Message - From: "Graham Percival" a10 is 26mm by 37m. Must be like very thin toilet tissue. Is it perforated? Just for information: http://en.wikipedia.org/wiki/Paper_format Cheers,Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: add [pagesize=xyz] option. (issue4239048)
- Original Message - From: "Graham Percival" a10 is 26mm by 37m. Must be like very thin toilet tissue. Is it perforated? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Extend Beam::shift_region_to_valid() to also take into account collisions. (issue4239047)
On Mon, Feb 28, 2011 at 11:48 AM, wrote:
> Great work! Two comments below concerning beam properties.
>
>
> http://codereview.appspot.com/4239047/diff/3002/lily/beam.cc
> File lily/beam.cc (right):
>
> http://codereview.appspot.com/4239047/diff/3002/lily/beam.cc#newcode1156
> lily/beam.cc:1156: Real min_y_size = 2.0;
> here, we should have something like
> if (to_boolean (me->get_property ("avoid-collisions"))
> so that users can opt out of the avoidance if they so choose.
> then, we would have an `else' that set the collision penalty in the
> quanting to 0 so that no collision avoidance took place.
?
Why not modify the beam-collision engraver to not add the objects as
collisions in the first place?
> I think that in a lot of real-music scenarios such as organ scores,
> people's may in fact want beams to collide, and thus, they should be
> able to opt-out of this avoidance.
Let's wait for a bit for these situations to surface. As a first line
of defense, people can simply remove the collision engraver .
> http://codereview.appspot.com/4239047/diff/3002/lily/beam.cc#newcode1256
> lily/beam.cc:1256: beam_left_y = point_in_interval (best, 2.0);
> Here, there should be a padding property that allows users to control
> breathing room for collisions. Otherwise, you could wind up getting a
> beam that is pushed just below a notehead in the quanting (see example
> in next email).
No, the padding is part of the scoring. This is code is just to
provide a credible starting point for the quanting code to look. As
noted in the comments, it assumes single beams as an approximation, so
if you start using this with 128th beams, it may fail. Are you really
using 128ths in this way? We could add a crude offset to account for
beam multiplicity.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: add [pagesize=xyz] option. (issue4239048)
On 2/28/11, pkx1...@gmail.com wrote: > Do we not want to make a custom edit in the .scm file also? > > Perhaps, with a size of height 35mm. a10 is 26mm by 37m. c10 is 28 by 40mm. pa10 is 26mm by 35mm. *shrug* if one of those isn't small enough (also don't forget about landscape size if that's useful), it's easy to add another one. But I believe in small, well-focused patches. Let's get this pushed, then you should be able to play around and let me know what else you need. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Extend Beam::shift_region_to_valid() to also take into account collisions. (issue4239047)
On Mon, Feb 28, 2011 at 11:48 AM, wrote:
> Great work! Two comments below concerning beam properties.
http://codereview.appspot.com/4239047/diff/3002/lily/beam.cc#newcode1156
> lily/beam.cc:1156: Real min_y_size = 2.0;
> here, we should have something like
> if (to_boolean (me->get_property ("avoid-collisions"))
> so that users can opt out of the avoidance if they so choose.
> then, we would have an `else' that set the collision penalty in the
> quanting to 0 so that no collision avoidance took place.
The idea is that this is only necessary for large objects
>
> I think that in a lot of real-music scenarios such as organ scores,
> people's may in fact want beams to collide, and thus, they should be
> able to opt-out of this avoidance.
>
> http://codereview.appspot.com/4239047/diff/3002/lily/beam.cc#newcode1256
> lily/beam.cc:1256: beam_left_y = point_in_interval (best, 2.0);
> Here, there should be a padding property that allows users to control
> breathing room for collisions. Otherwise, you could wind up getting a
> beam that is pushed just below a notehead in the quanting (see example
> in next email).
>
> http://codereview.appspot.com/4239047/
>
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: add [pagesize=xyz] option. (issue4239048)
Graham, thanks. Do we not want to make a custom edit in the .scm file also? Perhaps, with a size of height 35mm. This was about the minimum size I was able to create the default 'This is a scale in LilyPond' PDF created from the first time you run the binary that also includes space for the tagline. Or maybe A8 *is* small enough? http://codereview.appspot.com/4239048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Extend Beam::shift_region_to_valid() to also take into account collisions. (issue4239047)
Attached is the type of note-on-beam thing I was talking about in my previous
comments, which can be fixed w/ a padding property.
Cheers,
MS
<>
On Feb 28, 2011, at 9:48 AM, mts...@gmail.com wrote:
> Great work! Two comments below concerning beam properties.
>
>
> http://codereview.appspot.com/4239047/diff/3002/lily/beam.cc
> File lily/beam.cc (right):
>
> http://codereview.appspot.com/4239047/diff/3002/lily/beam.cc#newcode1156
> lily/beam.cc:1156: Real min_y_size = 2.0;
> here, we should have something like
> if (to_boolean (me->get_property ("avoid-collisions"))
> so that users can opt out of the avoidance if they so choose.
> then, we would have an `else' that set the collision penalty in the
> quanting to 0 so that no collision avoidance took place.
>
> I think that in a lot of real-music scenarios such as organ scores,
> people's may in fact want beams to collide, and thus, they should be
> able to opt-out of this avoidance.
>
> http://codereview.appspot.com/4239047/diff/3002/lily/beam.cc#newcode1256
> lily/beam.cc:1256: beam_left_y = point_in_interval (best, 2.0);
> Here, there should be a padding property that allows users to control
> breathing room for collisions. Otherwise, you could wind up getting a
> beam that is pushed just below a notehead in the quanting (see example
> in next email).
>
> http://codereview.appspot.com/4239047/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Extend Beam::shift_region_to_valid() to also take into account collisions. (issue4239047)
Great work! Two comments below concerning beam properties.
http://codereview.appspot.com/4239047/diff/3002/lily/beam.cc
File lily/beam.cc (right):
http://codereview.appspot.com/4239047/diff/3002/lily/beam.cc#newcode1156
lily/beam.cc:1156: Real min_y_size = 2.0;
here, we should have something like
if (to_boolean (me->get_property ("avoid-collisions"))
so that users can opt out of the avoidance if they so choose.
then, we would have an `else' that set the collision penalty in the
quanting to 0 so that no collision avoidance took place.
I think that in a lot of real-music scenarios such as organ scores,
people's may in fact want beams to collide, and thus, they should be
able to opt-out of this avoidance.
http://codereview.appspot.com/4239047/diff/3002/lily/beam.cc#newcode1256
lily/beam.cc:1256: beam_left_y = point_in_interval (best, 2.0);
Here, there should be a padding property that allows users to control
breathing room for collisions. Otherwise, you could wind up getting a
beam that is pushed just below a notehead in the quanting (see example
in next email).
http://codereview.appspot.com/4239047/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: add [pagesize=xyz] option. (issue4239048)
LGTM. Thanks, Carl http://codereview.appspot.com/4239048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: harmonics and slides (issue4186049)
LGTM.
Just one trivial nitpick.
http://codereview.appspot.com/4186049/diff/6002/Documentation/notation/fretted-strings.itely
File Documentation/notation/fretted-strings.itely (right):
http://codereview.appspot.com/4186049/diff/6002/Documentation/notation/fretted-strings.itely#newcode389
Documentation/notation/fretted-strings.itely:389: Please note that the
command @code{\harmonic} must always be defined
No need for 'Please'
http://codereview.appspot.com/4186049/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: harmonics and slides (issue4186049)
One comment. Thanks for your time. http://codereview.appspot.com/4186049/diff/6002/Documentation/notation/fretted-strings.itely File Documentation/notation/fretted-strings.itely (right): http://codereview.appspot.com/4186049/diff/6002/Documentation/notation/fretted-strings.itely#newcode427 Documentation/notation/fretted-strings.itely:427: @end lilypond Apologies for my ignorance on fretted music, but is there a reason we need both the \ottava #1 and the \clef "treble_8" functions in this? That is, can we omit one/all of them and still make the example make sense? I know it seems trivial but it does make the @lilypond even simpler and more compact. http://codereview.appspot.com/4186049/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Extend Beam::shift_region_to_valid() to also take into account collisions. (issue4239047)
On Mon, Feb 28, 2011 at 8:21 AM, m...@apollinemike.com wrote: >> fixed. >> >> http://codereview.appspot.com/4239047/ > > Several of the tests that I've been running work better with this new version > - large collisions are now handled no problem. > > The only things that don't work properly are the organ example as well as the > two attached examples. Is there any way to prevent the beam collision from > pulling these up? See attached. This was done with \override Stem #'details #'beamed-extreme-minimum-free-lengths = #'(0.3 0.2) > I see a code dup for the covered grobs code in beam.cc and beam-quanting.cc. > I believe that this sort of thing can be brought into beam.cc without ever > being part of the quanting. Ideally, the covered grobs should extracted only > in beam.cc, and the quanting should be passed numerical information about the > results of these calculations rather than having to redo them. This will > allow you as well to have collision-related properties for the beams that, > when tweaked, will likely handle many of the results below. This would save a tiny amount of computation, with lots of extra complexity. Remember that all property computations are cached anyway, so there are few calculations really being redone. There could be an argument to collapse common code into a shared function, but not sure if that will be practical. Maybe you could try a patch to see if it makes sense. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen <><>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving the transition between full-length and shortenedstems. (issue4210051)
2011/2/28 Trevor Daniels > > Graham Percival wrote Monday, February 28, 2011 7:39 AM >> >> On 2/27/11, Janek Warchoł wrote: >>> >>> Here you are. This contains all the changes and should apply cleanly >>> to origin/master. >> >> Thanks, pushed. > > This commit causes many changes to the reg tests due to the small > increase in some of the stems that protrude beyond the staff. > Virtually all of the changes look good, but one struck me as undesirable. I should've checked this myself... Sorry for not doing this. > It is in cue-clef-begin-of-score.ly. Here the stems on the d full-size > notes seem undesirably lengthened. Is the clef change being > ignored here? I don't have access to my main machine so i cannot see new output for myself, but i can say that in this regtest all four notes should have longer stems now. In general, stems of the notes that are on the middle line will be longer now and it is desired behaviour. (until now it was too short, see attachment). cheers, Janek <>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving the transition between full-length and shortenedstems. (issue4210051)
Graham Percival wrote Monday, February 28, 2011 7:39 AM On 2/27/11, Janek Warchoł wrote: Here you are. This contains all the changes and should apply cleanly to origin/master. Thanks, pushed. This commit causes many changes to the reg tests due to the small increase in some of the stems that protrude beyond the staff. Virtually all of the changes look good, but one struck me as undesirable. It is in cue-clef-begin-of-score.ly. Here the stems on the d full-size notes seem undesirably lengthened. Is the clef change being ignored here? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: harmonics and slides (issue4186049)
LGTM http://codereview.appspot.com/4186049/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Extend Beam::shift_region_to_valid() to also take into account collisions. (issue4239047)
On Feb 27, 2011, at 11:27 PM, hanw...@gmail.com wrote: > On 2011/02/28 04:06:03, hanwenn wrote: >> There are two issues in the regtest: it gets confused by x-staff > beams, and it >> tries to avoid the start of staff clef when the beam crosses a line > breaks. > > fixed. > > http://codereview.appspot.com/4239047/ Several of the tests that I've been running work better with this new version - large collisions are now handled no problem. The only things that don't work properly are the organ example as well as the two attached examples. Is there any way to prevent the beam collision from pulling these up? If you suspect that the collisions below have to do with the minimum stem length, could you provide a regtest that shows this property being overrided & the correct result being achieved? I see a code dup for the covered grobs code in beam.cc and beam-quanting.cc. I believe that this sort of thing can be brought into beam.cc without ever being part of the quanting. Ideally, the covered grobs should extracted only in beam.cc, and the quanting should be passed numerical information about the results of these calculations rather than having to redo them. This will allow you as well to have collision-related properties for the beams that, when tweaked, will likely handle many of the results below. Cheers, MS <><>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: harmonics and slides (issue4186049)
Is it ok, now? Thanks, patrick http://codereview.appspot.com/4186049/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
doc-section.sh now uses ~/lilypond-git/
I've changed scripts/auxiliar/doc-section.sh to use ~/lilypond-git/ by default, since this was confusing some contributors and the change had snuck into a patch they were proposing. Sorry for the inconvenience if you use a different dir, but we should make it simple for beginners and standardizing on the directory is a good start. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOC: NR 1.5.2 Multiple voices - part combining (issue4188056)
http://codereview.appspot.com/4188056/diff/20001/scripts/auxiliar/doc-section.sh File scripts/auxiliar/doc-section.sh (right): http://codereview.appspot.com/4188056/diff/20001/scripts/auxiliar/doc-section.sh#newcode33 scripts/auxiliar/doc-section.sh:33: FROMDIR="$HOME/lilypond-git" I totally agree that this should be done, but please not in the same patch as doc stuff. I'll do this right now, separately. This might cause merge problems for you, but I think it'll be cleaner in the long run. http://codereview.appspot.com/4188056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: harmonics and slides (issue4186049)
I had to run scripts/makelsr.py before I could compile this patch. Please do the same, then do: git add Documentation/snippets/*.ly git commit . and upload a new patch. Other than that, LGTM. http://codereview.appspot.com/4186049/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: harmonics and slides (issue4186049)
Reviewers: Graham Percival, Message: Hi Graham, here is a revised patch. Cheers, patrick Description: harmonics and slides new patch # This will displayed on the codereview site. harmonics-and-slides-V include file for chord glissando harmonics-and-slides-IV new snippets harmonics-and-slides-III Revision of old patch Please review this at http://codereview.appspot.com/4186049/ Affected files: M Documentation/notation/fretted-strings.itely A Documentation/snippets/new/tablature-chord-glissando.ly A Documentation/snippets/new/tablature-fretted-string-harmonics.ly A Documentation/snippets/new/tablature-open-string-harmonics.ly A Documentation/snippets/new/tablature-slides.ly A ly/chord-glissando-init.ly ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: build failure for freebsd-x86 in beam-quanting.cc
On 2/28/11, Jan Nieuwenhuizen wrote: > Graham Percival schreef op ma 28-02-2011 om 09:35 [+]: >> /main/src/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily/beam-quanting.cc:638: >> error: 'round' was not declared in this scope >> >> I'm guessing that you need to explicitly include some other header >> because round() is in default in glibc but not in freebsd libc, or >> something like that? > > Eek, are we using floats? I guess so? if (abs (round(yshift) - yshift) < 0.01 * staff_space) config->add (parameters.HORIZONTAL_INTER_QUANT_PENALTY, "H"); Take a look at 15feba22d437b566333c8c948a5780ce40c5953f Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: build failure for freebsd-x86 in beam-quanting.cc
Graham Percival schreef op ma 28-02-2011 om 09:35 [+]: > /main/src/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily/beam-quanting.cc:638: > error: 'round' was not declared in this scope > > I'm guessing that you need to explicitly include some other header > because round() is in default in glibc but not in freebsd libc, or > something like that? Eek, are we using floats? Jan. -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
build failure for freebsd-x86 in beam-quanting.cc
/main/src/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily/beam-quanting.cc:638: error: 'round' was not declared in this scope I'm guessing that you need to explicitly include some other header because round() is in default in glibc but not in freebsd libc, or something like that? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Use Doc PO files for something (Was Fwd: [translations] Translation of "top" and broken link)
I'd like a bug to be open about this, if possible. Translated docs used to make all comments, context IDs and variable names in lilypond code to become translated from strings in Documentation/po/.po files. This does not work anymore and we are not able to determine when did stop working. Translate strings in a PO file is much more efficient than trying to keep texinfo files in sync, so we think Documentation PO files should serve for a purpose as they used to as told above. This is important because the documentation relies much on inline code comments and you can obtain a truly localized look and feel if this worked. Current 2.12 docs are fine wrt this. -- Forwarded message -- From: Jean-Charles Malahieude Date: 2011/2/27 Subject: Re: [translations] Translation of "top" and broken link To: Francisco Vila Cc: translati...@lilynet.net Le 27/02/2011 19:23, Francisco Vila disait : > > 2011/2/26 Jean-Charles Malahieude: >>> >>> Besides: does anyone know if we are using Documentation/po/*.po >>> files for anything useful? >>> >> >> It normally is used to localize variable names and comments in the >> snippets. > > When was the last time you checked this? I can not see comments or > variable names to appear in Spanish or French in bigpage NR (for > example; others not checked.) > > for example, fr.po has > > #. Documentation/extending/scheme-tutorial.itely:1354 (variable) > #. Documentation/learning/fundamental.itely:3003 (variable) > #. Documentation/learning/fundamental.itely:3058 (variable) > #. Documentation/notation/changing-defaults.itely:3802 (variable) > msgid "padText" > msgstr "decallageTexte" > > (l.334) > > but no decallageTexte around, only padText everywhere. > I don't understand what's happening. If you look at the stable version of the tutorial, you'll see that the snippets in "2.1.2 Simple notation" get translated. Too bad that I have not noticed when this got ineffective... Cheers, Jean-Charles -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: add [pagesize=xyz] option. (issue4239048)
Test case: foo.tely:
\input texinfo @node Top
@top
Texinfo text
@lilypond[papersize=a8]
\book{
\score {
\relative c' {
a4 b c d
a4 b c d
a4 b c d
a4 b c d
a4 b c d
a4 b c d
a4 b c d
a4 b c d
a4 b c d
a4 b c d
}
}}
@end lilypond
@bye
http://codereview.appspot.com/4239048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond-book: add [pagesize=xyz] option. (issue4239048)
Reviewers: ,
Message:
We've had a doc editor doing bugger-all for the past two weeks because
nobody cooked up this 8-line python patch.
Please review. I'm pushing it in 24 hours unless somebody screams.
Description:
lilypond-book: add [pagesize=xyz] option.
This will be *extremely* useful when writing
Notation 4 Spacing issues.
CG: add info about git rebase -i.
Please review this at http://codereview.appspot.com/4239048/
Affected files:
M python/book_snippets.py
Index: python/book_snippets.py
diff --git a/python/book_snippets.py b/python/book_snippets.py
index
a1b1328c575b4be2af6afe92c07d09183b9b1870..b7c3ddf0d67d369acfec84b3db605a54860b4db9
100644
--- a/python/book_snippets.py
+++ b/python/book_snippets.py
@@ -53,6 +53,7 @@ NOTIME = 'notime'
OUTPUT = 'output'
OUTPUTIMAGE = 'outputimage'
PAPER = 'paper'
+PAPERSIZE = 'papersize'
PREAMBLE = 'preamble'
PRINTFILENAME = 'printfilename'
QUOTE = 'quote'
@@ -112,6 +113,7 @@ snippet_options = {
##
PAPER: {
+PAPERSIZE: r'''#(set-paper-size "%(papersize)s")''',
INDENT: r'''indent = %(indent)s''',
LINE_WIDTH: r'''line-width = %(line-width)s''',
QUOTE: r'''line-width = %(line-width)s - 2.0
* %(exampleindent)s''',
@@ -553,6 +555,12 @@ left-margin-default right-margin-default)"
elif relative > 0:
relative_quotes += "'" * relative
+# put paper-size first, if it exists
+for i,elem in enumerate(compose_dict[PAPER]):
+if elem.startswith("#(set-paper-size"):
+compose_dict[PAPER].insert(0, compose_dict[PAPER].pop(i))
+break
+
paper_string = '\n '.join (compose_dict[PAPER]) % override
layout_string = '\n '.join (compose_dict[LAYOUT]) % override
notes_string = '\n '.join (compose_dict[NOTES]) % vars ()
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: dodecaphonic accidentals
On Sun, 27 Feb 2011 23:58:45 -0800, Graham Percival wrote: Did you intend to remove the dodecaphonic accidentals snippet from our docs? If so (i.e. it's been replaced with 2.13 functionality), then we needs some magic in Documentation/snippets/new/ . Yes; it was obsolete even in version 2.12. I had thought I had done the required magic; I'll compare with the example you pointed to. Also, 'engravers-one-by-one.ly' needs some magic, probably addition to Documentation/snippets/new. The manual convert-ly of that file changed only the version number. (Convert-ly is NOT_SMART enough to know that the custom contexts in that snippet work just fine with the new vertical spacing.) Patch on the way within about a day. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git rebase and gitk
On Sun, Feb 27, 2011 at 09:23:00PM +0100, Reinhold Kainhofer wrote: > Am Sonntag, 27. Februar 2011, um 21:03:35 schrieb Graham Percival: > > git rebase -i origin/master > > > > are there any dangers with that? > > That's why a do a "git rebase origin/master" (non-interactive) > first, where I only have to deal with those conflicts. Thanks, added to the CG. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
