Re: GPD: official shortest note in lilypond
On Thu, 2007-11-08 at 02:03 +0100, Werner LEMBERG wrote: As a composer by myself, it's a mystery to me why so many composers love to use 128th and 256th, most time for no good reason. Let's ask ourselves about that well-known piano hack, Ludwig van Beethoven. Later we'll turn to Mozart, who didn't confine himself to 128th notes, but used 256th notes too. I'm sure you'll start explaining why you're a better composer than Beethoven and Mozart, at least, you're not given to such notational distortions as those two well-known fools. For the rest of us, who think these guys *define* successful piano writing, we find that such monuments as the Pathetique Sonata, the Diabelli Variations, the Eroica Variations, and the Mozart C Minor Sonata, all require 128th notes. If you don't care about typesetting the highest glories of the repetoire, that's your business, but you can hardly say it's some sort of minor issue. CASE ONE: In the Sonata Opus 13, already mentioned, there are two runs notated with 128th notes. While some pianists ignore his careful notation, Beethoven is not just giving a piacere runs where you pace it more or less how you like and just play fast; no, he is expecting you to hold to the beat. If he doubled the note values, the piece would be notated in 4/2, which is (1) extremely uncommon, and (2), likely to confuse the tempo indication. The C time signature and the Grave tempo give exactly the right sense of the introduction, and any change would materially alter the interpretation. CASE TWO: For another example, the 24 Variations by Beethoven on Righini's Arietta Vieni amore use 128th notes in the 23rd variation. The first 22 variations and the theme are noted Allegretto in 2/4 time, except for the 19th which divides the two beats in thirds, for 6/8 time. The last variation is back to 2/4, a bit faster (Allegro), with some tempo games as Beethoven does some inconsequential little developments. So what about the 23rd variation? As is frequent, a slow variation comes next to last; this one is Adagio sostenuto. But it would be an abuse to change the timing of the measures radically. He does a delightful development by timing this adagio in threes, so we must have a 3/4 signature. A 3/2 signature would be, as I said, an abuse, and would indicate something very different from keeping the quarter-note timing, and marking it 3/4. Likewise, it would be insane to alter the whole piece to be mostly 2/2 instead of 2/4. That would make it an alla breve feel, instead of the light allegretto Beethoven is working with, and would radically change the interpretation. So, in the 23rd variation (I say all this because the Op. 13 is on everyone's shelf, and this is not, so it's harder for you to check), in the second time through the second part of the Arietta, the left hand accompaniment is sixteenth-note detache chords, and the melody consists of little fillips, four notes to each chord, thus requiring 64th notes. And--you know, it is Beethoven!--as the melody comes to a conclusion, the chords in the left hand stop, and the fillips become disconnected and have some dotted rhythms. And, bingo, that requires of course the pairing of a 128th note with a dotted 64th note. CASE THREE: Now we turn to the Eroica Variations, Opus 35. Again in the slow variation (number fifteen) we find the 128th notes twice. As with case two, the theme-and-variations format constrains one's ability to change timings in the slow variation because of the need to preserve consistency between variations. In this one, the 128th notes are found in two rapid runs (measures 8 and 31) where again they are part of timed rapid passages much like in the Opus 13. Also part of the fifteenth variation (though noted in the last measure of the fourteenth) is a rapid run in *grace notes* of 128th notes. CASE FOUR: The Six Variations, Opus 34, in the Molto Adagio section of the last variation, contain again some examples, again this time in rapid timed runs as we saw in the Opus 13. Counting the Molto Adagio marking as measure 1, the runs occur in measures 4, 7, 17. CASE FIVE: Perhaps these 128th notes were youthful indiscretions. Nope, for we find the same phenomenon in the Diabelli Variations, Opus 120. Again in the slow variation (Quel Suprise!), number 31, we find rapid timed runs in two measures which need 128th notes. CASE SIX: Oh, but now you're saying, one sonata and theme-and-variations? That doesn't count! Nobody respects theme-and-variations! Of course, the delightful Fantasia Opus 77 once again shows Beethoven's ineptness. He uses the forbidden note for a run in the next to last measure, where it is clearly necessary, and could only be avoided by setting the timing wrong on the whole rest of the piece. CASE SEVEN: We turn now to another fool (in your clear estimation) who didn't know how to write proper music, one Wolfgang Amadeus Mozart. Unlike Beethoven, Mozart *likes* a piacere fast runs, so we
Re: draft release announcement
On Wed, 2006-11-01 at 11:37 -0600, Trevor Bača wrote: The rule still taught in US classrooms for capitalizing titles is that the important words all get capitals (which comes down to something like prepositions and articles being lowercase, with everything else in uppercase). This is obvious nonsense. But it's still what's taught and still what's -- unfortunately -- expected (as Jan points out). How is it obvious nonsense? Many manuals of style have no trouble expressing this rule in clear forms. The important words method is hard to implement, but convenient for explaining to ten-year-olds. It so happens that the American book publishing industry is not bound by what is taught to fourth graders, and you cannot judge how book publishers work in terms of the simplified explanations given in elementary school. HOWEVER there are a couple of important exceptions. To start with, since this rule is no rule at all, the Library of Congress (no less) refuses to use it. Pick up any English-language book you happen to have sitting nearby, open to the first couple of pages, and look at the in-catalog number given there. The title is given in French (or international, or whatever you want to call it) title case: first word and proper nouns capitalized and nothing else. The reason is that the French / intl rule is an actual rule. And so the LOC uses it for every book published in the US, usually in direct contradiction to what the editor and publisher put on the cover and the spine. Actually, in German, as is well known, all nouns get capitalized. Every country has its own rules. There is nothing international about using sentence-case for titles; it's just the custom followed in some countries and not others. What you are running into here is that the rules for library catalogs in America are different from the rules for titles in running text or bibliographies. This is a consequence of the fact that American and British libraries agreed upon a common set of rules for cataloging, which rules happen to have the sentence case specification. So, my personal preference on this point is the same as Han-Wen's: the practice is old, out-dated and ridiculous in the US, even if still widely practiced, as Jan points out. For all the careful time and attention we spend making sure LilyPond output adheres as closely as possible to beautiful examples of notation from the past, I think we can afford ourselves the liberty to skip this one particular out-moded practice. Yes, because the best thing to do with standards is to declare that one is going to ignore them, in the name of inventing one's own standard. Wonderful. Thomas signature.asc Description: This is a digitally signed message part ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: polyphony voices sharing stems? (hymnody feature)
Ted Walther [EMAIL PROTECTED] writes: Most hymns are sung in four part harmony. Or three part. However, they are entered as piano music. because they are almost always accompanied by a piano because we moderns don't spend much time memorizing complex melodies. Actually, most hymns are entered as organ music written on two staves. The bass line is played on the pedals. Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond Scheme syntax in ly/music-fonctions-init.ly
Ludovic RESLINGER [EMAIL PROTECTED] writes: Actually I haven't tested, because I am on packaging of guile-1.8 in debian. I think this is independently useful work to do (and thanks for taking it on), and since upstream says they use 1.8 and everyone else says that 1.8 works, and that 1.6.8 has trouble, it is surely the best thing to simply proceed ahead with 1.8 and then depend on that for Debian lilypond. However, it would be a good idea if someone who knew more about lilypond's guile use than I do would report a bug against guile 1.6.8 for the guile developers' information. Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: confusion about version numbers
Han-Wen Nienhuys [EMAIL PROTECTED] writes: Thomas Bushnell BSG schreef: What does it mean that there are lilypond 2.8.5 binaries for some archs, but only source for 2.8.4? That I botched the source upload of 2.8.5 I do that all the time. :) Does that mean that 2.8.5 was really released, but the source just didn't make it into the archive? I didn't even see a release announcement for it. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond Scheme syntax in ly/music-functions-init.ly
In lilypond 2.8.4, ly/music-functions-init.ly, there occurs the following snippet (we're using Guile 1.6.8): %% FIXME: guile-1.7 required? %#(use-modules (scm display-lily))invalid module name for use-syntax ((srfi srfi-39)) I am in fact seeing this error. Are there people successfully building lilypond using Guile 1.6.8? Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: About lilypond's build problem with debian
Han-Wen Nienhuys [EMAIL PROTECTED] writes: Thomas Bushnell BSG schreef: I'm distressed that nobody has bothered to fix the bug since then. In the thread on the mailing list you can see that if LILYPONDPREFIX is set correctly, the bug goes away. This issue has been addressed in a more robust manner in the 2.9 series, and I would welcome a backport of the changes; we haven't found the time to do it. Good to hear. I think for Debian's purposes, setting LILYPONDPREFIX properly is probably the simplest solution. I look forward to 2.10 having a bettr fix in place. Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: About lilypond's build problem with debian
Han-Wen Nienhuys [EMAIL PROTECTED] writes: Thomas Bushnell BSG schreef: The problem is that lilypond's build system assumes that lilypond is already installed on the system. Han-Wen Nienhuys said no, it uses LILYPONDPREFIX, but as I point out in the thread, it is setting LILYPONDPREFIX *incorrectly*, and the reason the builds are working for Han-Wen is that he already has lilypond installed. this is false BTW, as I don't have lilypond installed at all. I always run from the development tree. On April 27 I submitted a bug report for 2.8.1, and explained the fix that solves the problem. I have no idea about 2.9 and what changes you say have been made there. Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
release announcements?
Why do I never see release announcements on lilypond-devel? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
what is 2.8.2?
how is it that there are binary packages for some systems for 2.8.2, but no source? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: building lilypond 2.8.1 on Debian unstable
Jan Nieuwenhuizen [EMAIL PROTECTED] writes: Thomas Bushnell writes: Mats Bengtsson [EMAIL PROTECTED] writes: See http://lists.gnu.org/archive/html/lilypond-devel/2006-03/msg00066.html Thanks. I think for Debian it will be ok to just require python2.4. Good catch, the configure scripts needs to be fixed. It seems to me there are two possible fixes: one is to require python 2.4, the other is to ship the relevant library as part of lilypond and use that when python 2.3 is being used. The latter seems to be too much work for too little benefit. So that still leaves as a bug the mismatch between how make/lilypond-vars.make sets LILYPONDPREFIX and how the scripts expect it to be set. Indeed. We kludge around here a bit, and it happens to work by accident, we'll fix this too. Great to hear. There is some Debian-delay getting all the dependencies for 2.8.1 going, so I'm happy to wait for the next release for it. Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: building lilypond 2.8.1 on Debian unstable
Heikki Johannes Junes [EMAIL PROTECTED] writes: A brute force solution was to make so many times, that you can finally see the missing buildscripts/out/ to appear, and the build to compile. That doesn't work; it simply capitalizes on the bug in the Makefile relying on the shell's redirection to create files. Specifically, the redirection is leaving around the manpage file (even though it hasn't really been created) and make isn't deleting it, so each time the make fails, it leaves a bogus manpage and the next time it runs, the bogus manpage is there and it can get one step further. This may satisfactorily create a lilypond binary, but it is not satisfactory for the Debian package, I'm afraid. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: building lilypond 2.8.1 on Debian unstable
Han-Wen Nienhuys [EMAIL PROTECTED] writes: 2006/4/28, Thomas Bushnell BSG [EMAIL PROTECTED]: File scripts/out/convert-ly, line 39, in ? import lilylib as ly ImportError: No module named lilylib Looking at the script, it is looking for the lilylib module in the installation directory, and doesn't contain any code or other help to locate it in the build directory. this is red herring; make/lilypond-vars.make sets LILYPONDPREFIX, which will cause the file to be found when doing the build. Still fails, even when I set it. [EMAIL PROTECTED]:/home/src/lilypond-2.8.1$ ls out/share/lilypond/current/ dvips elisp fonts lilypond-force ly mf ps python scm scripts tex [EMAIL PROTECTED]:/home/src/lilypond-2.8.1$ ls out/share/lilypond/current/python config.hh fontextract.py midi.dep musicexp.pyc rational.pyc convertrules.py fontextract.pyc midi.lo musicxml.py convertrules.pyc lilylib.py midi.so musicxml.pyc dummy.dep lilylib.pyc musicexp.py rational.py [EMAIL PROTECTED]:/home/src/lilypond-2.8.1$ LILYPONDPREFIX=out/share/lilypond/current scripts/out/convert-ly --help Traceback (most recent call last): File scripts/out/convert-ly, line 39, in ? import lilylib as ly ImportError: No module named lilylib Now curiously, if I set LILYPONDPREFIX to out, then it gets further. But make/lilypond-vars.make does not set it to that, it sets it to $(build_lilypond_datadir)/current, which is out/share/lilypond/current. Doing this (setting LILYPONDPREFIX to out) produces: [EMAIL PROTECTED]:/home/src/lilypond-2.8.1$ LILYPONDPREFIX=out scripts/out/convert-ly --help Traceback (most recent call last): File scripts/out/convert-ly, line 39, in ? import lilylib as ly File out/share/lilypond/current/python/lilylib.py, line 17, in ? import subprocess ImportError: No module named subprocess [EMAIL PROTECTED]:/home/src/lilypond-2.8.1$ ls /usr/lib/python2.4/subprocess* /usr/lib/python2.4/subprocess.py /usr/lib/python2.4/subprocess.pyo /usr/lib/python2.4/subprocess.pyc It works over here. Of course if you run this from the command line it fails. Of course, because you already have the files installed. De install all of lilypond from the system, and then try and compile it... that's a fair test! Your build works Just Fine because you already have the libraries installed. Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: building lilypond 2.8.1 on Debian unstable
Thomas Bushnell BSG [EMAIL PROTECTED] writes: [EMAIL PROTECTED]:/home/src/lilypond-2.8.1$ ls /usr/lib/python2.4/subprocess* /usr/lib/python2.4/subprocess.py /usr/lib/python2.4/subprocess.pyo /usr/lib/python2.4/subprocess.pyc Sorry, what I meant to do here was: $ ls /usr/lib/python2.3/subprocess* since it's Python 2.3 that I'm actually using. There isn't any subprocess library in Python 2.3 (that I'm aware of). Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: building lilypond 2.8.1 on Debian unstable
Mats Bengtsson [EMAIL PROTECTED] writes: See http://lists.gnu.org/archive/html/lilypond-devel/2006-03/msg00066.html Thanks. I think for Debian it will be ok to just require python2.4. So that still leaves as a bug the mismatch between how make/lilypond-vars.make sets LILYPONDPREFIX and how the scripts expect it to be set. Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
building lilypond 2.8.1 on Debian unstable
I'm trying to build lilypond 2.8.1 on debian unstable. Doing ./configure and make, it configures sensibly AFAICT, and starts building, and then dies with the following: /usr/bin/perl /home/src/lilypond-2.8.1/buildscripts/out/help2man out/convert-ly out/convert-ly.1 help2man: can't get `--help' info from out/convert-ly make[1]: *** [out/convert-ly.1] Error 1 make[1]: Leaving directory `/home/src/lilypond-2.8.1/scripts' make: *** [all] Error 2 So I do: scripts/out/convert-ly --help, to see what's happening, and it says: Traceback (most recent call last): File scripts/out/convert-ly, line 39, in ? import lilylib as ly ImportError: No module named lilylib Looking at the script, it is looking for the lilylib module in the installation directory, and doesn't contain any code or other help to locate it in the build directory. Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Email addresses in Ubuntu package
Erik Sandberg [EMAIL PROTECTED] writes: In the Ubuntu package, an incorrect address to Han-Wen is given. The domain name is now xs4all.nl, not cs.uu.nl. (this was updated today in all source files). Where in the package? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Email addresses in Ubuntu package
Erik Sandberg [EMAIL PROTECTED] writes: In debian/control (the Description field, the last two lines). Oops, that's a bug! Debian packages normally don't put that in the Description at all. ;) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: help! eps no workie
Tyler Eaves [EMAIL PROTECTED] writes: On Tue, 25 Oct 2005 15:07:17 -0400, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Han-Wen Nienhuys [EMAIL PROTECTED] writes: You can use --preview to get an EPS file. Title:CenturySchl.-Roma Creator:LilyPond CreationDate:Sun Mar 27 19:14:13 2005 but no actual music. Eek. What might be wrong? this is normal. OO will only print the image. Yeah, it turns out this is an openoffice.org disaster. For my current publishing project I'm using pngs because I don't have time for anything else, and it will look ok. Be aware that something that looks fine on screen often looks HORRIBLE printed. Yep. I check for print quality by examining the resulting pdf at very high magnification. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a new lilypond build failure
Jan Nieuwenhuizen [EMAIL PROTECTED] writes: Well, it's a dangerous thing. Among other things, their version numbers might collide badly with the official Debian ones. Best it should have different package names to prevent this sort of thing from happening. Whe have this on our website, I think that Anthoy Fok provided this recipe The build scripts are in the subdirectory codedebian//code; you can make the .deb by doing tar xzf lilypond-x.y.z.tar.gz cd lilypond-x.y.z dpkg-checkbuilddeps # print missing build dependencies # apt-get install ... # install any missing packages dch -p -v x.y.z.local.1 Local build. debuild We could also just copy your ./debian stuff and change the name to lilypond-snapshot and lilypond-2.6-snapshot or something? Yes, that is a safer recipe. If you copy my ./debian code, that's ok, but still, I'd rather it didn't land inside the standard tarball but lived separately. Also, there will be necessary version skew: I make my change only after you release the tarball. Since the virtue of this is for users who are using the CVS archive (and I do see the point of that) how about leaving it in the CVS, but not packaging it into the tarball? That seems like the best of both worlds. Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a new lilypond build failure
Jan Nieuwenhuizen [EMAIL PROTECTED] writes: Ok; they were once used for processing the texinfo docs, right? They are still used for producing the PDF documentatation, so there is still a build dependency on tetex. Also, tetex is great for making documents with lilypond snippets, but this does not make tetex a dependency (now that we dropped it). Ah, yes, we get that from mftrace anyway, since mftrace depends on tetex-bin in Debian. :) You say that the TeX backend is no longer supported (!). Why is this? TeX used to be our easy way out to produce output. In the 2.5 series, we managed to use pango to make the half-baken PS backend fully operational. Supporting tex output is a lot of work, and it probably has just one user. I used to use it a lot. Ah well. :) Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a new lilypond build failure
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
Thomas Bushnell BSG wrote:
ec-fonts-mftraced
Wait, you mean showed up and is now gone? What's it for anymore?
Why
did we ever have it? :)
It was for Lily 2.4, which supported Latin1 encoding and fonts, but not
unicode.
I see, so now that Unicode is supported, it's not relevant.
Does that mean that nobody will ever want ec-fonts-mftraced anymore?
(If so, I can drop the Debian package itself too.)
No, Lily used to be linked against libkpathsea to locate TeX fonts, so
it could determine dimensions of texts. This is no longer necessary with
Pango. LilyPond now outputs PS directly, which you can include into TeX
with \includegraphics{}. Supporting TeX (with all of its crappy support
tools) was one of the major headaches of deploying LilyPond, and I'm
very glad it's gone.
If the manual suggests .tex is the default, then that would be a bug in
the manual then; can you pinpoint it more exactly?
Let me check to make sure I have the right version of the manual. :)
I'll get back to you on that.
Thomas
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond puts a shared library in /usr/share
[EMAIL PROTECTED] (Pedro Kröger) writes: This is very bad mojo and a violation of the GNU coding standards, which require that /usr/share is only for architecture independent files. really? I thought that /usr/local/share was for architecture independent files: The root of the directory tree for read-only architecture-independent data files. This should normally be /usr/local/share [1] Isn't that what I just said? A shared library is not an architecture independent file: /usr/share/lilypond/2.6.3/python/midi.so: ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), not stripped But I suppose that in this case /usr/lib/pythonversion/site-packages/ should be the right choice? I'm not a python expert. I think this would be the wrong place; I think it should go in /usr/lib/lilypond/version and the search paths for lilypond's python support should have that added. Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond puts a shared library in /usr/share
Thomas Bushnell BSG [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Pedro Kröger) writes: This is very bad mojo and a violation of the GNU coding standards, which require that /usr/share is only for architecture independent files. really? I thought that /usr/local/share was for architecture independent files: The root of the directory tree for read-only architecture-independent data files. This should normally be /usr/local/share [1] Isn't that what I just said? I see the distinction you were making. No, /usr/share and /usr/local/share have the same semantics. Of course, lilypond installs by default into /usr/local/share; I said /usr/share only because I configure with --prefix=/usr and forgot that this isn't standard. The bug is there regardless of the value of --prefix; $(datadir) is only for architecture independent files. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
a new lilypond build failure
So delightfully, mftrace version 1.1.17 does indeed fix the previous build problems. But now there's a new, more subtle, one. Normal Debian automatic build procedure is to build things with input redirected from /dev/null. This causes a failure in running lilypond for documentation generation. The command invoked is from lilypond-2.6.3/Documentation/user, and is /home/debian/lilypond-2.6.3/lily/out/lilypond --verbose /home/debian/lilypond-2.6.3/ly/generate-documentation If the input is a terminal, this works fine, and prints the following output: GNU LilyPond 2.6.3 LILYPOND_DATADIR=/usr/share/lilypond/2.6.3 LOCALEDIR=/usr/share/locale Effective prefix: /usr/share/lilypond/2.6.3 Initializing FontConfig... adding font directory: /usr/share/lilypond/2.6.3/fonts/otf/ adding font directory: /usr/share/lilypond/2.6.3/fonts/type1/ adding font directory: /usr/share/lilypond/2.6.3/fonts/svg/ Processing `/home/debian/lilypond-2.6.3/ly/generate-documentation.ly' Parsing...[/usr/share/lilypond/2.6.3/ly/init.ly[/usr/share/lilypond/2.6.3/ly/declarations-init.ly[/usr/share/lilypond/2.6.3/ly/music-functions-init.ly][/usr/share/lilypond/2.6.3/ly/nederlands.ly][/usr/share/lilypond/2.6.3/ly/drumpitch-init.ly][/usr/share/lilypond/2.6.3/ly/chord-modifiers-init.ly][/usr/share/lilypond/2.6.3/ly/script-init.ly][/usr/share/lilypond/2.6.3/ly/scale-definitions-init.ly][/usr/share/lilypond/2.6.3/ly/grace-init.ly][/usr/share/lilypond/2.6.3/ly/midi-init.ly[/usr/share/lilypond/2.6.3/ly/performer-init.ly]][/usr/share/lilypond/2.6.3/ly/paper-defaults.ly[/usr/share/lilypond/2.6.3/ly/titling-init.ly]][/usr/share/lilypond/2.6.3/ly/engraver-init.ly][/usr/share/lilypond/2.6.3/ly/dynamic-scripts-init.ly][/usr/share/lilypond/2.6.3/ly/spanners-init.ly][/usr/share/lilypond/2.6.3/ly/property-init.ly]][/home/debian/lilypond-2.6.3/ly/generate-documentation.ly[/usr/share/lilypond/2.6.3/scm/documentation-lib.scm][/usr/share/lilypond/2.6.3/scm/document-functions.scm][/usr/share/lilypond/2.6.3/scm/document-translation.scm][/usr/share/lilypond/2.6.3/scm/document-music.scm][/usr/share/lilypond/2.6.3/scm/document-backend.scm][/usr/share/lilypond/2.6.3/scm/document-markup.scm] Writing lilypond-internals.texi... ]] But if the input is redirected from /dev/null, it exits after printing: LILYPOND_DATADIR=/usr/share/lilypond/2.6.3 LOCALEDIR=/usr/share/locale Effective prefix: /usr/share/lilypond/2.6.3 Initializing FontConfig... adding font directory: /usr/share/lilypond/2.6.3/fonts/otf/ adding font directory: /usr/share/lilypond/2.6.3/fonts/type1/ adding font directory: /usr/share/lilypond/2.6.3/fonts/svg/ And it does not generate any of the proper output files that should be generated. Moreover, the trailing newline after /svg/ is not printed. This premature exit reports exit status zero (which also caused considerable pain in locating this as the source of the problems I'm having!). This happens with a lilypond that otherwise seems to work fine. Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cannot build lilypond 2.6.3 on powerpc
Han-Wen Nienhuys [EMAIL PROTECTED] writes: Thomas Bushnell BSG wrote: Han-Wen Nienhuys [EMAIL PROTECTED] writes: Hrmmph. Is this still an mftrace problem (does mftrace cmr10 produce a .pfa which looks good in fontforge?) Alas, no. I get no glyphs, and the output of mftrace is as follows. BTW, there is presumably a missing \n on one of these printfs. The problem is the gf2pbm program included in mftrace. Can you compile gf2pbm.c from mftrace for yourself (using WORDS_BIGENDIAN in config.h for ppc), and check whether that works. Usage: mf-nowin cmr10 gf2pbm -n 65 cmr10.2602gf produces 65.pbm containing the glyph A. Ah, I have found the problem. The Debian package builds gf2pbm with optimization on (-O2). gf2pbm misbehaves when compiled with optimization, and works fine when compiled without. This is almost certainly not a compiler bug, of course, it's much more likely a problem inside gf2pbm. Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cannot build lilypond 2.6.3 on powerpc
Han-Wen Nienhuys [EMAIL PROTECTED] writes: Thomas Bushnell BSG wrote: Han-Wen Nienhuys [EMAIL PROTECTED] writes: Thomas Bushnell BSG wrote: This is almost certainly not a compiler bug, of course, it's much more likely a problem inside gf2pbm. Aha, GCC spews some warnings about dubitable pointer manipulations. Which GCC version is this? 4.0.2. I have gcc 4, but only on an x86 box. I can have a look into cleaning the dubious code, but I can't test the result on PPC. Is that OK with you? Of course that never hurts! I'm trying to debug it myself too. Oddly, -O2 fails, -O1 does not, and turning the -O2 optimizations one one-at-time doesn't cause a failure. So it must be triggered by a combination of the two. Do you see any problems with -O2 on x86? Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cannot build lilypond 2.6.3 on powerpc
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Han-Wen Nienhuys [EMAIL PROTECTED] writes: Thomas Bushnell BSG wrote: Han-Wen Nienhuys [EMAIL PROTECTED] writes: Thomas Bushnell BSG wrote: This is almost certainly not a compiler bug, of course, it's much more likely a problem inside gf2pbm. Aha, GCC spews some warnings about dubitable pointer manipulations. Which GCC version is this? 4.0.2. I have gcc 4, but only on an x86 box. I can have a look into cleaning the dubious code, but I can't test the result on PPC. Is that OK with you? Of course that never hurts! I'm trying to debug it myself too. Oddly, -O2 fails, -O1 does not, and turning the -O2 optimizations one one-at-time doesn't cause a failure. So it must be triggered by a combination of the two. Do you see any problems with -O2 on x86? I can answer this myself: no problems on x86. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cannot build lilypond 2.6.3 on powerpc
Han-Wen Nienhuys [EMAIL PROTECTED] writes: Thomas Bushnell BSG wrote: Thomas Bushnell BSG [EMAIL PROTECTED] writes: Ah, I have found the problem. The Debian package builds gf2pbm with optimization on (-O2). gf2pbm misbehaves when compiled with optimization, and works fine when compiled without. More specifically, failure happens with: -fschedule-insns -fstrict-aliasing -O But not with: -O or either of those -f optimizations alone. there are some dodgy pointer casts in gf2pbm, specifically, gf2pbm.c: In functie $-1òøread_GF_charòù: gf2pbm.c:305: let op: initialization from incompatible pointer type BMUNIT *cp, *basep, *maxp; char**basep_cpp = basep; GCC4 has become much more agressive with considering cast pointers as unaliased by definition, so I would suspect this one. Yep, I've narrowed it down to that one too (I didn't think the warning at first should matter)! If I change the declaration to BMUNIT **basep_cpp, that of course shuts up the warning. And--it causes the failure to happen whether optimization is on or not! The problem is almost certainly the type punning of the basep_cpp variable and the creepy pointer arithmetic being done with what it points to. When the declaration is fixed to shup up the warning, the result is that the same thing happens as when the compiler assumed there was no aliasing, and that's that the pointer arithmetic is multiplied by the wrong things. It would of course help if there were comments! :) :) I'm attempting a fix now. Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cannot build lilypond 2.6.3 on powerpc
Thomas Bushnell BSG [EMAIL PROTECTED] writes:
I'm attempting a fix now.
Done; here is the patch:
--- /home/debian/mftrace-1.1.16/gf2pbm.c 2005-10-15 13:57:58.0 -0700
+++ /home/src/mftrace-1.1.16/gf2pbm.c 2005-10-15 14:23:49.0 -0700
@@ -302,7 +302,7 @@
ubyte cmnd;
int min_m, max_m, min_n, max_n;
BMUNIT *cp, *basep, *maxp;
- char **basep_cpp = basep;
+ BMUNIT **basep_cpp = basep;
int bytes_wide;
bool paint_switch;
#define White false
@@ -391,7 +391,7 @@
case SKIP2:
case SKIP3:
*(basep_cpp) +=
- num(GF_file, WIDENINT cmnd - SKIP0) * bytes_wide;
+ num(GF_file, WIDENINT cmnd - SKIP0) * bytes_wide / sizeof (BMUNIT);
case SKIP0:
new_row = true;
paint_switch = White;
@@ -414,7 +414,7 @@
if (new_row) {
*(basep_cpp) +=
- bytes_wide;
+ bytes_wide / sizeof (BMUNIT);
if (basep = maxp || cp = basep) too_many_bits(ch);
cp = basep;
word_weight = BMBITS;
I've verified that this works completely, producing a nice happy
looking pbm output file.
Thomas
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Illegal C++
Wiz Aus [EMAIL PROTECTED] writes: miss the many admittedly powerful tools that are available under linux. But never yet have I felt the slightly bit compelled to choose to develop under that platform. I'm sorry, but I like my GUI's, and my single keystroke compile and debug cycles, and not to having to worry about which version of which package is compatible with another and why this scripting command works here and not there. And I'm quite obviously not the only one. I'm more than willing to contribue towards lilypond development, but I doubt I would bother if I had to do it in a linux environment. Hrm, I run Debian and have all that wondrous stuff. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cannot build lilypond 2.6.3 on powerpc
Han-Wen Nienhuys [EMAIL PROTECTED] writes: If you want to analyze the problem, you could trace into fm-find_by_name(idx) a few lines before using gdb. It might be a compatibility problem with freetype. Do the emmentaler glyphs show up in gnome-character-map if you install the .otf in ~/.fonts? I don't know C++. I'm an old C programmer. So that means I'm not even sure what exactly to do to set breakpoints in freaky inherited functions and whatnot. Can you give me instructions? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cannot build lilypond 2.6.3 on powerpc
Han-Wen Nienhuys [EMAIL PROTECTED] writes: input/example-1.ly:4:16: warning: note head `noteheads.s2' not found (combing from note-head.cc line 65), it doesn't contain the correct glyph. If you want to analyze the problem, you could trace into fm-find_by_name(idx) a few lines before using gdb. It might be a compatibility problem with freetype. Do the emmentaler glyphs show up in gnome-character-map if you install the .otf in ~/.fonts? Looking for the glyphs is a good idea, but which file should I install in .fonts to check? What are the emmentaler glyphs? I know music, but I don't know how to recognize what I should see. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cannot build lilypond 2.6.3 on powerpc
Han-Wen Nienhuys [EMAIL PROTECTED] writes: What are the emmentaler glyphs? I know music, but I don't know how to recognize what I should see. gnome-character-map view unicode block font : emmentaler block: private unicode area from codepoint E100 onward, you should see isolated rests, accidentals and noteheads in the glyph table. Nope, I see nothing of the sort; all I see are the number-in-block Unicode glyphs for the absent code points. For the record, the fontforge in use is Debian fontforge 0.0.20050911-1 which reports: Copyright (c) 2000-2005 by George Williams. Executable based on sources from 17:48 11-Sep-2005. fontforge 20050911 Near as I can tell from using fontforge, the emmentaler-20.otf file does not have any glyphs in it at all (including certainly at the private use area where you mention). It is 62836 bytes long, so *something* is going on. I'll do a make from a fresh directory and report back what the output is relevant to the generation of this file...maybe something will be obvious from that. Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cannot build lilypond 2.6.3 on powerpc
Han-Wen Nienhuys [EMAIL PROTECTED] writes: from codepoint E100 onward, you should see isolated rests, accidentals and noteheads in the glyph table. Well, it's no surprise that I didn't see anything! Making progress here; clearly something is busted in font generation. The fontforge call to generate the emmentaler-20.otf file shows: (cd ./out /usr/bin/fontforge -script emmentaler-20.pe) Copyright (c) 2000-2005 by George Williams. Executable based on sources from 17:48 11-Sep-2005. Warning: Font contained no glyphs /usr/bin/python ../buildscripts/substitute-encoding.py --outdir=./out out/PFAemmentaler-20.pfa rm ./out/*.scale.pfa rm: cannot remove `./out/*.scale.pfa': No such file or directory make[1]: [out/PFAemmentaler-20.pfa] Error 1 (ignored) The emmentaler-20.pe file looks sensible: emmentaler-20.pe Description: Binary data The generation of feta20.pfa, however, does not look sane: excerpt Description: Binary data I'm using mftrace version 1.1.12, and potrace version 1.7. Autotrace version 0.31.1 is also installed, but mftrace says it uses potrace if both are there. mftrace also uses t1asm, which is version 1.32. I don't know much of anything about mftrace, so I'm not sure what the place to look is before this. Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
cannot build lilypond 2.6.3 on powerpc
Lilypond 2.6.3 does not build on powerpc. make all works fine, but make web fails. The specific error happens while building the documentation thus: one Description: Binary data (These last two lines then get printed forever in an apparent infinite loop.) The contents of the lily-1770879717.ly file referenced are: lily-1770879717.ly Description: Binary data Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cannot build lilypond 2.6.3 on powerpc
Han-Wen Nienhuys [EMAIL PROTECTED] writes: Thomas Bushnell BSG wrote: Lilypond 2.6.3 does not build on powerpc. make all works fine, but make web fails. The specific error happens while building the documentation thus: looks like something went wrong building the fonts. You do have mf/out/emmentaler*otf ? Yes. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Is Anthony Fok [EMAIL PROTECTED] MIA?
Jan Nieuwenhuizen [EMAIL PROTECTED] writes: Thanks for the offer! I'm not sure however how adopting a package works, I guess you'll have to sort with Anthony and Pedro. I know how to take care of the package. But Anthony Fok is currently the maintainer, so he needs to either orphan it or offer it for adoption. I can't speak about the question of making that happen; I'm just saying that if it should be in that state, and then someone says will you please take this over, I will probably say yes. We aren't at that point yet, however. Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Is Anthony Fok [EMAIL PROTECTED] MIA?
Martin Michlmayr [EMAIL PROTECTED] writes: * Thomas Bushnell BSG [EMAIL PROTECTED] [2005-03-14 02:14]: I know how to take care of the package. But Anthony Fok is currently the maintainer, so he needs to either orphan it or offer it for adoption. I can't speak about the question of making that happen; I'm just saying that if it should be in that state, and then someone says will you please take this over, I will probably say yes. We aren't at that point yet, however. Anthony told me over dinner that people interested in adopting his packages can go ahead. So please consider this an invitation to adopt lilypond if you're serious about maintaining it. Ok, adoption in progress. Would the lilypond people please point me to the official web pages and subscription information for the relevant mailing lists I should be on? Thanks. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
