Re: Great Experience!
Am Donnerstag, 13. Mai 2010, um 06:38:42 schrieb Han-Wen Nienhuys: > Was the music font lily's feta font? The G-clef is a give-away, > because Feta's is quite unlike any other G-clef. Yes, it was the feta font. I just didn't think of the G-clef, but at some other peculiarities that I have experienced. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: imprecise Taktlinie in german doc (NR)
On Wed, May 12, 2010 at 09:35:26PM +0200, Henning Plumeyer wrote: > >I'm not an active musician, and only decades ago I did do music > >with others (orchestra, choir), so I may be wrong, but I've a strong > >feeling towards `Taktnummern'. It's less ambigous. > > I've been in hundreds of rehearsals and never heard the word Taktnummern, > only Taktzahlen. Then I'm probably wrong. As said, I'm not an active musician ;-) Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Critical issues
Issue 881: Arpeggios may collide with laissezVibrer ties According to the bug tracker, v2.11.19's output is what to aim for. Neil gave the fix: (define-public (laissez-vibrer::print grob) (ly:tie::print grob)) (then add laissez-vibrer::print to pure-print-callbacks) But he has not done a regtest check. /// How do one do a regtest? I remember there were discussion about this a while ago, but doing a quick search (regtest check lilypond) did not turn up anything useful, except [1] and [2]. [1] http://lilypond.org/doc/v2.13/Documentation/contributor/checking-and-verifying-issues [2] http://lilypond.org/test/ Perhaps it should be documented, maybe it already are. Doing "info ./Documentation/out/lilypond-contributor.info-1" I find: 8.1 Introduction to regression tests The regression tests are automatically compiled using special `make' targets. The output of the regression tests is also automatically So, what targets? The targets test* seems to have something with the regression directory to do, but I don't understand how to do a comparision to a known good set. . Do we have a known good set? . If so, how do I compare current output with it? Regards, /Karl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Critical issues
On Thu, May 13, 2010 at 10:06:45AM +0200, Karl Hammar wrote: > How do one do a regtest? Regression check; by compiling stuff. > 8.1 Introduction to regression tests > > The regression tests are automatically compiled using special `make' > targets. The output of the regression tests is also automatically > > So, what targets? They might be "make baseline-test", followed by applying a patch, followed by "make check", but I'm not certain. It's explained somewhere in Contributing 2. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ping Issue 931041: Fix #915 (faulty full-bar rest positioning with clef)
On Wed, May 12, 2010 at 10:57:05PM +0100, Neil Puttock wrote: > On 12 May 2010 15:59, Graham Percival wrote: > > Any chance that somebody could step in, make the required changes, and > > get it pushed? > > Is it holding up 2.14? ;) Not by itself; I was sending a reminder because the patch has been floating around for two weeks, and I didn't want it to get lost. I'll be sending semi-regular reminders about old patches. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Critical issues
Issue 815: Enhancement: AJAX-powered search auto-completion for the online documentation Issue 1038: more technical website items Theese two seem to be related to the web site, not to the released software. I can understand that it can be critical for the official site, but how can that be critical for the release ? Regards, /Karl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Where is the bug tracker?
On Wed, May 12, 2010 at 10:44:30PM +0200, Karl Hammar wrote: > Wouldn't it be nice to have a link to the bug tracker from > > http://lilypond.org/devel/ That website is (almost) deprecated; the new website is: http://lilypond.org/website/bug-reports.html Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Great Experience!
2010/5/13 Reinhold Kainhofer : > "Music engraving by LilyPond 2.12.3 -- www.lilypond.org > Engraver Gianluca D'Orazio -- his.em...@example.com" Gianluca has been active on the user's list since 2006 to 2008 approx. -- 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: Critical issues
On Wed, May 12, 2010 at 10:14:17PM +0200, Karl Hammar wrote: > *** > Issue 815: Enhancement: AJAX-powered search auto-completion for the online > documentation > Why is this a critical issue for the lilypond release? Because the patch has been hanging around for over a year. My decision on this isn't going to change, so discussion will not be fruitful. > *** > Issue 989: ensure that no information is only in the regtests > > Though Graham complain about this issue in the "report", > this seems to be taken by Valentin. He has a list at > http://wiki.lilynet.net/index.php/Regtests > > What to do about it? > Shall we discuss individual items on the list? We don't need discussion about this; we need patches. Stuff that should go in the main text should be added there. Stuff that should go in the snippets (i.e. tweaks and overrides) should be added there. There's information about the snippets somewhere in Contributing chapter 6. Documentation is chapter 4. Each item should only take 5 minutes or so, once you know how to add snippets or modify the documentation. Pick one of the items at random and send a patch here for discusion. (err, the first sentence in this part should be "we don't need more vague discussion; we need discussion about specific patches") > *** > > Issue 1031: constantly-changing input/regression/rest-collision-beam-note.ly > > If it is changes every time, what is the correct output? One of the two possible outputs has either a collision between rest and beam, or a very near collision. The other one clearly has no collision at all. I'd rather go with the "no collision at all", but if we can consistently get the "almost-collision" version (and can't consistently get the "no collision at all" version), then I'll consider this issue fixed. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: imprecise Taktlinie in german doc (NR)
Am 12.05.2010, 23:36 Uhr, schrieb Maximilian Albert : Same here. :) Although in a rehearsal one would usually just say something like "in Takt ..." instead of using a construction involving "Taktzahlen". Yes, right. "Conductor: Again from bar five please. Voice from back of viola section: But Maestro, we have no bar numbers." would translate to: "Dirigent: Nochmal von Takt fünf, bitte! Stimme aus der Bratschengruppe: Aber wir haben keine Taktzahlen." Henning ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Critical issues
On Thu, May 13, 2010 at 09:41:47AM +0200, Karl Hammar wrote: > Issue 815: Enhancement: AJAX-powered search auto-completion for the online > documentation > > Issue 1038: more technical website items > > Theese two seem to be related to the web site, not to the released > software. I can understand that it can be critical for the official > site, but how can that be critical for the release ? It's critical for the release because I say so. I want the new website ready for 2.14.0. (I'm not being childish about this; the website is built from the main source, so any major changes to the technical side of the website may involve changes to the lilypond build system. It makes sense to get it all sorted out before 2.14. But if it cuts out any pointless debate about this, then consider my answer to simply be "because I say so".) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Great Experience!
2010/5/13 Reinhold Kainhofer : > > [...] > > And then I got the final page, and there it was: > > "Music engraving by LilyPond 2.12.3 -- www.lilypond.org > Engraver Gianluca D'Orazio -- his.em...@example.com" > > WOW! You can't image what it feels like to be surprised like this in > such a prefessional surrounding! I mean, that is the application we > are all working on. And as this example shows, LilyPond can not only > compete at this topmost level, it really beats anything else! Yeah, that's great! I'm far for being an expert in music engraving but as a musician I have to play on so many scores that do not feel "pleasant" to read. I think it is due to these largely used softwares and to these publishers that do not seem to consider their customers and do not take care of the "beauty" of the scores they produce. So it's always good news to hear that some people still think at the ones who will read their scores and do nice engraving (and even better if they are using LilyPond to this). @Reinhold: Did you contact the author? Do you know if he has planned to provide this score on a site like Mutopia or IMSLP? That would be even *more* "PERFECT"! ;) (and by the same way we would be able to see this perfect score)... > So, Kudos to you all who worked on LilyPond and made it into the > professional engraving application it is now! Yes, Kudos. Let's hope LilyPond's engraving quality will be more and more recognized, LilyPond more and more used (and also by some "well-known" music publishers), so musicians would have more quality scores! Thanks everybody, Xavier -- Xavier Scheuer ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond 2.13.21 released [correction]
On 05/12/2010 12:32 PM, Graham Percival wrote: [the previous announcement stated ".12" instead of ".21"] We are happy to announce the release of LilyPond 2.13.21. This release contains the usual number of bugfixes. However, a number of critical issues still remain, so this release is intended for developers only. Thanks!! I use the development version for all my work (at my own risk). This release should be of particular interest to package maintainers: we have made a few changes to the configure script and the required libraries. Barring any urgent bug reports, this is the build system and libraries that will be used for the next stable release. download.linuxaudio.org seems to be unavailable at the moment. Paul Scott ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Critical issues
Graham: > On Thu, May 13, 2010 at 10:06:45AM +0200, Karl Hammar wrote: > > How do one do a regtest? > > Regression check; by compiling stuff. > > > 8.1 Introduction to regression tests > > > > The regression tests are automatically compiled using special `make' > > targets. The output of the regression tests is also automatically > > > > So, what targets? > > They might be "make baseline-test", followed by applying a patch, > followed by "make check", but I'm not certain. It's explained > somewhere in Contributing 2. Ok, found something in "3.6.3 Testing LilyPond" (though nothing in the chapter on regression tests). * Initial test: make [-jX] make test-baseline make [-jX CPU_COUNT=X] check * Edit/compile/test cycle: _## edit source files, then..._ make clean_## only if needed (see below)_ make [-jX]_## only if needed (see below)_ make test-redo_## redo files differing from baseline_ make [-jX CPU_COUNT=X] check _## CPU_COUNT here?_ Hmm, the make check seems redundant since test-redo already does it: $ find . -name GNUmakefile | xargs grep -A 10 test-redo ... ./GNUmakefile:test-redo: ./GNUmakefile- for a in `cat $(RESULT_DIR)/changed.txt` ; do \ ./GNUmakefile- echo removing $$a* ; \ ./GNUmakefile- rm -f $$a* ;\ ./GNUmakefile- done ./GNUmakefile- $(MAKE) check ... ./scripts/build/out/output-distance seems to be the workhorse of the regression tests. I cannot find any useful documentation of it with: find . -type f | xargs grep output-distance except the source code itself. But if I already have a known good result from the code tracker, how do I compare it with the new result? Regards, /Karl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Critical issues
On Thu, May 13, 2010 at 09:11:18PM +0200, Karl Hammar wrote: > Graham: > > They might be "make baseline-test", followed by applying a patch, > > followed by "make check", but I'm not certain. It's explained > > somewhere in Contributing 2. > > Ok, found something in "3.6.3 Testing LilyPond" (though nothing in the > chapter on regression tests). Known problem, sadly. We even lack the developer resources to adequately maintain the manual which aims to increase our developer resources. Also, you might want to ignore me and wait for other people to comment, since I've never tested patches with a regtest comparison. > But if I already have a known good result from the code tracker, > how do I compare it with the new result? Well, if you have a short piece of input code, and a good picture, then you could just do lilypond -dpreview bug-example.ly and then look at the resulting bug-example.preview.png (or use lilypond --png if it's a multi-line example) If I were working on a single .ly file, I'd just compare the two versions by eye, rather than trying to use any automatic tool. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Critical issues
On 5/13/10 1:11 PM, "Karl Hammar" wrote: > Graham: >> On Thu, May 13, 2010 at 10:06:45AM +0200, Karl Hammar wrote: >>> How do one do a regtest? >> >> Regression check; by compiling stuff. >> >>> 8.1 Introduction to regression tests >>> >>> The regression tests are automatically compiled using special `make' >>> targets. The output of the regression tests is also automatically >>> >>> So, what targets? >> >> They might be "make baseline-test", followed by applying a patch, >> followed by "make check", but I'm not certain. It's explained >> somewhere in Contributing 2. > > Ok, found something in "3.6.3 Testing LilyPond" (though nothing in the > chapter on regression tests). > >* Initial test: > > make [-jX] > make test-baseline > make [-jX CPU_COUNT=X] check > >* Edit/compile/test cycle: > > _## edit source files, then..._ > > make clean_## only if needed (see below)_ > make [-jX]_## only if needed (see below)_ > make test-redo_## redo files differing from > baseline_ > make [-jX CPU_COUNT=X] check _## CPU_COUNT here?_ > > Hmm, the make check seems redundant since test-redo already does it: > > $ find . -name GNUmakefile | xargs grep -A 10 test-redo > ... > ./GNUmakefile:test-redo: > ./GNUmakefile- for a in `cat $(RESULT_DIR)/changed.txt` ; do \ > ./GNUmakefile- echo removing $$a* ; \ > ./GNUmakefile- rm -f $$a* ;\ > ./GNUmakefile- done > ./GNUmakefile- $(MAKE) check > ... > > ./scripts/build/out/output-distance seems to be the workhorse of the > regression tests. I cannot find any useful documentation of it with: > > find . -type f | xargs grep output-distance > > except the source code itself. > > But if I already have a known good result from the code tracker, > how do I compare it with the new result? What do you mean by "if I already have a known good result from the code tracker"? make test-baseline followed by make check will do exactly what you want. You should then have, as described in Contributors' 3.6.3, a file out/test-results/index.html that shows the results of the regression tests. If the only snippet listed in out/test-results/index.html is output-distance.ly, then that means you haven't broken any previous regressions. output-distance.ly is a snippet that has random content, so it will change every time it's run. That means that you will *always* get a difference when you run the regression tests. Ideally, in this case, you'd see changes in output-distance.ly. And you'd add a regression test for the current bug, so there would also be an entry for the current bug. Other than that, it would say that there is a large number of snippets with no differences. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Critical issues
Carl Sorensen: > On 5/13/10 1:11 PM, "Karl Hammar" wrote: ... > > But if I already have a known good result from the code tracker, > > how do I compare it with the new result? > > What do you mean by "if I already have a known good result from the code > tracker"? In http://code.google.com/p/lilypond/issues/detail?id=1080 there is a grace-start-good.png . > make test-baseline > > followed by > > make check ... I understand that I could possible go back to 2.13.17, do the make's, jump to current git and make test-redo. But if the "old good" png is already available, then I see the possibility to skip the "go back to..." step. Regards, /Karl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Critical issues
On 5/13/10 2:08 PM, "Karl Hammar" wrote: > Carl Sorensen: >> On 5/13/10 1:11 PM, "Karl Hammar" wrote: > ... >>> But if I already have a known good result from the code tracker, >>> how do I compare it with the new result? >> >> What do you mean by "if I already have a known good result from the code >> tracker"? > > In http://code.google.com/p/lilypond/issues/detail?id=1080 there is a > grace-start-good.png . > >> make test-baseline >> >> followed by >> >> make check > ... > > I understand that I could possible go back to 2.13.17, do the make's, > jump to current git and make test-redo. It's not necessary to go back to 2.13.17. All that is needed to do is to get the current git master, build it, and run make test-baseline. Then apply the patch, and run make check. > > But if the "old good" png is already available, then I see the > possibility to skip the "go back to..." step. There are two separate issues: 1) Does the patch solve the problem? This issue is tested by simply running the sample file on the tracker to see if the output goes to the desired state. 2) Does the patch cause any other problems? This can only be answered by running the complete regression test suite. IIUC, Neil's patch was already demonstrated to meet issue 1. But issue 2 was not yet checked. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Critical issues
Carl Sorensen: > On 5/13/10 2:08 PM, "Karl Hammar" wrote: ... > > In http://code.google.com/p/lilypond/issues/detail?id=1080 there is a > > grace-start-good.png . ... > IIUC, Neil's patch was already demonstrated to meet issue 1. But issue 2 > was not yet checked. Are you mixing this up with http://code.google.com/p/lilypond/issues/detail?id=881 Regards, /Karl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Critical issues
On 5/13/10 2:31 PM, "Karl Hammar" wrote: > Carl Sorensen: >> On 5/13/10 2:08 PM, "Karl Hammar" wrote: > ... >>> In http://code.google.com/p/lilypond/issues/detail?id=1080 there is a >>> grace-start-good.png . > ... >> IIUC, Neil's patch was already demonstrated to meet issue 1. But issue 2 >> was not yet checked. > > Are you mixing this up with > > http://code.google.com/p/lilypond/issues/detail?id=881 > Oops! It was another issue I was mixing it up with. I'm sorry. But we still need to check both issues for every patch. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: completion disturbed by other staff (issue 1082)
hi all, attached a patch fixing the issue. the cause of the problem was note_dur being less than left_to_do_, as noted in the comment I added. the fix itself is the following part: - if (nb.main_part_ && nb < note_dur.get_length ()) + if (nb.main_part_ && nb < left_to_do_) the remaining bit simplifies initialisation of left_to_do_ while also puts it early enough to be used in the changed condition. p patch13 Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Notes on #1036
Hello, Just to prevent that my tiny advances on #1036 get lost, here are my random notes on the issue. Those notes are very messed but after a rest my head will surely understand certain things a bit more clearly. http://wiki.lilynet.net/index.php/Issue1036 -- 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: completion disturbed by other staff (issue 1082)
hi all, updated the patch fixing the issue and attached an example where the previous version failed. > the cause of the problem was note_dur being > less than left_to_do_, as noted in the comment I added. > > the fix itself is the following part: > - if (nb.main_part_ && nb < note_dur.get_length ()) > + if (nb.main_part_ && nb < left_to_do_) the condition is reverted to the original, but do_nothing_until_ is set unconditionally. > the remaining bit simplifies initialisation of left_to_do_ > while also puts it early enough to be used in the changed condition. > > p > patch14 Description: Binary data patch15 Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Critical issues
Joe Neeman schrieb:
On Wed, 2010-05-12 at 22:14 +0200, Karl Hammar wrote:
Issue 1080: Regression: bar lines in double bar are positioned too
close together
"pnorcks" mentions commit 27a4d9354effb09c696925881ec4df007da8a0db
as a possible cause. Reverting part of that commit:
gives me the attached grace-start result which resembles the 2.13.17
result presented in the bug tracker.
What should we do about it?
I'd suggest we check with Marc Hohl to see what the intent of that
change was. I suspect that it was an attempt to change how \bar "||" is
aligned so that it lines up better with the new segno barline.
Yes, that's right.
If I'm
right, though, then Marc misunderstood the last parameter to
Stencil::add_at_edge, and the correct code would be
m.add_at_edge (X_AXIS, LEFT, thin, thinkern / 2);
m.add_at_edge (X_AXIS, RIGHT, thin, thinkern);
Oh, I see. Yes, I misunderstood the spacing - I asked about that subject
while working on the segno patch, but no-one told me I was wrong here
(or I have missed something important).
Sorry for this, and thanks to Karl for pointing this out and to Joe for
giving the right solution. I attached a patch which does the right thing.
Thanks,
Marc
Cheers,
Joe
From 15b2103f19fe92c03a6f423cc93ac51e97f0a113 Mon Sep 17 00:00:00 2001
From: Marc Hohl
Date: Fri, 14 May 2010 08:21:03 +0200
Subject: [PATCH] Issue 1080: corrected spacing in double bar lines
---
lily/bar-line.cc |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lily/bar-line.cc b/lily/bar-line.cc
index d3f21e5..a00dc0e 100644
--- a/lily/bar-line.cc
+++ b/lily/bar-line.cc
@@ -200,7 +200,7 @@ Bar_line::compound_barline (Grob *me, string str, Real h,
m.add_at_edge (X_AXIS, RIGHT, thin, thinkern);
*/
m.add_at_edge (X_AXIS, LEFT, thin, thinkern / 2);
- m.add_at_edge (X_AXIS, RIGHT, thin, thinkern / 2);
+ m.add_at_edge (X_AXIS, RIGHT, thin, thinkern);
}
else if (str.find ("S") != NPOS || str == "|._.|")
{
--
1.5.4.3
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
