Re: imprecise Taktlinie in german doc (NR)
-Eluze elu...@gmail.com writes: David Kastrup wrote: -Eluze elu...@gmail.com writes: yes, but the term Taktzahl is mainly found in technical contexts! I was talking about Taktzahlen. what's wrong about using the singular? That you'll get many more technical terms rather than musical. Let's see where this leads Google: Results for: taktzahlen # Musiksoftware Forum: Taktzahlen bei Sibelius One for me. is Sibelius the reference now? This is a _forum_, not the official documentation. If you allow only Lilypond references, you'll only get the previous documentation state. That's going in circles. # Ulrich Siegele: Taktzahlen als Ordnungsfaktor in Suiten- und ... Nontechnical, but measure count. yes, we are talking about measures! Sigh. That one was a point for _you_, namely measure _count_ rather than measure _number_. But you argue just as vividly against yourself than anybody else. # Research centre Beethoven-Archiv - [ Translate this page ] Sie vermuten ganz richtig, die Taktzahlen stammen nicht von den Komponisten, ... Taktzahlen wurden erst sehr spät im 19. Jahrhundert eingeführt. ... Point for me. no - you can't claim Beethoven as a protagonist since obviously he did not use Taktzahlen So if a Beethoven research center discusses musical terms, this does not count? And what makes you sure that Beethoven did not use Taktzahlen as a term? Because he was a Frenchman or what? Sorry, it does not appear like you actually are interested in arguing for the sake of getting the best documentation quality for Lilypond, but the worst discussion quality on the list. in a musical context it often means the number of measures which e.g. build a verse (in german: die (An-) Zahl (der) Takte Not really often. often enough For you to invent new terminology and have it disseminated by Lilypond? - and many meanings have disappeared or have been perverted because people did not really understand them; if a majority uses a word in a special meaning this does not mean other meanings are wrong! It is not Lilypond's documentation's task to invent new terms, regardless how nice they might be. It is the task to explain Lilypond in terms the user is familiar with. obviously you can say: Die Nummer des Taktes wird durch eine Zahl über dem Taktstrich angezeigt but not Die Nummer des Taktes wird durch eine Nummer über dem Taktstrich angezeigt. Uh, you are aware that you are arguing against your own proposal here? not really - here i just state that the number (Nummer) or the measure is referenced by a Zahl which implies that the Nummer/Takt is the higher context. this also means that the Takt or Taktnummer has a meaning by itself whereas the Zahl is nothing for itself. if you use the term Taktzahl you are on the wrong level, but still many would understand what is meant. Your argument does not make enough sense to analyze it. And again, you try to argue for some inherent superiority of your claim, not for its common established use. You are missing the point. I've also seen Taktziffern in composition competition rules, but that term makes my technical hide crawl, since its translation would be measure digits. Ziffern are strictly the letters 0 to 9. Wie hoch würden Sie den Schaden beziffern? nobody would limit this to a letter, in America they would claim for millions! beziffern means mit Ziffern versehen, not mit einer einzelnen Ziffer versehen. Ein Wort buchstabieren also does not mean that there is just a single letter for the whole word. anyway, thanks for this discussion! I have a hard time believing that you are serious. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
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 gra...@percival-music.ca 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 reinh...@kainhofer.com: 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 maximilian.alb...@googlemail.com: 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 reinh...@kainhofer.com: [...] 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 x.sche...@gmail.com ___ 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 2:31 PM, Karl Hammar k...@aspodata.se wrote: Carl Sorensen: On 5/13/10 2:08 PM, Karl Hammar k...@aspodata.se 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
