Re: CG: out-of-tree building in main compile chapter. (issue3823045)
No complaints? I'll go ahead and push it in 24 hours if nobody objects or asks for more time. (you don't need to have any specific objections; if you're busy and can't review it for the next few days, but want to review it, just let me know and I'll wait) http://codereview.appspot.com/3823045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix Issue 1290 (issue3832046)
On 2011/01/04 01:46:45, Keith wrote: For a 2-staff system (with non-protruding bass clefs to make the math easier) the patch computes minimum_distance 3.05, 7.33, 29.41, 29.38 as it adds four systems to a page. Can you send me a test file so I can check it out? Thanks, Carl http://codereview.appspot.com/3832046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix Issue 1290 (issue3832046)
The new patch fixes the issue, but we can't yet use it in larger scores, if we want to do that. Whenever there is more than one staff in a system, and any non-zero skyline-horizontal-padding, minimum_distance is computed reasonably for the first and second systems, but not the third and later. For a 2-staff system (with non-protruding bass clefs to make the math easier) the patch computes minimum_distance 3.05, 7.33, 29.41, 29.38 as it adds four systems to a page. http://codereview.appspot.com/3832046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Optical spacing fails at tight situations
On Dec 30, 2010, at 12:48 PM, Janek Warchoł wrote:
> Hi,
>
> didn't find it in the tracker so i report:
> optical spacing doesn't work as expected in the following situation:
>
> \version "2.13.43"
> \new Score {
> \repeat unfold 12 { c''16 [ d'' b' c'' ] \noBreak }
> }
>
> All 16ths are spaced equally, while the distance betwwen d and b
> should be smaller. When notes are not so tight, it works as expected,
> try
>
> \version "2.13.43"
> \new Score {
> \repeat unfold 8 { c''16 [ d'' b' c'' ] \noBreak }
> }
>
> yours Pondly,
> Janek
Is this unexpected behavior? Does the ragged-right or /noBreak affect this?
Clearly the difference is there. My question is, is it a feature, or a bug?
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
what's up with optimal-page-breaking-hstretch.ly
Compiling this with 2.12.3 and 2.13.45 yields (to my eye) rather different results. I personally cannot tell if the systems are horizontally stretched or not. They appear to be centered. Or should this illustrate that only the systems on the first page are vertically stretched? Regardless, in 2.13, only one system is on the second page, so I don't think any ragged settings will be obviously apparent. Am I completely off here? Can someone explain what I should be seeing, and then we can work out if it is displaying correctly. Thanks, James___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond logging (Re: lilypond too noisy on the cmd line)
On Mon, Jan 03, 2011 at 06:16:08AM -0500, David Santamauro wrote: > The first thing that jumps out at me is Apache log4cxx. It is a robust > logging framework based on Java log4j. It introduces dependencies on > the apache portable runtime library That together makes 29708 lines of code just for logging, only including the unix specific parts of apr and not including tests, examples and build stuff (and not including comments, lines with only single opening or closing braces etc.). The (C++) parts of LilyPond in contrast have 53860 lines of code using the same counting script. Lines of code for the OpenBSD syslogd: 2226. And for the client parts, i.e. syslog(3) & friends: 232. So, ignoring any potential licensing issue between the apache stuff and the GPLv3 for now, log4cxx doesn't look appropriate by mere size. > The opposite end of the spectrum, is a much simpler logging class that > I cook myself based on syslogd. It is controlled by command-line > argument (--level | -l), exists as a global object and exposes the > traditional methods: > error() > warn() > notice() > info() > etc... Just keep it as simple as possible. And as unconfigurable as possible (use sane default settings). For LIlyPond, I don't even see any need for ditinquishing between notice() and info(). Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 879
Is about knees, crossing staves, and the RemoveEmptyStaff command. It took
me to engraver-init.ly where I found:
RemoveEmptyStaves = \with {
\remove "Axis_group_engraver"
\remove "Hara_kiri_engraver"
\consists "Hara_kiri_engraver"
\override Beam #'auto-knee-gap = #'()
\override VerticalAxisGroup #'remove-empty = ##t
}
I know I don't properly understand this stuff still, but doesn't the
\consists re-instate the previously removed engraver on the line above?
--
Phil Holmes
Bug Squad
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Change stringTunings entries from semitones to pitches (issue3842041)
For the Doc/Notation/fretted-strings.itely - that looks good. I can't comment on the rest. http://codereview.appspot.com/3842041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix Issue 1290 (issue3832046)
I've made the changes, and now the patch actually works.
Thanks all for your comments!
Carl
http://codereview.appspot.com/3832046/diff/2001/lily/page-layout-problem.cc
File lily/page-layout-problem.cc (right):
http://codereview.appspot.com/3832046/diff/2001/lily/page-layout-problem.cc#newcode266
lily/page-layout-problem.cc:266: Page_layout_problem::append_prob (Prob
*prob, Spring const& spring, Real padding)
On 2011/01/02 23:09:02, Keith wrote:
This function is not called for either of our test cases.
Yes, I guess this is called for adding a prob that is not a system. So
I'm removing the code here.
http://codereview.appspot.com/3832046/diff/2001/lily/page-layout-problem.cc#newcode274
lily/page-layout-problem.cc:274: minimum_distance = (*sky)[UP].distance
(bottom_skyline_, scm_to_double (prob->get_property
("skyline-horizontal-padding")));
On 2011/01/02 05:19:58, joeneeman wrote:
robust_scm2double is probably better
removed (see above)
http://codereview.appspot.com/3832046/diff/2001/lily/skyline.cc
File lily/skyline.cc (right):
http://codereview.appspot.com/3832046/diff/2001/lily/skyline.cc#newcode396
lily/skyline.cc:396: if ((i->slope_ == 0) && !isinf (i->y_intercept_) &&
i->y_intercept_ >= 0)
OK, I got it to work properly now. I have a better algorithm for
handling the bottom of the extracted box.
http://codereview.appspot.com/3832046/diff/2001/lily/skyline.cc#newcode398
lily/skyline.cc:398: Interval (i->y_intercept_ < 0 ? i->y_intercept_ : 0
, i->y_intercept_)));
Now I handle the y_intercept_ < 0 problem properly here.
http://codereview.appspot.com/3832046/diff/2001/lily/skyline.cc#newcode399
lily/skyline.cc:399: Skyline padSky = Skyline (boxes, horizon_padding,
a, (Direction) 1);
Using sky_ now.
http://codereview.appspot.com/3832046/diff/2001/lily/skyline.cc#newcode498
lily/skyline.cc:498: const Skyline *padded_other = &other;
On 2011/01/02 05:19:58, joeneeman wrote:
I'm not sure, but I think "Skyline const *" is more consistent with
the rest of
the code.
Done.
http://codereview.appspot.com/3832046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Updates to bagpipe.ly
Sven Axelsson-3 wrote:
>
> I am the author of the bagpipe.ly mode included in the Lilypond
> distribution. I'm sorry I haven't been very visible here the last
> several years. I haven't had much user feedback for the bagpipe mode,
> although I know there are people out there using it.
Hi Sven. You are right, there are people out there using it, and I'm one of
them. Thanks very much for making it easy to engrave bagpipe music with
Lilypond! (I'm not a very advanced Lilypond user, so I can't comment much on
your actual questions about default layout tweaks. I can say that I never
mix bagpipe and non-bagpipe scores, so personally, I'm fine with doing as
much as you like by default.)
Perhaps a starting point would be if someone could have a look at what
> I'm doing in https://github.com/svenax/bagpipemusic/. The relevant
> file is bagpipe_new.ly, and there are lots of examples on how to use
> it in the repo as well.
Actually, I was looking for a newer version of bagpipe.ly when I found this
thread. Specifically, I was entering a piece that included an embellishment
that I couldn't find in bagpipe.ly: it's a lot like a d doubling, but goes
to c instead of e. I'm not sure what it's called, maybe just an alternate d
doubling? Anyway, I couldn't find it, so for now I've just put it in
manually as "\grace { \small g32[ d c] }", but it would be nice if this
could be added to future versions of bagpipe.ly (or perhaps a macro to make
it easier to define custom embellishments?) Sorry, I can't help with a
suggestion for what to call it, since I have no idea myself.
The new mode is not backwards compatible with the old one, so I would
> have to include some convert-ly rules if approved. Or perhaps it could
> actually be included as bagpipe_new.ly, not replacing the old one.
I did notice when I dropped in bagpipe_new.ly and updated my \include
statements to include the new file that \hideKeySignature was gone. (I
always use this, since I don't see much point in showing the key signature.)
I removed \hideKeySignature, and re-engraved my scores, and noticed that all
of my cs and fs had sharp symbols next to them... not good. I looked at some
of the examples in your git repository and found that \bagpipeKey was what I
wanted, but other than that, I didn't notice any other compatibility issues.
Might I suggest including a definition for \hideKeySignature that just does
\bagpipeKey, for easy backwards compatibility? If the remaining
compatibility issues are as minor as this, maybe you won't need to call it
bagpipe_new. (Or maybe that's the point of your convert.ly rules? I guess
that would be a reason for me to explicitly use version numbers in my input
files.)
Anyway, the new spacings look nice; thanks for bagpipe.ly!
--
View this message in context:
http://old.nabble.com/Updates-to-bagpipe.ly-tp30558430p30572835.html
Sent from the Gnu - Lilypond - Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
- Original Message - From: "Graham Percival" To: "Phil Holmes" Cc: Sent: Monday, January 03, 2011 3:15 AM Subject: Re: critical issues On Sun, Jan 02, 2011 at 04:37:35PM -, Phil Holmes wrote: " Priority-Critical: LilyPond segfaults, a regression (see below) against a previous stable version or a regression against a fix developed for this version. This does not apply where the "regression" occurred because a feature was removed deliberately - this is not a bug. " I'm not certain what "regression against a fix developed for this version" means. If somebody fixes a minor bug in 2.13.15, and that fix doesn't work in 2.13.17, I don't think that should be a Critical bug. If the fix works in 2.14.0 but doesn't work in 2.14.2 or 2.15.2, then I _would_ consider that a critical bug, under the usual "regression against the past two stable versions" rule. That was new wording I was under the impression we'd agreed the last time this was discussed. You said "I can't tell if there was a difference here from the current version, but this looks fine." My intention was that, even if it was a minor bug, then someone had put work in recently to fix it. If someone else has just unpicked that, then this a Bad Thing and should be corrected. At the bottom of this section, add: " Note that these are initial classifications and can be subject to change by others in the development team. For example, a regression against an old stable version which hasn't been noticed for a long time and which in unlikely to get fixed could be downgraded from Priority-Critical by one of the programmers. " This means that the "regression since the last two stable versions" becomes an ad-hoc programmer decision, rather than an official policy decision. Couldn't we keep the "for example, while developing 2.13, any regression since 2.12.x or 2.10.x counts as a critical issue" sentence? I think that one sentence with exact numbers would provide much more clarity than terms like "this version" or "previous two stable versions". On December 30 you said: "In particular, I'd fine telling / expecting bug squad members to make something Critical if it's a regression, period. Just as long as a programmer can come by and say "wait, we broke that back in 2005... sure, it's still a bug, but we're not going to delay a stable release for it. I'm setting it to priority-medium"." My wording reflects that? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Regtests for 13.45
A few minors things to report. In page-breaking-page-count3.log there are 4 extra lines reporting problems: "programming error: number of pages is out of bounds continuing, cross fingers programming error: tried to space systems on a bad number of pages continuing, cross fingers" The flags on semiquavers are consistently very slightly different - see the attached inflated image. I'd be surprised if this is a problem, but it does look like a deliberate change. The change to fix 1465 are shown as different pages in 13.45 - this is correct behaviour. That's it, so far as I can see. -- Phil Holmes Bug Squad <>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond logging (Re: lilypond too noisy on the cmd line)
On Sun, 2 Jan 2011 15:47:01 +0100 "Bertalan Fodor (LilyPondTool)" wrote: > You should consider using a proper logging framework with different > logging levels. > The first thing that jumps out at me is Apache log4cxx. It is a robust logging framework based on Java log4j. It introduces dependencies on the apache portable runtime library as has Apache License v2.0, which states: "[...] is a license that is supposed to be compatible with other open source licenses, while remaining true to the original goals of the Apache Group and supportive of collaborative development across both nonprofit and commercial organizations. The Apache Software Foundation is still trying to determine if this version of the Apache License is compatible with the GPL." The opposite end of the spectrum, is a much simpler logging class that I cook myself based on syslogd. It is controlled by command-line argument (--level | -l), exists as a global object and exposes the traditional methods: error() warn() notice() info() etc... Any other recommendations in the middle? David ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Updates to bagpipe.ly (issue3825043)
On Mon, Jan 03, 2011 at 10:26:20AM +0100, Sven Axelsson wrote: > The latest patch attached. Thanks, pushed. It'll appear in 2.13.46. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Updates to bagpipe.ly (issue3825043)
On 3 January 2011 10:12, Graham Percival wrote: > On Mon, Jan 03, 2011 at 09:52:58AM +0100, Sven Axelsson wrote: >> On 3 January 2011 00:39, wrote: >> > LGTM, could you send me a patch to apply? (git format-patch origin) >> > >> > http://codereview.appspot.com/3825043/ >> >> The patches are downloadabe from Rietveld. > > But unfortunately not with your name, email address, and commit > message -- they're raw patches only. I think it's nice to give > you credit for this work, so please do a "git format-patch origin" > and send me the patch. You mean in order to put the blame on me :) The latest patch attached. Thanks a lot. -- Sven Axelsson ++[>++>+++>++>++ ><-]>.+..>+.>+.<<-.>>+.>.<<. +++.>-.<<++.>>.<++.>>>++..>>.<. 0001-Spacing-tweaks-and-new-gracenotes.patch Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Updates to bagpipe.ly (issue3825043)
On Mon, Jan 03, 2011 at 09:52:58AM +0100, Sven Axelsson wrote: > On 3 January 2011 00:39, wrote: > > LGTM, could you send me a patch to apply? (git format-patch origin) > > > > http://codereview.appspot.com/3825043/ > > The patches are downloadabe from Rietveld. But unfortunately not with your name, email address, and commit message -- they're raw patches only. I think it's nice to give you credit for this work, so please do a "git format-patch origin" and send me the patch. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Updates to bagpipe.ly (issue3825043)
On 3 January 2011 00:39, wrote: > LGTM, could you send me a patch to apply? (git format-patch origin) > > http://codereview.appspot.com/3825043/ > The patches are downloadabe from Rietveld. -- Sven Axelsson ++[>++>+++>++>++ ><-]>.+..>+.>+.<<-.>>+.>.<<. +++.>-.<<++.>>.<++.>>>++..>>.<. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
