wikipedia...
Hi there, Triggered by recent wikipedia messages, I had a peek at our http://en.wikipedia.org/wiki/Lilypond page and found it still has the weird (long and not very impressive) fire breathers example. Why the .ly at all, better show impressive output and move .ly example to a LilyPond_Language page? Also, there are some pieces by Han-Wen from 2006 on the talk page http://en.wikipedia.org/wiki/Talk:GNU_LilyPond quotes below. Can someone other than Han-wen or me take care of this? Possibly it's no wonder that wikipedia doesn't use lilypond, considering that our article on wikipedia is so bad? Greetings, Jan. Hi, I take issue with While it has achieved this, the quality of output from competing commercial packages has improved since the inception of the LilyPond project so that they are now comparable because it implies that LilyPond can be considered "done" from a typographical POV (which it isn't, IMO). Furthermore, "comparable" is a vague statement: mosquitos and elephants are comparable, and the result of the comparison is that the elefant is bigger. Esthetics aren't well defined, but most printout of Finale and Sibelius still (we're speaking 2006) looks made with a computer. I think I am not the right person to edit the page itself, though. Han-Wen (LilyPond Author). and also I don't own licenses to either Finale or Sibelius, so I can't provide you with any specific samples, but I've seen both in action. I think that pointing out weaknesses of other packages should not be done on the LilyPond page, but rather on the pages of said packages. I think it's better to point out what sets apart Lily, as this is more informative and more objective, eg * optical scaling for font: depending on staff size, the design of the font is altered slightly. (This is a Feature that Knuth's Comupter Modern font is well known for too): note heads become rounder, and lines heavier. * Optical spacing (see the essay), where stem directions are taken into account for spacing subsequent notes. Note that this is something different from the inaccurately named Optical (tm) Spacing feature of Sibelius. * Proportional spacing, where allotted space is exactly equal to durations. No other packages support this out of the box. (you need a recent 2.7 lily, though) * Ledger lines that never collide, but are shortened in tight situations. * Stem directions on the center follow the directions of surrounding notes. (recent 2.7) Also, in general, LilyPond does much better on automatically avoiding collisions for ties, slurs, articulation marks, nested tuplets, etc.. For example, if you add an arpeggio to a chord in Finale, Finale just parks it on top of the accidentals, you have to manually tweak things to look ok. Han-Wen Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Naming output files - status update please?
Hi all, I've been prompted by a reply from Mats on the -user list. >See >http://lists.gnu.org/archive/html/lilypond-user/2009-02/msg00833.html >and follow-ups for the previous discussion on the topic. As far as I >can see, an implementation proposal is already available, just to >commit. > I know Marek Klein did a lot of work on this and developed Scheme code to use an alist for the output-file name. I know from the messages that he was talking about amending regression tests and things. Carl, Valentin, did this ever get as far as a patch, or do we need a frog to undertake the actual packaging to produce it? If anyone has any more information please let me know so I can see about taking this on (if it needs doing). Cheers, Ian ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: wikipedia...
2009/6/4 Jan Nieuwenhuizen : > Op donderdag 04-06-2009 om 11:08 uur [tijdzone +0200], schreef Francisco > Vila: > >> First thing we can do, given that the talk section is intended to >> improve the article, is to write down these objections in it. > > Well, that's what Han-Wen did in 2006. Nothing happened. I'd say: > be bold and fix it first. I have freshened the Spanish wikipedia LilyPond page a little bit. This is the most time-consuming task you can face. After a rest I could try translating it into English, sooner or later. -- Francisco Vila. Badajoz (Spain) www.paconet.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
LSR update policies, and WTM is input/new/revised/ ?
If you're involved with LSR, check out the LSR update docs in the CG on kainhofer in a day or so; please make corrections. Could somebody process the files in input/new/revised/ ? And why do we need this directory, anyway? Shouldn't those files just be dumped into input/new/ ? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond 2.13.1 up
Han-Wen Nienhuys wrote: On Wed, Jun 3, 2009 at 3:04 PM, Patrick McCarty wrote: Yes, I was testing the GUB binary at lilypond.org. I have just confirmed the problem on 64-bit GNU/Linux too. The problem seems to be exactly what the error message reports: there is no file gs_init.ps located in the installation directory. I already know what is wrong. I'll try to push a new release tonight. (I found this bug on XP and fixed it there. I was assuming that the Gub3 checksumming would rebuild the installers automatically, but that was naive.) With 2.13.1 on Debian sid I get: Converting to `./asthedeertenor.pdf'... `gs -q -dSAFER -dDEVICEWIDTHPOINTS=612.00 -dDEVICEHEIGHTPOINTS=792.00 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite -sOutputFile="./asthedeertenor.pdf" -c .setpdfwrite -f "asthedeertenor.ps"' failed (256) Paul Scott ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Make some local functions public (was: Re: lily-library.scm question)
On Sat, May 30, 2009 at 1:08 AM, Mark Polesky wrote: > Patrick McCarty wrote: >> I don't know if there is any performance penalty, but it's probably >> negligible. You could propose that these procedures be made public; I >> am okay with it. > > Then if no one has any reservations, does anyone want to apply this? The patch looks good to me. The "print-book-with" procedure is pretty specialized, but I don't see any harm in making it public. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB on kainhofer: still cross/gcc
In message <200905312229.35014.reinh...@kainhofer.com>, Reinhold Kainhofer writes Am Sonntag, 31. Mai 2009 21:22:41 schrieb Jan Nieuwenhuizen: Op zaterdag 30-05-2009 om 22:46 uur [tijdzone -0700], schreef Graham Percival: > Any more tips? I'd really like to get this working so I can make > releases. Oh, you can also try to not waste your hardware resources and confuse softwary by just installing 64 bits ;-) No, he can't, because it's my server, and I won't do any reinstall in the near future. Initially, I wasn't even aware that the server has a 64 bit CPU (and even if I were, back then I didn' t have enough trust in the 64bit OS releases), so it was set up with kubuntu 32bit. And even now I would set it up with 32bit again, since I don't want to build all my custom packages twice (I'm managing more computers than just that server). Also, given my experience with creepy bugs in Korganizer, caused by 64bit versions of libraries and other incompatibilities, I still don't trust 64bit OSes enough to install it on a production server. I think that's a pretty usual setup (most people I know have a 32bit version of Linux installed on their laptop even though their CPU is actually a 64bit). Note also, that running 32-bit on a 64-bit system can OFTEN be a performance WIN, so you DON'T want to upgrade "just because you can". The main reason for upgrading to 64-bit is to make efficient use of memory above 4Gb. If you can then run 32-bit apps over a 64-bit OS, that'll often be the best combination, as the binaries are smaller, are more likely to run from cache, etc etc. So, in short, if you have less than 4Gb ram, you should probably stay 32-bit. Even if you have more, is the gain worth the pain? Often it isn't. Cheers, Wol -- Anthony W. Youngman - anth...@thewolery.demon.co.uk ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: wikipedia...
2009/6/4 Jan Nieuwenhuizen : > Hi there, > > Triggered by recent wikipedia messages, I had a peek at our > > http://en.wikipedia.org/wiki/Lilypond ... > Possibly it's no wonder that wikipedia doesn't use lilypond, > considering that our article on wikipedia is so bad? First thing we can do, given that the talk section is intended to improve the article, is to write down these objections in it. -- Francisco Vila. Badajoz (Spain) www.paconet.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Fix crash when output-preview-framework is missing
On Thu, May 28, 2009 at 4:51 PM, Patrick McCarty wrote:
> On Thu, May 28, 2009 at 4:45 PM, Patrick McCarty wrote:
>> On Thu, May 28, 2009 at 10:46:11PM +0200, Reinhold Kainhofer wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> Am Donnerstag, 28. Mai 2009 22:18:23 schrieb Neil Puttock:
>>> > + warning (_f ("the `%s' backend does not support -dprint-pages",
>>> > + get_output_backend_name ()));
>>> >
>>> > + warning (_f ("the `%s' backend does not support -dpreview",
>>> > + get_output_backend_name ()));
>>> >
>>> > I'm not sure about these; personally I'd prefer having the important
>>> > information (the unsupported backend) at the end of the message:
>>> >
>>> > "unsupported backend for program option -dpreview: `%s'"
>>>
>>> This way, the explanation "unsupported backend" and the type of backend are
>>> very far apart and as such this message is much harder to understand. If you
>>> prefer the backend at the end, I would formulate it as:
>>>
>>> Program option -dpreview not supported by backend `%s'.
>>
>> I like Reinhold's suggestion a little more, so I think we should go
>> with it.
>>
>> A new patch with revised warning messages is attached.
>
> Sorry, something weird happened with the encoding of my last message.
> I'll send it through the web interface this time.
Any comments for this revised patch? The only things I changed were
the warning messages.
Thanks,
Patrick
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond 2.13.1 up
Han-Wen Nienhuys wrote: On Wed, Jun 3, 2009 at 3:04 PM, Patrick McCarty wrote: Yes, I was testing the GUB binary at lilypond.org. I have just confirmed the problem on 64-bit GNU/Linux too. The problem seems to be exactly what the error message reports: there is no file gs_init.ps located in the installation directory. I already know what is wrong. I'll try to push a new release tonight. (I found this bug on XP and fixed it there. I was assuming that the Gub3 checksumming would rebuild the installers automatically, but that was naive.) With 2.13.1 on Debian sid I get: Converting to `./asthedeertenor.pdf'... `gs -q -dSAFER -dDEVICEWIDTHPOINTS=612.00 -dDEVICEHEIGHTPOINTS=792.00 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite -sOutputFile="./asthedeertenor.pdf" -c .setpdfwrite -f "asthedeertenor.ps"' failed (256) Paul Scott ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: wikipedia...
Op donderdag 04-06-2009 om 11:08 uur [tijdzone +0200], schreef Francisco Vila: > First thing we can do, given that the talk section is intended to > improve the article, is to write down these objections in it. Well, that's what Han-Wen did in 2006. Nothing happened. I'd say: be bold and fix it first. Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR update policies, and WTM is input/new/revised/ ?
Graham Percival wrote: If you're involved with LSR, check out the LSR update docs in the CG on kainhofer in a day or so; please make corrections. Could somebody process the files in input/new/revised/ ? And why do we need this directory, anyway? Shouldn't those files just be dumped into input/new/ ? Cheers, - Graham I read the diff for CG when it came in this morning and the LSR stuff looks good to me. If you want, we could also include the script I wrote for checking all the snippets at once. Carl suggested that it go in the docs somewhere. I ran the files in input/new/revised/ and they all compiled. I don't understand what they're doing in there. I just checked and all of them are in the LSR and compile properly. Jon -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Website broken
Hi there, can someone fix this? This currently hangs the website update. mkdir -p out/locale/de/LC_MESSAGES/ msgfmt --output=out/locale/de/LC_MESSAGES/newweb.mo po/de.po po/de.po:166: end-of-line within string po/de.po:167: end-of-line within string -- 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: Website broken
On Thu, Jun 4, 2009 at 8:41 PM, Han-Wen Nienhuys wrote: > Hi there, > > can someone fix this? This currently hangs the website update. > > mkdir -p out/locale/de/LC_MESSAGES/ > msgfmt --output=out/locale/de/LC_MESSAGES/newweb.mo po/de.po > po/de.po:166: end-of-line within string > po/de.po:167: end-of-line within string Sure, here is a patch. -Patrick 0001-Fix-PO-file.patch Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
