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"
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: lilypond Scheme syntax in ly/music-fonctions-init.ly
Ludovic RESLINGER <[EMAIL PROTECTED]> writes: > Yes, I'm on the problem, to solve it, we need guile-1.8 serie.Hi, Heikki Junes' email suggests that using 1.8 creates a different problem; is this not your experience? What guile is being used by the upstream developers? The installation instructions say that only 1.6.7 is needed, IIRC. Thomas ___ 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: 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
confusion about version numbers
What does it mean that there are lilypond 2.8.5 binaries for some archs, but only source for 2.8.4? 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
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
Ludovic RESLINGER <[EMAIL PROTECTED]> writes: > I saw in archive some messages about a problem to build lilypond in > debian unstable. I think this is not a problem of python's version, because > I tested to build with python2.4 and python2.5, and the problem stay the > same: > > chmod 755 out/convert-ly > /usr/bin/perl /home/me/lilypond-2.8.4/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/me/lilypond-2.8.4/scripts' > make: *** [all] Error 2 I reported this bug on lilypond-devel back on April 27, in a message titled "building lilypond 2.8.1 on Debian unstable". 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. 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. 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
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
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
"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
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
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 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: 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: 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: help! eps no workie
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. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
help! eps no workie
So I can produce (blurry) png images, but eps output produces files that gs can't read and oowriter can't do anything with. gs simply displays empty pages, and oowriter includes just boxes of the proper size that say "Creator:LilyPond". No actual music. gv's display is different: for the -1.eps file, I get bad and missing fonts with partial data: an indication that the Emmenthaler fonts aren't being found. So I do the .eps file that has the fonts in it, and gv can display proper output. But still, oowriter can't read it. With the .eps file, oowriter puts a box that says: Title:CenturySchl.-Roma Creator:LilyPond CreationDate:Sun Mar 27 19:14:13 2005 but no actual music. Eek. What might be wrong? 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: > What tex intricacies did you use? Integration with [la]tex documents > is still supported, but using .eps snippets now. Not many. I've never been a power lilypond user, and my needs would be quite satisfied with .eps. I didn't much integrate it with tex, but just produced pages and then ran tex on them to get output. I'd be just as happy with .dvi output. > The tex backend is still present. If there are problems with it, > Han-Wen might be persuaded to support it as a sponsored feature? It's not a bad thing, but it should not be a priority on my account. 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
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 debian/; 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
another wishlist item
So the availability of mensural and "gregorian" square-note notation in lilypond is great. Will we ever see diastematic neumes?! :) (Just pushing the envelope...) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Debian lilypond
Erik Sandberg <[EMAIL PROTECTED]> writes: > If you print the document on a 1200 dpi printer, you must create > 1200 dpi PNGs to get full quality. I don't know what "full size" > means in terms of dpi, but if it means >=1200 dpi, then it should of > course be ok for most users (though the corresponding .eps might be > a smaller file). Oh, yeah, certainly. I'm not looking for space-cheap for this; I'm making documents for publication and it's just fine if the PDF I give the printer is stunningly huge. Though since EPS is nonlossy and openoffice.org supports that too, I suppose I should do that! Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Debian lilypond
Erik Sandberg <[EMAIL PROTECTED]> writes: > PNGs suffer from limited resolution. It's probably wiser to include .eps or > embedded .pdf files (perhaps pngs can be used as preview images, if that's > needed). Why? If I generate a png at full size, how do I lose? What am I missing? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Debian lilypond
OK, I'm building and uploading a new lilypond version for Debian with the new patches that Jan Nieuwenhuizen helpfully provided. In addition, dropping TeX from the build dependencies will make many people happy. It would be fun if (hint hint) there were a clever way to integrate lilypond and openoffice.org. I know it's probably a nightmarish proposal, so maybe not. I just generate png files myself and include them. Thanks for all the work you guys do on an excellent and well-loved piece of software. 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
lilypond packaging
The INSTALL.txt says suggests the "International fonts" for building the website, which of course we want in the Debian package. These fonts are only needed to build the website, right, because the fonts in question get embedded into the images? 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: > LilyPond no longer uses > > ec-fonts-mftraced Wait, you mean showed up and is now gone? What's it for anymore? Why did we ever have it? :) > I think the package > > musixtex-fonts > > does not exist and if it does, I cannot imagine any conflicts. The Debian package no longer includes this conflict. > Also, > as LilyPond does not use tex by default > > libkpathsea3 > tetex-bin > tetex-extra > > are not requirement anymore. They may be useful, and are required > when using the (unsupported) TeX backend. Ok; they were once used for processing the texinfo docs, right? You say that the TeX backend is no longer supported (!). Why is this? The manual still regards .tex output as the default output format and plenty of users regard it as the expected thing. >> Lilypond is such a great thing, I'm glad that finally Debian users >> will have an up-to-date package at least in Debian unstable. > > Thanks! Yes, that's great. And don't forget the Ubuntu users. Well, I can't support everyone. Ubuntu can copy Debian, but I can't simultaneously handle that. >> Oh, and a request: the debian/ directory in the tarballs that you all >> distribute isn't very helpful to me > > I always liked to distribute this for users to build their own deb > package [from CVS]. What do you think? 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. 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: > Thomas Bushnell writes: > >> But now there's a new, more subtle, one. > > Fixed in CVS, see patch below. > > Thanks for the report (and sorry that this kludge survived in the > first place). Ah, I like. Many thanks. My patch was worse (to have an environment variable that, if set, forces running-from-gui? to return #f). I like this one more. :) Anyway, with my patch (or equivalently with yours, I'm sure), lilypond 2.6.3 is now in Debian. (Whew!) It took overcoming an mftrace bug or two, getting Debian's fontforge up-to-date (which required overcoming some other bugs!), finding and fixing the running-from-gui? kludge, and a whole host of other stuff. And, during the whole process, 2.6.4 got released... :) I'm going to start going through the many Debian bug reports filed against the Debian lilypond package now, many of which are very old and were reported against version 2.2 or older. I expect they are nearly all no longer real bugs. Then I'll upgrade to 2.6.4 or whatever is the latest on the branch. Lilypond is such a great thing, I'm glad that finally Debian users will have an up-to-date package at least in Debian unstable. Oh, and a request: the debian/ directory in the tarballs that you all distribute isn't very helpful to me, because I have a separate way of keeping track of what goes in there. It would suit me fine if it simply went away entirely; I'm not using it in my packages, and it may easily be confusing to others. 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
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/python/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/ 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
lilypond puts a shared library in /usr/share
Lilypond installs a shared library in /usr/share, to wit: /usr/share/lilypond/2.6.3/python/midi.so (2.6.4 has the same problem.) This is very bad mojo and a violation of the GNU coding standards, which require that /usr/share is only for architecture independent files. Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a new lilypond build failure
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > At the very least, the code in lily.scm should be fixed to set the > running-from-gui? flag on a sensible basis. Failing that, the --safe > switch should be honored by lily-parser-scheme.cc. I misunderstood here the purpose of the --safe flag (thinking, incorrectly, that it was intended to make the program's execution safe from the bug I was seeing!). (It didn't help that "man lilypond" told me nothing of the meaning of the flag...) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a new lilypond build failure
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > But now there's a new, more subtle, one. Normal Debian automatic > build procedure is to build things with input redirected from > /dev/null. Ok, I have found out (thanks to strace) where the rest of the output is going; it lands in "generate-documentation.log". This is incomprehensible; nothing can justify this! It's perfectly sensible to redirect the output to a log when *stdout* is unreachable, but not when *stdin* is. This led me to the likely source of the problem: the grotesque running-from-gui? function in scm/lily.scm. This function makes the wildly crazy assumption that if stdin is not a terminal, we must be running under a GUI. The code at the end of lily.scm overrides this when the --safe-mode switch has been given, but that doesn't affect the use of that flag again in lily-parser-scheme.cc, does it?! The actual problem is the following chdir, another random dependency on such irrelevant details as whether there is a gui or whether stdin is the function ly_parse_file, found in lily/lily-parser-scheme.cc. This function also uses that nice running-from-gui? flag, but unlike the code at the end of scm/lily.scm, it does not test to see whether the "safe" flag has been given. The result is that lily proceeds to *CHDIR* (for God's sake, why?!) into the directory of the scheme input file specified on the command line. And, because it has misguidedly chosen to write a log file (in the old directory), without even mentioning on stderr that stderr is being redirected, unasked for, it's pretty easy for poor little me to miss. The desire to write the output file in the same directory as the input, when running under a GUI, makes a teeny bit of sense, but chdir is totally the wrong way to do that, since it affects everything else a program might want to do. There is way too much grot associated with this for little-ol-me to fix for Debian; can you please fix it for me? It's really atrocious. At the very least, the code in lily.scm should be fixed to set the running-from-gui? flag on a sensible basis. Failing that, the --safe switch should be honored by lily-parser-scheme.cc. Regardless, the strategy chosen here seems quite ill-founded. Output should be written to stdout. Chdir shouldn't be done by programs like lilypond, ever. Whether stdin is a terminal is entirely irrelevant to the entire operation of the program. Thomas ___ 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
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: 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: > 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. I'll try isolating it function by function 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: > 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: >> 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
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. 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: >> >>> 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, very interesting. When I compile it myself, I get no problems. When I build the Debian package myself, I get a problem. So presumably there is a packaging mistake. (Though it isn't in config.h, oddly.) 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: > 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. Thomas mftrace 1.1.16 Font `cmr10'... Using encoding file: `/usr/share/texmf/dvips/tetex/f7b6d320.enc' Running Metafont... Tracing bitmaps... Too many bits found when loading character 0warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 1warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 2warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 3warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 4warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 5warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 6warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 7warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 8warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 9warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 10warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 11warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 12warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 13warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 14warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 15warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 16warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 17warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 18warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 19warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 20warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 21warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 22warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 23warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 24warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 25warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 26warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 27warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 28warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 29warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 30warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 31warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 32warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 33warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 34warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 35warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 36warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 37warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 38warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 39warning: /usr/bin/gf2pbm: command exited with value 512 (ignored) Too many bits found when loading character 40warning: /usr/bin/gf2pbm
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: > Thomas Bushnell BSG wrote: >> 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. > > Upgrade mftrace to 1.1.16 Ok, mftrace 1.1.16 has now made it into Debian, and I still have the same problems compiling. I will verify all the details, but for now, the upgrade of mftrace has not solved the problem. 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: >> 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. > > Upgrade mftrace to 1.1.16 Thanks; I've requested such an upgrade from the Debian mftrace maintainer. Do you have sure knowledge that this is the problem, or are we just trying to narrow it down further? 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
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: > 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: > 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: > Thomas Bushnell BSG wrote: >> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: >> >>>can you do >>> >>> export LILYPONDPREFIX= >>> lily/out/lilypond input/example-1 >>> >>> this should give the same errors. >> Indeed it does (though without the infinite loop). >> >>>Can you post what >>> >>> lily/out/lilypond --verbose input/example-1 >>> >>>says? >> > > this is very strange, apparently, all the required fonts are found > > Grob count > 159[/home/src/lilypond-2.6.3//mf/out/emmentaler-11.otf][/home/src/lilypond-2.6.3//mf/out/emmentaler-13.otf][/home/src/lilypond-2.6.3//mf/out/emmentaler-14.otf][/home/src/lilypond-2.6.3//mf/out/emmentaler-16.otf][/home/src/lilypond-2.6.3//mf/out/emmentaler-18.otf][/home/src/lilypond-2.6.3//mf/out/emmentaler-23.otf] > > but then, > > 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? I'll see what I can do. I'm trying to compile the program to package it for Debian. The errors I get occur when I compile directly from the source using the normal instructions. Have you built and run it on a powerpc Linux system? Running what system, with what packages as dependencies? 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: > can you do > > export LILYPONDPREFIX= > lily/out/lilypond input/example-1 > > this should give the same errors. Indeed it does (though without the infinite loop). > Can you post what > > lily/out/lilypond --verbose input/example-1 > > says? errs 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
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: 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
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: > > We are a bit concerned with old LilyPond packages, and a potential > > new maintainer (Pedro Kroger) with his sponsor going mia. > > Who was going to sponsor him? I use lilypond all the time, so I'm happy to adopt it if necessary. I'm a bad mentor/sponsor however. Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
