Re: Font handling error on Mac OS/X
> (font-file-as-ps-string name full-name): > /Users/Carl/lilypond-working/out/share/lilypond/current/scm/framework-ps.scm > :293:28: Wrong number of arguments to # (name file-name font-index)> > > It appears to me that the call to font-file-as-ps-string is missing > a font-index argument. > > Any suggestions? Fixed in git. Note that this is probably a temporary fix only since I don't know whether TTCs are used on macs. A few days ago I've already asked the author of fondu regarding this issue, but apparently he is on vacation. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
incorrect bbox values for EPS images
It seems that lilypond computes incorrect bbox values for EPS images. While the top, left, and right side is OK, the bottom is always too far away by a certain (fixed?) amount. Looks like a bug... Werner <>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
copyright year update script issue
Jan, can you add a list of exceptions to your copyright year update script? Some files like the mf2pt1 stuff are contributed and should stay as-is. I've fixed that manually in the git, but an automatic process would be better. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: copyright year update script issue
> > can you add a list of exceptions to your copyright year update > > script? Some files like the mf2pt1 stuff are contributed and > > should stay as-is. > > Why is this necessary? Well, I think it is a kind of courteousy to leave `external' files unchanged. Additionally, it simplifies updating. Other files like texinfo.tex should also stay as-is, without updating the copyright year (which your script hasn't done BTW). Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: copyright year update script issue
> Do you have a list of files to exclude? These files come to my mind: COPYING tex/texinfo.tex tex/txi-de.tex tex/txi-en.tex tex/txi-es.tex tex/txi-fr.tex scripts/build/mf2pt1.pl mf/mf2pt1.mp scripts/build/help2man.pl Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
better output of -dhelp
The output of -dhelp should be more readable now; I've updated also almost all help doc strings. Please check. Additionally, following GNU standards, its output is now sent to stdout. BTW, is it possible to internationalize these help strings? This is rather important IMHO. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Distribution updates and documentation woes
> And last but not least: what about our own documentation builds? > Info docs are missing here altogether! Should we include info docs > and re-root the documentation ball to look like > >share/doc/lilypond/Documentation/* >share/info/dir >share/info/* I'm all for it. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ideas for Google Summer of Code
> I'd especially like someone to look at some of the problems with > lilypond-book. Particularly the margin settings. What exactly do you mean? > I would think the reason those problems haven't been fixed is that > it's more than a few hours to do it, but I would really be surprised > if it were more than two months. If I have some time I'll work on the LaTeX output of lilypond-book. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Documentation improvements patch
> In several places, but not all, you replaced the text
>
> Default 1.0.
>
> with the text
>
> defa...@tie{}1.0.
>
> I understand that the @tie{} is there to prevent the 1.0 from being wrapped
> onto a line by itself.
>
> Is there a reason that you didn't do it on all of them, or was it just an
> oversight?
In case I've missed `1.0' or any other string with a length <=3 (not
counting the final period) which belongs to the word before, it's an
oversight. It's just my feeling that too short items shouldn't start
a line. The value 3 is debatable, of course.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch to fix `make web'
> > This patch fixes `make web'. Can someone apply it? > > ...but it didn't fix `make all'. Sorry about the early post. > > This revised patch should fix the issue. Applied, thanks. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond-book: \lilypond vs. lilypond environment
Folks, a long time ago, if I remember correctly, there was a difference between lilypond-book's handling of \lilypond and a `lilypond' environment: The former was (mainly) for inline use, the latter (mainly) for use in a paragraph of its own. I would like to restore this behaviour. While it is already possible to use \lilypond within a paragraph (and the `lilypond' environment also), the image is not aligned well: The `eps-box-padding' value (as specified with the command line option `--left-padding') is applied, and the image isn't centered vertically. [See my other mail w.r.t. the usefulness of `--left-padding'.] Since `--left-padding' is a global lilypond-book option, we would need a local option `left-padding' for both \lilypond and the `lilypond' environment; the default value would be zero for \lilypond and the `--left-padding' value for the `lilypond' environment. Similarly, I would add a new local option `vcenter' (possibly combined with two other yet-to-be-implemented local options `hoffset' and `voffset') to center lilypond images vertically. Only \lilypond would have this option set by default. To avoid compatibility issues I suggest to introduce a (no-op) \lilypondbookversion macro which is scanned by lilypond-book to activate the new behaviour. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
buggy lilypond-book behaviour
The main argument for having `eps-box-padding' was vertical alignment in LaTeX and texinfo documents due to bar numbers sticking out to the left. However, the output is already aligned properly with lilypond 1.12.1 even without this option. Since a global value for `eps-box-padding' is questionable anyway I suggest to mark `--left-padding' as obsolete and change it to be a no-op. Another bug in lilypond-book is its attempt to set the staff length equal to the LaTeX line length. This no longer works correctly as soon as bar numbers are displayed or instruments are specified, as Laure describes in another email. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ideas for Google Summer of Code
> The other one is the attached lilypond file, which looks good if you > just run lilypond on it, but if you run lilypond-book on the > attached .lytex file, you don't really get a usable piece. I > reported this issue a few months ago, and someone did do some work, > so that the music no longer runs off the page, but I think you'll > agree that the lilypond output is much more what the user would want > than the lilypond-book output. Yep. A few days ago I've prepared two emails which I've just sent to the list (with slight updates). Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please fix: japanese doc compilation
> someone added a japanese translation of the docs, but after enabling > it (so it is distributed), I get error (see below). Can someone fix > this, or disable the translation? This is a blocking issue for > releasing 2.12.2. The Japanese translation is for texi2html only, I believe. I can't see an easy way to make it work with texinfo.tex, given that there is no equivalence to LaTeX's NFSS interface to select fonts. We would need a texi2latex translation so that we could use my CJK package (to be more precise, my CJKutf8.sty file). Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please fix: japanese doc compilation
> We would need a texi2latex translation so that we could use my CJK > package (to be more precise, my CJKutf8.sty file). Alternatively, texinfo.tex needs to be hacked for (hard-coded) Japanese support. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
automatic setting of `currentBarNumber'
Writing to lilypond-user, I got no reply, thus I'm sending it again to
lilypond-devel.
Werner
==
The following problem:
\score {
\relative {
c1 | c1 | c1 | c1 |% Bars 1-4
}
\score {
\relative {
c1 | c1 | c1 | c1 |% Bars 5-8
}
I know how to manually set `currentBarNumber' in the second \score
block:
\set Score.currentBarNumber = #5
However, I want to have this set automatically; for example, if I
later decide to insert two bars into the first \score block, the
starting bar number for the second \score block should be updated
accordingly.
It's rather straightforward to store the value of `currentBarNumber'
in a Scheme variable (the number `10' is just a dummy value):
#(define lastBarNumber 10)
\score {
\relative {
c1 | d1 | e1 | f1 |
\applyContext
#(lambda (x)
(set! lastBarNumber (ly:context-property x 'currentBarNumber)))
}
However, I wasn't able to make lilypond use the computed value. I
tried both `\set' and `\applyContext' (using
`ly:context-set-property!') without success.
Please advise.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automatic setting of `currentBarNumber'
> currentBarNumber must be an integer, so the value is computed at > parsing time. If it could be a procedure, which evaluation would be > delayed at music interpretation time, then it would be possible. > That requires modifying LilyPond code (unless I'm missing > something). > > For a possible solution, see the attached patch. Thanks! However, I believe that this ad-hoc solution is too specific; I can imagine that there are other useful applications which need evaluation at music interpretation time. Any suggestion how to make this more generic? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please fix: japanese doc compilation
> There are many LilyPond users in Japan and they need information > about LilyPond in Japanese. I want them to join to LilyPond > community without hesitating. They are solving their problems > individually. Since there is such a great number of Japanese LilyPond users not fluent of English, it would be most important to create a `central' Japanese lilypond user forum, with one or more guys who forward more difficult questions to the English mailing lists (as it is already done for the German and French user forums) and translate the answers back into Japanese -- people like you, for example. In case people hesitate to write bad English: We don't care! lilypond code is universal :-) Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCHES] Re: move .ly code out of .py
> Patch to add the glyph to the feta font and define a corresponding > \snappizzicato articulation: http://codereview.appspot.com/12862 > > Werner, can you please take a look at the metafont code and check if > I did it the right way? Everything looks fine. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond & wikipedia
There's an interesting discussion (since five years!) why lilypond can't be integrated into wikipedia yet: https://bugzilla.wikimedia.org/show_bug.cgi?id=189 A resumé of the discussion is this last comment (from about a week ago): We want LilyPond to be as safe to call as, say, ImageMagick (or ABC!). If it's configured correctly, we should be guaranteed that it will terminate in a reasonably short amount of time while using a reasonably small amount of memory/disk/network/etc. I think this is a clear enough requirement to relay. Alternatively, if LilyPond devs won't do this, someone could write a preprocessing sanitizer of some kind like we have for LaTeX, as long as it achieves the same effect. Tim Starling, one of the main wikipeda software developers, says: My understanding is that a) safe mode is not secure, being trivially DoS-able by short infinite loop scripts b) safe mode will not work for many of the free scores available on the web The problems with LilyPond are sufficiently severe that I have, from time to time, researched alternative music renderers such as Philip's Music Writer that don't have an embedded scripting language. Anyone who can shed more light on the raised issues? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Japanese translations
> The reason to put @c at the end of each line is because a line break > in a TexInfo file produces a white space in its document and > Japanese texts usually do not use any white space. @c at the end of > line prevents texi2html from converting it's line break to a white > space. This is a suboptimal solution. texinfo (and texi2html) should have an option to control that, similar to my CJK package for LaTeX. > Of course, I think choice 1 is best. But if I should take choice 3, > it is better to put line breaks immediately after commas or periods > when I can. (They are "、" and "。" respectively in Japanese.) Similarly, kinsoku shori should be controlled by texi2html. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch to fix compile
> `make all' is currently broken on git master. This patch fixes the > problem. Applied, thanks. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
many texi2html warnings for lilypond-snippets.texi
Compiling the documentation in current git with `make web', texi2html (CVS version from 2009-01-09) produces zillion warnings like this: texi2html --I=/home/wl/lilypond/out/xref-maps \ --I=. \ --I=./out-www \ --output=out-www/lilypond-snippets/ \ --prefix=index \ --split=section \ --init-file=/home/wl/lilypond/lilypond-texi2html.init \ out-www/lilypond-snippets.texi *** Duplicate node found: Adding beams (in out-www/expressive-marks.texi l. 13 in @lydoctitle) *** Duplicate node found: Changing text and spanner styles for text dynamics (in out-www/expressive-marks.texi l. 407 in @lydoctitle) *** Duplicate node found: Printing metronome and rehearsal marks below the staff (in out-www/expressive-marks.texi l. 1635 in @lydoctitle) ... ** node_next `slurs' for `Adding beams' not found ** node_prev `ties etc. when using tuplet and non-tuplet rythms.' for `Adding beams' not found ** No node following `Adding ambitus per voice' in menu, but `Ambitus with multiple voices' follows in sectionning ... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: many texi2html warnings for lilypond-snippets.texi
>> Compiling the documentation in current git with `make web', texi2html >> (CVS version from 2009-01-09) produces zillion warnings [...] > > This was the simplest way I found to make TOC links for individual > snippets effective, and I guess "makeinfo --html" won't return > non-zero status with this. Very ugly :-) > A cleaner solution would be generating menus and @nodes in > makelsr.py and/or lystotely.py. Indeed. Perhaps you can emit a warning message in the makefile; something like: Please ignore the many warnings from texi2html. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: which fontforge version?
> while working on an update of the openbsd port of lilypond, i see > lots of fontforge whinings like this one: [...] > > > What (hopefully newer) version fontforge is typically used for > lilypond? I'm currently using a CVS version dated 2009-Jan-23, and I don't get a single warning. > And: does anyone using fontforge-20080927 on other operating systems > running into those errors? Yes, older FontForge versions have rounding problems. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: which fontforge version?
> Hopefully it is really caused by the rounding errors Werner > mentioned. Definitely. George says that he fights a never-ending battle :-) Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
links in LSR snippets
LSR files sometimes refer to the manual. Example:
makam-example.ly:
(see the `Learning Manual @version{}, 4.6.3 Other sources of
information' for the location of this file)
Such references to absolute section numbers are error-prone;
additionally, there is no proper hyperlink. Any idea how to do
better?
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: links in LSR snippets
>> LSR files sometimes refer to the manual. Example:
>
> I almost consider this a bug, especially if they reference the LM.
Yep.
> ... we *could* add a special "html" command for these in LSR. They
> would do nothing in the main LSR view, but when we run makelsr.py,
> we could change the new "html" command into @ref{}. Depending on
> how the build process works, these might be able to link back to the
> proper location.
>
> However, I really cannot see this being worth the (relatively
> speaking) enormous effort to modify LSR, modify makelsr.py, possibly
> modify the build process, and test the entire thing. I think we're
> looking at 20 hours of work to support something that perhaps a
> dozen badly-worded snippets use.
OK.
> To anticipate a possible objection: the snippets are not designed to
> teach lilypond basics.
Exactly.
A logical corrolary: LSR files must not refer to the documentation (or
rather, to exact locations in the docs); instead, the docs should
refer to LSR files. All references should be thus removed.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch for ja doc and two Questions
> Hidoi! Boku wa oyaji desu? Boku wa tada san-juu-sai! :( Soo desu ne! Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
what's in lilypond-mode.el?
Keyword completion in lilypond-mode.el is by default assigned to . With my openSuSE 11.1 X11 setup, this key apparently doesn't exist in Emacs 22.3.1 by default; I've only TAB (which is translated from ). It's easy to redefine this with .emacs, but I wonder why is used at all instead of plain . Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: what's in lilypond-mode.el?
> ah is this why I've never been able to get completion working in > LilyPond-mode? Probably. Add this to your .emacs file: (load-library "lilypond-mode") (define-key LilyPond-mode-map [tab] 'LilyPond-autocompletion) Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CFF font in PostScript for HP printers
> [...]. This all looks nice in Ghostview, Acrobat distiller handles > it and it prints on a Ricoh printer that I have access to. However, > I cannot make it work on any HP PS printers. I don't think the > problem is the binary data. It seems that the HP printers don't know > about the FontSet resource category: [...] My first guess is a bug in the HP printer's PostScript emulation. What about a printer with a native Adobe PS interpreter? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: Why is it _still_ so freaking hard to get info with images?
> If one uses the --sort option, one gets dozens of fonts. The Type1 > font is at the second place and increasingly dissimilar fallbacks > follow. The fontformat= entry does not seem to change anything any > which way. Using foundry=urw in contrast helps. But that probably > is asking more than you want. I don't think so. AFAIK, we want *exactly* the URW versions, so this looks like a good alternative. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: Why is it _still_ so freaking hard to get info with images?
>> I don't think so. AFAIK, we want *exactly* the URW versions, so >> this looks like a good alternative. > > Do we really want to use these particular clones in case there are > supposedly metrically identical fonts installed in a preferred > setting? IMHO yes. Those fonts are intended as fallback fonts; the user is free to override them with something different. > If for some reason, only the URW version of those fonts is > acceptable, the foundry=urw variant obviously is the way to go. I would it formulate differently: The URW fonts are free, they fit exactly our purposes, it doesn't hurt to install them, so make lilypond depend on them unconditionally. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: Why is it _still_ so freaking hard to get info with images?
> Maybe another solution is requiring other fonts, IIRC Werner > proposed TexGyre Schola a while ago. If we do the switch (which I still want to do but my usual lack of time prevents this), we enforce exactly the new font as the default, so the solution should be the same. > It looks like a good idea to append foundry=urw in fc-match call in > configure, but this fix will break when the foundry field of TTFs > shipped with Canorus changes from "unknown" to "urw" -- or maybe > this won't happen because TTF files will never provide "urw" as > foundry? I rely on advice from a fonts guru here. Sorry, I don't understand the problem. Why will this lilypond fix break something in Canorus or vice versa? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: Why is it _still_ so freaking hard to get info with images?
>> Sorry, I don't understand the problem. Why will this lilypond fix >> break something in Canorus or vice versa? > > Canorus installs Truetype versions of some of those fonts, > system-wide. The Lilypond configure command finds some of those > truetype fonts via fc-match in preference of the usual Type1 > versions coming with GhostScript. This causes compilation of > Lilypond to fail. This part I have understood. But I don't see a problem if we make lilypond find the Type 1 versions of the URW fonts. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: Why is it _still_ so freaking hard to get info with images?
> May I apply the patch below? > > - NCSB_FILE=`$FCMATCH --verbose "Century Schoolbook L:style=$style" | > - grep 'file:' | grep -v "\.ttf"` > + NCSB_FILE=`$FCMATCH --verbose "Century Schoolbook > L:style=$style:foundry=urw" | grep 'file:' | grep -v "\.ttf"` Looks good to me (if you use proper indentation :-). Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: Why is it _still_ so freaking hard to get info with images?
> However, Werner made it sound like Lilypond should come with its own > version of the fonts and use that, in which case it would seem sort of > pointless looking for the system-wide installation of those fonts. We need to find the system's Type 1 fonts to generate OTFs out of them, with fixed ligatures if necessary, and which are used locally only. Thus I think the patch is correct. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tab characters in the source code
> And wait, once we've founded our new group and taken over the world, > they'll have to call themselves ZEBRA Zebra" :-) This is not uncommon. For example, the common toad is called `Bufo bufo' in Latin; the human race is `Homo sapiens sapiens', etc., etc. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH -- Dashed Slurs
> Please review my patch for dashed slurs on rietveld: Very nice! What do you think about making `dash-definition' either accept a list of four parameters or a list of lists (with four parameters each)? Then we could write #'(a b c d) and are not forced to use #'((a b c d)) if the slur is not split into different segments. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH -- Dashed Slurs
>> Very nice! What do you think about making `dash-definition' either >> accept a list of four parameters or a list of lists (with four >> parameters each)? Then we could write >> >> #'(a b c d) >> >> and are not forced to use >> >> #'((a b c d)) >> >> if the slur is not split into different segments. > > If the slur is not split into different segments, a will be 0 and b > will be 1. So this proposal is still more complex than necessary. Indeed. So it could accept either two numbers or a list of quartuple lists. > What about just defining a function > > \setSlurDash dash-fraction dash-period > > that would create the appropriate entry for dash-definition? We > would also have \setPhrasingSlurDash. This is fine with me. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improve implementation of dashed slurs
> An example of a useful dashed bezier-sandwich arpeggio would be when > indicating arpeggios presumed to have been accidentally omitted from > a manuscript, within an urtext edition. I don't think so. The proper way would be rather to use an arpeggio typeset with a smaller design size. IMHO a dashed arpeggio looks horrible. The more curves the object itself has, the uglier. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improve implementation of dashed slurs
> Using a smaller design size might work with a squiggle-arpeggio, but > for composers who use the slur-arpeggio (I think Grieg was one?), > typesetting a thinner curve might be too subtle a difference. Ah, I haven't thought of the slur-arpeggio. Yes, I've meant the squiggle-arpeggio. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Markup commands \left-brace and \right-brace
>> Please review this patch here: >> >> http://codereview.appspot.com/8874/show > > Looks good! I'm not a good lisp programmer, but isn't the standard method for searching like that to not use a loop but recursive calls? It doesn't really matter, but Han-Wen likes to use recursive calls a lot :-) Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Date in the footer and Headers/Footers/Titles
> I'm a lot more willing to rename this section. I've seen > somewhere between 3-10 people confused by this in the past 5 > years. "Titular material"? "Headers and footers"? Any > suggestions for the name? Perhaps Headings, headers, and footers Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Date in the footer and Headers/Footers/Titles
> Or even > > Titles, Headings, and Headers/Footers I don't see an immediate difference between titles and headings. The latter includes the former AFAIK. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Date in the footer and Headers/Footers/Titles
> Since "Heading" and "Header" are extremely similar, explicitly > including the word "title" decreases the likelihood of > miscommunication and misunderstanding, which is what we're trying to > solve here. > > Kieren. Then I suggest Titles, Headings, Headers, Footers or something similar to avoid the nasty `/'. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Date in the footer and Headers/Footers/Titles
>> Then I suggest >> Titles, Headings, Headers, Footers >> or something similar to avoid the nasty `/'. > > Headings (Titles) and Margin Text (Headers and Footers) If I read `margin' I only think of left and right margins. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
two failing files during `make doc'
Folks, the files lily-50e2bfee.ly lily-7d242e8d.ly fail to be properly built during `make doc'. Using gs 8.64, I get messages like Substituting .notdef for glyphIndex11C in the font IPAGothic while converting the EPS. Older gs versions like 8.62 abort with an error, BTW. Reason is that lilypond accesses the Japanese IPAGothic font with artificial glyph names of the form `glyphIndexXXX' since the original TrueType font (ipag.ttf) doesn't contain glyph names in its `post' table -- virtually all CJK fonts miss that. If lilypond embeds the font itself in the EPS, it properly constructs the input code -> glyph index mapping table. However, loading the font with (/usr/share/fonts/truetype/ipag.ttf) (r) file .loadfont doesn't do this. Is there someone out here who has sufficient PS experience and knowledge of ghostscript to write some code which fixes this? A few months ago I asked on the gs-devel list how a TTF can be accessed by glyph indices within gs, and I got this answer, which isn't very helpful for me, unfortunately: You should load it as [a] CID font with specifying it in gs/Resource/Init/cidfmap . Then you can access glyphs by char codes in `cmap'. As to accessing by glyph indices, Ghostscript library doesn't provide that, but it may be done with a small development in Postscript. Note that access by character codes is *not* a possibility since we received the glyph indices by the Pango library which does the layout for text objects within lilypond. A quick fix is to handle those two files specially, explicitly activating font embedding while lilypond processes the files. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: two failing files during `make doc'
> A quick fix is to handle those two files specially, explicitly > activating font embedding while lilypond processes the files. An alternative is that lilypond itself forces embedding of the whole font if it detects that the font doesn't provide glyph names. On the other hand, it would be *very* useful if we have some code to access TTFs directly with glyph indices. Reason is that many TTFs -- even high quality MS fonts! -- sometimes have invalid or incorrect PS glyph names since they are rarely used in the MS world. A side effect would be smaller PS and EPS files because the char code->glyph index mapping table can be omitted. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
crash while processing lily-7d242e8d.ly
[git from today]
Running
lilypond lily-7d242e8d.ly
makes lilypond crash. Below is the full backtrace (I configured with
--disable-optimisation, BTW); not very informative, but...
valgrind gives the following:
Invalid read of size 4
at 0x80519A6: ly_car(scm_unused_struct*) (lily-guile.hh:187)
by 0x810DA8B: ly_error(scm_unused_struct*, scm_unused_struct*)
(general-scheme.cc:91)
by 0x40BB35F: scm_gsubr_apply (in /usr/lib/libguile.so.17.2.0)
by 0x40A5669: (within /usr/lib/libguile.so.17.2.0)
by 0x40A4141: scm_dapply (in /usr/lib/libguile.so.17.2.0)
by 0x40A295A: scm_apply (in /usr/lib/libguile.so.17.2.0)
by 0x40A36EB: scm_apply_0 (in /usr/lib/libguile.so.17.2.0)
by 0x81D45DE: Paper_book::classic_output(scm_unused_struct*)
(paper-book.cc:241)
by 0x80A1871: ly_book_process_to_systems(scm_unused_struct*,
scm_unused_struct*,
scm_unused_struct*,
scm_unused_struct*)
(book-scheme.cc:95)
by 0x40BB32E: scm_gsubr_apply (in /usr/lib/libguile.so.17.2.0)
by 0x40A3F06: scm_dapply (in /usr/lib/libguile.so.17.2.0)
by 0x40A4C58: (within /usr/lib/libguile.so.17.2.0)
Address 0x404 is not stack'd, malloc'd or (recently) free'd
Interestingly,
lilypond -dbackend=eps lily-7d242e8d.ly
works just fine.
Werner
==
Program received signal SIGSEGV, Segmentation fault.
0x080519a6 in ly_car (x=0x404) at ./include/lily-guile.hh:187
187 inline SCM ly_car (SCM x) { return SCM_CAR (x); }
(gdb) bt
#0 0x080519a6 in ly_car (x=0x404) at ./include/lily-guile.hh:187
#1 0x0810da8c in ly_error (str=0xb6c7a230, rest=0x404) at general-scheme.cc:91
#2 0xb7f0f360 in scm_gsubr_apply () from /usr/lib/libguile.so.17
#3 0xb7ef966a in ?? () from /usr/lib/libguile.so.17
#4 0xb7ef8142 in scm_dapply () from /usr/lib/libguile.so.17
#5 0xb7ef695b in scm_apply () from /usr/lib/libguile.so.17
#6 0xb7ef76ec in scm_apply_0 () from /usr/lib/libguile.so.17
#7 0x081d45df in Paper_book::classic_output (this=0x856fef8,
output=0xb6b45600) at paper-book.cc:241
#8 0x080a1872 in ly_book_process_to_systems (book_smob=0xb769e9f0,
default_paper=0xb73d1670,
default_layout=0xb72cdc78, output=0xb6b45600) at book-scheme.cc:95
#9 0xb7f0f32f in scm_gsubr_apply () from /usr/lib/libguile.so.17
#10 0xb7ef7f07 in scm_dapply () from /usr/lib/libguile.so.17
#11 0xb7ef8c59 in ?? () from /usr/lib/libguile.so.17
#12 0xb7efc7ab in scm_primitive_eval () from /usr/lib/libguile.so.17
#13 0x081df44f in internal_ly_parse_scm (ps=0xbfffbcb8) at parse-scm.cc:65
#14 0x081df4bf in ly_parse_scm (
s=0x848c2b3 "(let ((book-handler (if (defined?
'default-toplevel-book-handler)\n", ' ' ,
"default-toplevel-book-handler\n", ' ' ,
"toplevel-book-handler)))\n (cond ((pair? toplevel-boo"..., n=0xbfffbe10, i=
{start_ = 0xbfffbdd4
"��H\b��H\bXBK\b��H\b��H\bXBK\b�\210��\220\220D\bൢ�\004\002", end_ = 0x0,
source_file_ = 0x84ab498}, safe=false, parser=0x84ab498) at parse-scm.cc:128
#15 0x082ddf1e in Lily_lexer::yylex (this=0x857d1b8) at lexer.ll:340
#16 0x082e10b4 in yylex (s=0xbfffdcc0, loc=0xbfffd744, v=0x84ab498) at
parser.yy:2696
#17 0x082e266d in yyparse (my_lily_parser=0x84ab498) at out/parser.cc:2612
#18 0x082eef45 in Lily_parser::do_yyparse (this=0x84ab498) at parser.yy:2476
#19 0x0815370d in Lily_parser::parse_file (this=0x84ab498, init=
{static npos = 4294967295, _M_dataplus = {> =
{<__gnu_cxx::new_allocator> = {}, }, _M_p
= 0xbfffded0 "\024AK\b\230�J\b> =
{<__gnu_cxx::new_allocator> = {}, }, _M_p
= 0xbfffdecc
"\f�I\b\024AK\b\230�J\b> =
{<__gnu_cxx::new_allocator> = {}, }, _M_p
= 0xbfffdec8
"\234�I\b\f�I\b\024AK\b\230�J\b___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Fw: CTAN has a new package: figbas
W.r.t the current discussion this might be of interest. Werner --- Begin Message --- This package has been put up at tug.ctan.org and should soon be at your local mirror Thanks, Jim Hefferon Saint Michael's College . The following information was provided by our fellow contributor: Name of contribution: figbas Author's name: Bob Tennent Location on CTAN: /fonts/figbas Summary description: mini-fonts for figured-bass notation in music License type: lppl Announcement text: -- This package consists of three mini-fonts (and associated metrics) of conventional ligatures for the figured-bass notations 2+, 4+, 5+, 6+ and 9+ in music manuscripts. The fonts are usable with Computer Modern Roman and Sans, and Palatino/Palladio, respectively. -- This package is located at http://tug.ctan.org/tex-archive/fonts/figbas . More information is at http://tug.ctan.org/pkg/figbas (if the package is new it may take a day for that information to appear). We are supported by the TeX Users Group http://www.tug.org . Please join a users group; see http://www.tug.org/usergroups.html . ___ Ctan-ann mailing list ctan-...@dante.de https://lists.dante.de/mailman/listinfo/ctan-ann --- End Message --- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PDF Problem
> But, the key players dismissed it, did nothing and yes...2 years > later I am a bit frustrated. My post yesterday asking why after 2 > years nothing had been done, was not really too out of line if you > think about it. One of the key players, Rune, has passed away. We can answer your request differently: Noone has the expertise and sufficient interest to fix this particular problem, given that we have hundreds of more important bugs to fix. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PDF Problem
> BTW, I completely agree this thread was not handled well, not only > by me, but by everyone from its inception to the present entry which > I hope is its termination. Quite an ugly business! Very bad form > shown by all! I do offer my apologies for my part, and yes - by all > means I hope everyone is indeed getting on with more worthwhile > endeavors. To close this issue: Please submit a bug report, providing the images you've sent earlier to this list. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: include a sample "Makefile"?
> What do you guys think of including a sample Makefile somewhere in > the documentation? Good idea! Perhaps we can manage to avoid GNU make extensions so that poor Windows users have a chance to try nmake. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: include a sample "Makefile"?
> parts: > $(LILY_CMD) $(wildcard Parts/*.ly) > mv *.pdf $(OUTDIR)/ `wildcard' is a GNU extension. It can be circumvented with shell commands, however, I suggest to name the part files explicitly. >> $(OUTDIR)/%.pdf: Scores/%.ly Percent rules are a GNU extension. >> define movement_pdf_target Macro definitions are a GNU extension. >> $(foreach m, MOVEMENTS, $(call movement_pdf_target,$(m)) Both `foreach' and `call' are GNU extensions. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: include a sample "Makefile"?
> Pity. In that case, the original approach is best for portability I > suppose. Here's how I have the "parts" target now: > > parts: > for LILYFILE in Parts/*.ly ; do $(LILY_CMD) "$$LILYFILE" ; done > mv *.pdf $(OUTDIR)/ > > It works exactly as it did with the GNU wildcard, except that > multiple files can't be compiled at once with separate processors. > I'll probably stick with the GNU wildcard approach in my personal > makefiles, or else have both lines in there with one commented out. There's an easier solution: Store the result of the `ls' command in a variable and pass it in a single lilypond call (note the backquote characters): LILY_PARTS=`ls Parts/*.ly` parts: $(LILY_CMD) $(LILY_PARTS) mv *.pdf $(OUTDIR)/ I think it is safe to assume that an environment which has `bash' has `ls' too. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: include a sample "Makefile"?
> My bash-fu is minimal to non-existent, but couldn't you do something > like > > for LILYFILE in Parts/*.ly ; do $(LILY_CMD) "$$LILYFILE" & ; done > wait > mv *.pdf $(OUTDIR)/ > > ? > > I'm sure there's a command, and I think it is "wait", that says to > wait and collect status from all the jobs you've just spawned, so > the mv wouldn't run until all the LILY_CMD commands had completed. It's time consuming to call lilypond again and again. Far better to call it once only, processing all files in one run. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: include a sample "Makefile"?
> I changed the ` backticks to the $() construct on recommendations > from one of my scripting books, which alleges that backticks are > old-fashioned. BTW, you might read the `autoconf' documentation which has a few, quite long chapters on writing portable make and shell scripts. http://www.gnu.org/software/autoconf/manual/ > I really have no idea, but all of my scripts are done with the $() > construct. Of course in the makefile it has to become $$(foo). According to the abovementioned documentation, the shell construct `$(...)' is not supported everywhere; in particular, recent Solaris and IRIX versions of `sh' don't have it. > I doubt we'll ever come up with something everyone likes. I'm > learning a lot, though, so I don't mind all the conflicting > suggestions. :) It has nothing to do with `everybody likes it' or not. I think the main goal is to develop something which works everywhere. If we assume `GNU make' and `bash', it's far easier to write clean scripts. If we assume best portability, we have to circumvent a lot of problems... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: include a sample "Makefile"?
> Werner's point about multiple invocations of lilypond is very valid, > but on a multi-processor machine my technique will use all > processors. It'll probably be a bit slower on a uni-processor, > though. This is getting error prone. If you want to support multi-processor engines, just write a simple rule like .pdf: .ly lilypond ... mv ... and invoke `make' with `-j2' (or whatever numeric argument to -j is appropriate to your processor). Then `make' will take care of everything. > WITH the ampersand, all ten instances are fired off at once, taking > maybe 15 seconds, and then the code moves on to the next line. Uh, oh. You are aware that big lilypond scores need a few hundred MBytes to process? If you start, say, 10 lilypond processes at the same time, you'll get big troubles if you don't have enough main memory due to constant swapping. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: include a sample "Makefile"?
> [...] I'm wondring about a portable way to determine the number of > cores/CPUs present to adjust job-count value. On Linux: CPU_CORES=`cat /proc/cpuinfo | grep -m1 "cpu cores" | sed s/".*: "//` Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: include a sample "Makefile"?
> INPUTS= $(wildcard *.ly)
IMHO, exactly THIS statement should be replaced with an explicit list
of all input files so that you can disable or enable files at your
wish. Using the `\' character to suppress the end of line, you can
structure this very nicely:
INPUTS = \
foo-a.ly \
foo-b.ly \
\
bar-x.ly \
bar-y.ly \
...
If you are using GNU make, this can be also stated as
INPUTS += foo-a.ly
INPUTS += foo-b.ly
...
which makes it very easy to comment out the unused lines.
> if I run "make score" again (while there's a current pdf output of
> the file in the PDF dir), instead of saying it's up-to-date, it
> compiles the file again. Can you tell me which part of the makefile
> keeps track of the pdf output?
>
> [...]
>
> .ly.pdf:
> ${LILY_CMD} $<
>
> %.pdf %.midi: %.ly
Hmm. You give the same (well, almost the same) rule twice. This
old-fashioned (but fully portable) suffix rule
.x.y:
foo
is the same as this GNU make pattern rule:
%.x: %.y
foo
However, this pattern rule
%.pdf %.midi: %.ly
foo
says that both %.pdf and %.midi depend on %.ly, and `foo' generates
them both with a single invocation. (You can't express this with an
old-fashioned suffix rule). Having only
%.pdf %.midi: %.ly
$(LILY_CMD) $<
is thus sufficient.
One thing is still missing: The makefile must find the botu the input
and output files to check whether something needs to be remade. This
explicit rule:
score: PDF/${piece}.pdf
$(LILY_CMD) Scores/${piece}.ly
mv ${piece}.pdf PDF/
directly mentions that the output file is created in the `PDF'
subdirectory. The above pattern rule doesn't know that. This is the
reason why your files are made again and again if you use the `score'
target.
The solution to this problem is to use the special VPATH variable of
`make' which lists the directories for both targets and prerequisites.
A limitation is that the directories in `VPATH' are not expanded and
must be given directly (this seems to be undocumented; I'll contact
the GNU make people):
VPATH = /your/dir/Scores /your/dir/PDF
%.pdf %.midi: %.ly
cd PDF; $(LILY_CMD) $<
Note that you can't say
%.pdf %.midi: %.ly
cd PDF
$(LILY_CMD) $<
since `make' invokes the shell for each line separately, so the second
command doesn't see the `cd PDF' at all.
Finally, the `score' target can be simplified to
score: $(piece).pdf
The pattern rule does the rest.
> Also, what is the significance of the curly braces instead of
> parentheses in ${piece}?
Both do exactly the same.
See below for something which works fine for me.
Werner
==
piece = stamitz
LILY_CMD = lilypond -ddelete-intermediate-files \
-dno-point-and-click
.SUFFIXES: .ly .pdf .midi
VPATH = /your/dir/Scores /your/dir/PDF
%.pdf %.midi: %.ly
cd PDF; $(LILY_CMD) $<
.PHONY: score
score: ${piece}.pdf
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: include a sample "Makefile"?
> The terminal output for individual jobs is lost, but it processes > much faster. Redirect the logging output to log files. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: include a sample "Makefile"?
> A limitation is that the directories in `VPATH' are not expanded and
> must be given directly (this seems to be undocumented; I'll contact
> the GNU make people):
This was my mistake. I forgot about the `shell' function. Here's a
revised version of the Makefile.
Werner
==
piece = stamitz
LILY_CMD = lilypond -ddelete-intermediate-files \
-dno-point-and-click
.SUFFIXES: .ly .pdf .midi
curdir = $(shell pwd)
VPATH = $(curdir)/Scores $(curdir)/PDF
%.pdf %.midi: %.ly
cd PDF; $(LILY_CMD) $<
.PHONY: score
score: ${piece}.pdf
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: include a sample "Makefile"?
>> A limitation is that the directories in `VPATH' are not expanded
>> and must be given directly (this seems to be undocumented; I'll
>> contact the GNU make people):
>
> This was my mistake. I forgot about the `shell' function. Here's a
> revised version of the Makefile.
And two other corrections: `make' provides the CURDIR variable
automatically, and using `:=' immediately sets `VPATH' to its final
value.
Werner
==
piece = stamitz
LILY_CMD = lilypond -ddelete-intermediate-files \
-dno-point-and-click
.SUFFIXES: .ly .pdf .midi
VPATH := $(CURDIR)/Scores $(CURDIR)/PDF
%.pdf %.midi: %.ly
cd PDF; $(LILY_CMD) $<
.PHONY: score
score: ${piece}.pdf
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: include a sample "Makefile"?
> Does this now resemble something I can make generic and put in the > docs? Not yet. See below for something which fits better the 80 chars line length limit. You've forgotten the driver files for the full score and the movements; I've added it now. Note that it wouldn't be necessary to mention the *.ly files explicitly since the pattern rule automatically looks for them. Only the additional dependencies must be named. However, I personally prefer to list them all to avoid confusion. You might remove them if you wish. > Any GNU Make extensions left in there? Full of them. :-) To be serious: I suggest that we concentrate on GNU make only since it is (a) available on almost all platforms and (b) is really much more user friendly than other make programs. BTW, if you really can't use a `GNU make' binary, you can replace it with the `makepp' program, written in perl: http://makepp.sf.net A final point which I ask you to change: You should call the parts something like `stamitz-cello.pdf' instead of just `cello.pdf'. As soon as you've written many scores it helps a lot if all output files have names which makes identification easy. Werner PS: There might be typos in my modifications, so please test them. == # # This is a Makefile for `GNU make'! It uses extension # not available in most other `make' programs. # # The name stem of the output files. piece = stamitz # The command to run lilypond. LILY_CMD = lilypond -ddelete-intermediate-files \ -dno-point-and-click # The used suffixes in this Makefile. .SUFFIXES: .ly .ily .pdf .midi # Output files are created in the `PDF' subdirectory # of the current directory. # Input files are searched in the other directories # listened in the VPATH variable. curdir = $(shell pwd) VPATH = \ $(curdir)/Scores \ $(curdir)/PDF \ $(curdir)/Parts \ $(curdir)/Notes # The pattern rule to create PDF and MIDI files # from a LY input file. %.pdf %.midi: %.ly cd PDF; $(LILY_CMD) $< # A shorthand. notes = \ cello.ily \ figures.ily \ horn.ily \ oboe.ily \ trioString.ily \ viola.ily \ violinOne.ily \ violinTwo.ily # The depencies of the full score. $(piece).pdf: $(piece).ly $(notes) # The dependencies of the movements. $(piece)I.pdf: $(piece)I.pdf $(notes) $(piece)II.pdf: $(piece)II.pdf $(notes) $(piece)III.pdf: $(piece)III.pdf $(notes) $(piece)IV.pdf: $(piece)IV.pdf $(notes) # The dependencies of the parts. cello.pdf: cello.ly cello.ily \ figures.ily \ trioString.ily horn.pdf: horn.ly horn.ily oboes.pdf: oboes.ly oboe.ily viola.pdf: viola.ly viola.ily violinOne.pdf: violinOne.ly violinOne.ily violinTwo.pdf: violinTwo.ly violinTwo.ily # Say `make score' to generate the full score. .PHONY: score score: $(piece).pdf # Say `make movements' to generate files for the # four movements separately. .PHONY: movements movements: $(piece)I.pdf \ $(piece)II.pdf \ $(piece)III.pdf \ $(piece)IV.pdf # Say `make parts' to generate all parts. # Say `make foo.pdf' to generate the part for instrument `foo'. # Example: `make cello.pdf'. .PHONY: parts parts: cello.pdf \ violinOne.pdf \ violinTwo.pdf \ viola.pdf \ oboes.pdf horn.pdf # end of Makefile ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: include a sample "Makefile"?
> PS: There might be typos in my modifications, so please test them. Uff, indeed there are typos. Attached an improved version. Werner == # # This is a Makefile for `GNU make'! # It uses extensions not available in most other `make' programs. # # The name stem of the output files. piece = stamitz # The command to run lilypond. LILY_CMD = lilypond -ddelete-intermediate-files \ -dno-point-and-click # The used suffixes in this Makefile. .SUFFIXES: .ly .ily .pdf .midi # Input and output files are searched in the directories listened in # the VPATH variable. All of them are subdirectories of the current # directory (given by the GNU make variable `CURDIR'). VPATH = \ $(CURDIR)/Scores \ $(CURDIR)/PDF \ $(CURDIR)/Parts \ $(CURDIR)/Notes # The pattern rule to create PDF and MIDI files from a LY input file. # Output files are created in the `PDF' subdirectory. %.pdf %.midi: %.ly cd PDF; $(LILY_CMD) $< # A shorthand. notes = \ cello.ily \ figures.ily \ horn.ily \ oboe.ily \ trioString.ily \ viola.ily \ violinOne.ily \ violinTwo.ily # The dependencies of the full score. $(piece).pdf: $(piece).ly $(notes) # The dependencies of the movements. $(piece)I.pdf: $(piece)I.pdf $(notes) $(piece)II.pdf: $(piece)II.pdf $(notes) $(piece)III.pdf: $(piece)III.pdf $(notes) $(piece)IV.pdf: $(piece)IV.pdf $(notes) # The dependencies of the parts. cello.pdf: cello.ly cello.ily \ figures.ily \ trioString.ily horn.pdf: horn.ly horn.ily oboes.pdf: oboes.ly oboe.ily viola.pdf: viola.ly viola.ily violinOne.pdf: violinOne.ly violinOne.ily violinTwo.pdf: violinTwo.ly violinTwo.ily # Say `make score' to generate the full score. .PHONY: score score: $(piece).pdf # Say `make movements' to generate files for the # four movements separately. .PHONY: movements movements: $(piece)I.pdf \ $(piece)II.pdf \ $(piece)III.pdf \ $(piece)IV.pdf # Say `make parts' to generate all parts. # Say `make foo.pdf' to generate the part for instrument `foo'. # Example: `make cello.pdf'. .PHONY: parts parts: cello.pdf \ violinOne.pdf \ violinTwo.pdf \ viola.pdf \ oboes.pdf horn.pdf # end of Makefile ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: include a sample "Makefile"?
> Are these typos in the block below? It looks as if the $(piece)I.pdf > after the colon should read "$(piece)I.ly". Yes, of course these are typos. :-) > Ok I'm trying to figure a way to make the output file names add > $(piece)- to each one automatically instead of changing the source > file names. Don't tell me how just yet, I'm keen to figure it > out. :) Hmm. I rather suggest that you really rename all input files accordingly, not using trickery to rename the output files after compilation. > BTW I like the #comments in the makefile very much. Is it o.k. to > keep those for the docs? Of course. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: include a sample "Makefile"?
> For the moment I've added a crude method of putting the midi files in > the MIDI/ dir: > >mv PDF/*.midi MIDI/ > > If there's a way to automate this it would look nicer. Also, it only > works on the "make movements" command. I tried "make stamitzIV.pdf" > just now and it kept the midi file in the PDF directory. Sigh. This slight adaptation of the pattern rule does what you want. %.pdf %.midi: %.ly $(LILY_CMD) $<; \ if test -f "$*.pdf"; then \ mv "$*.pdf" PDF/; \ fi; \ if test -f "$*.midi"; then \ mv "$*.midi" MIDI/; \ fi Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: page breaking changed in 2.13 ???
> i am using a 2.13 lilypond compiled from today's git repo, and i am > observing - in comparison to a version from around 10th of April - > that the page breaking strategy seems to have changed significantly. > Which leads me in one case of a before 47page piano reduction score > (1 to 4 staves per page, staff lines number irregular) becoming a > 123page score only having one line per page, even if just being a > piano solo line... This looks like a bug. Can you reduce it so that Joe can check it? > P. S. I would also be grateful for instructions to roll back my > source tree to the April version, if that is the easiest... Just use `gitk' to select a certain revision (or tag) `foo'. Then say, on the command line, git checkout foo and compile this. Later, you might revert to the top of git with git checkout master Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: revising LM "Score and Parts"
>> I don't know what >> $(LILY_CMD) $<; \ >> means, This calls lilypond -- or rather the contents of the variable LILY_CMD -- with the prerequisite (the *.ly file) as the argument. >> but the two if statements seem to check if there are any pdf or >> midi files around and then move them to their directories. >> >> On Windows this can be achieved as follows: >> if exist *.pdf move "*.pdf" PDF/ >> if exist *.midi move "*.pdf" MIDI/ > > If it has to be on one line: > if exist *.pdf move "*.pdf" PDF/ & if exist *.midi move "*.pdf" MIDI/ It is not necessary to put everything on a single line, but if you do so you avoid (at least under GNU/Linux) additional calls to the command shell, making the execution faster. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: revising LM "Score and Parts"
>> I've made some progress. When I try to run "make score" on Windows >> XP, As it stands, the Makefile doesn't work with Windows. For documentation purposes I strongly suggest to cook up a special Windows Makefile with the same functionality. >>%.pdf %.midi: %.ly >> $(LILY_CMD) $<; \ >> if test -f "$*.pdf"; then \ >>mv "$*.pdf" PDF/; \ >> fi; \ >> if test -f "$*.midi"; then \ >>mv "$*.midi" MIDI/; \ >> fi >> >> Now, the full score compiles if I change the score target to this: >> >>score: >> $(LILY_CMD) Scores/$(piece).ly >> >> So it looks like the Windows environment doesn't know how to deal >> with the pattern rule defined at the top of the Makefile. If nothing compiles then the Makefile doesn't find the *.ly files in the `Score' subdirectory. This means that the VPATH settings don't work. Do you use the `CURDIR' variable in the VPATH path elements? BTW, you can see the exact make rules with make -r -R -p Makefile Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: revising LM "Score and Parts"
>> If there is at least one blank (on a german Windows the home >> directory is called "c:\Dokumente und Einstellungen\") >> searching does not work. I suggest that you contact the help-m...@gnu.org mailing list, providing a minimal (trivial) example demonstrating the VPATH problem. Either this is a bug in the Windows port of GNU make, or they know a solution. >> # The pattern rule to create PDF and MIDI files from a LY input >> # file. The .pdf output files are created in the `PDF' >> # subdirectory, and the .midi files are put into the `MIDI' >> # subdirectory. >> %.pdf %.midi: %.ly >> $(LILY_CMD) $< >> if exist "$*.pdf" move /Y "$*.pdf" PDF/ >> if exist "$*.mid" move /Y "$*.mid" MIDI/ Uuh, you are using `%.midi' in the rule but you are moving *.mid files! You should use `%.mid' too since this is what lilypond creates if run on Windows, right? The comment should be updated accordingly. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: revising LM "Score and Parts"
>> Uuh, you are using `%.midi' in the rule but you are moving *.mid >> files! You should use `%.mid' too since this is what lilypond >> creates if run on Windows, right? The comment should be updated >> accordingly. > > You're right, but oddly, it worked as expected even without fixing > the pattern rule. The .mid files were put into the MIDI directory. Well, if you don't mention the MIDI file somewhere else in the Makefile, the `%.midi: %.ly' rule never gets executed -- it is the `%.pdf: %.ly' part which creates both PDF and MIDI output (and which subsequently gets renamed afterwards). For testing purposes, you might try to add foo: $(piece)I.mid to the make file, retaining the incorrect rule. Now saying make foo won't work at all. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: better error msg for ambiguous (de)crescendo?
> Here are my candidates: > "warning: impossible or ambiguous (de)crescendo." > "warning: impossible or ambiguous (de)crescendo (MIDI)." > "warning: ignoring impossible or ambiguous (de)crescendo." > "warning: ignoring impossible or ambiguous (de)crescendo (MIDI)." > "warning: MIDI found an impossible or ambiguous (de)crescendo." > "warning: MIDI is ignoring an impossible or ambiguous (de)crescendo." > > Anyone care to vote, suggest an alternative, or express > an opposition to this idea? What about warning: MIDI: impossible or ambiguous (de)crescendo: ignored It looks horrible from a grammatical point of view, but it probably makes scanning through log files easier. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: better error msg for ambiguous (de)crescendo?
> warning: lilypond cannot interpret a (de)crescendo. > MIDI output ignoring (de)crescendo starting at line . > > This way the diagnostic states why Lily can't do what the user has > coded, what it's doing as a result, and the consequences of the > error condition detected. This is not precise enough IMHO, since you won't get an error if you don't produce MIDI output... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: where to put useful lists in the docs?
> [...] why not define a function that takes a function and a list of > pairs? It's usual to have procedure arguments: > > (define (map-on-pairs fn pairs) > (cons (apply fn (map car pairs)) > (apply fn (map cdr pairs > > (map-on-pairs + '((1 . 1) (2 . 3) (5 . 8))) => (8 . 12) > (map-on-pairs min '((1 . 8) (1 . 5) (2 . 3))) ==> (1 . 3) Very nice! Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Issue?] hiding Accidental(s) on tied note(s) after a line break
> shortest note playing here.")
> (shortest-starter-duration ,ly:moment? "The duration of the
> shortest note that starts here.")
> + (hide-tied-accidental-after-break ,boolean? "If set, an accidental
> +that appears on a tied note after a line break will not be displayed")
> (side-axis ,number? "If the value is @code{#X} (or
> equivalen...@tie{}@code{0}), the object is placed horizontally next to
> the other object. If the value is @code{#Y} o...@tie{}@code{1}, it is
Joe, items in define-grob-properties.scm are sorted alphabetically.
Please move it to the right location.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
bad formatting of lilypond grammar
The lilypond grammar contains some extremely long lines which look very bad in formatting (and are difficult to comprehend), for example 206 music_function_chord_body: music_function_identifier_musicless_prefix EXPECT_MUSIC function_arglist_nonmusic chord_body_element 207 | music_function_identifier_musicless_prefix function_arglist_nonmusic Is it possible to fix the formatting so that lines are not exceeding the 80 character length limit, as shown above? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
beat grouping vs. beam grouping
In the docs there are references to both `beam-grouping' and `beat-grouping'. This is confusing. However, `beam-grouping' doesn't exist in the source code. I thus suggest to replace `beam-grouping' with `auto-beam beat-grouping' just to avoid the term `beam-grouping' altogether. The snippet `beam-grouping-in-7-8-time.ly' should probably be renamed too. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
setting `to-barline' for trills too?
Currently, `to-barline' is set to ##f for trills. What about changing it so that ##t is the default? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: beat grouping vs. beam grouping
> A git grep for beam-grouping returned only the snippet you referenced above. > > A git grep for "beam grouping" returned only one reference which was in the > snippet you referenced above. > > Can you be more specific about where the doc references to > beam-grouping are? Sorry, for being imprecise. I mean that `beat.?[Gg]rouping' is used in the source code, too, so we should avoid `beam grouping'. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: meta-proposal
> What do people think about adding an extra mailing list: > lilypond-proposals? I dislike that. Two lists are fully sufficient IMHO. Probably all lilypond-devel readers would subscribe that too, so where's the benefit? It makes discussion more complicated if someone is discussing a problem on lilypond-devel and is suddenly `forced' to continue a possible bigger solution on lilypond-proposals. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: include a sample "Makefile"?
> http://www.jonathankulp.com/makefiles.pdf . What does the `$' in the directory structure stands for? . There's a severe error in the `%.pdf %.midi' rule: Its command is not indented! You have to convert the `tab' characters into something different (probably eight spaces) to get proper indentation and tell the user that tab characters must be used there.[1] The same holds for the command of the `archive' target; in the other makefiles which I have just skimmed there are similar issues. Werner [1] Well, only the very first character right before $(LILY_CMD) must be a tab since all other lines are just a continuation of the first one, but this little `white lie' doesn't do any harm IMHO. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: include a sample "Makefile"?
> I think I've cleaned up all of the indentation problems Werner > pointed out [...] I'm still not happy. Use only tabs (which translates to eight spaces) where necessary. In all other cases I suggest an indentation of two spaces or nice vertical alignment. Additionally, you should add the excellent comment # this line begins with a tab to all relevant places. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: include a sample "Makefile"?
> This makes sense. I think I have it now... Thanks! A last question: Why is the contents of build.bat double-spaced? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: include a sample "Makefile"?
>> Why is the contents of build.bat double-spaced? >> > > No particular reason. Should it be single-spaced? It doesn't matter, but single spacing looks better IMHO in the info PDF. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: CG addition--running stable and devel at once
> http://www.jonathankulp.com/stable-devel.pdf BTW, to run stable and development versions in parallel, I do it a bit differently: . `stable': Configure and install as normal. . `devel': Configure with ./configure --prefix=/usr/local/test and install as normal. . If I want to use the development version, I then say PATH=/usr/local/test/bin:$PATH lilypond ... This part can be saved into a file, of course. So it's the question what exactly you want to achieve if you say `use the development version'. Leaving the binary directly in the compilation directory probably makes it difficult to say `git pull' without recompilation afterwards. [Well, I always compile in a separate directory after cloning the repository with `git clone -l -s . ../lilypond.compiled' so that `git pull' in the original git repository is safe too -- if I want to synchronize the compilation directory I simply say `git pull' there too.] Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOCS: CG addition--running stable and devel at once
> Maybe I should add your method as well? I think it's not worth the trouble. I'm just used to my habit, and it probably really hasn't great benefits. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] should it be @code{\\addInstrumentDefinition} ?
> I made this change in music-functions-init.ly:
>
> -...@var{\addinstrumentdefinition}.")
> +...@code{\addinstrumentdefinition}.")
>
> However, the \a is still showing up as a control character 0x07,
> [...]
>
> Can someone explain why it works in one file but not in the other?
Documentation in .ly files are handled by lilypond itself, this is,
the `lilypond' binary is called to produce files included by the
texinfo system. And `lilypond' needs two backslashes which are then
reduced to a single one. The same is true for Scheme files.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: html validator yields errors
> Clicking on the lilypond.org W3C HTML 4.0 validator button yields errors: > > http://validator.w3.org/check?uri=http%3A%2F%2Flilypond.org%2Fweb%2F;accept=text%2Fhtml%2Capplication%2Fxhtml%2Bxml%2Capplication%2Fxml%3Bq%3D0.9%2C*%2F*%3Bq%3D0.8;accept-language=en-us%2Cen%3Bq%3D0.5;accept-charset=ISO-8859-1%2Cutf-8%3Bq%3D0.7%2C*%3Bq%3D0.7 I just followed this link and it is checked successfully. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: development on windows
> (again, I'm happy to dump whatever suggestions people throw at me > in the CG) A very nice IDE with editor and debugger (the latter is really nice IMHO) for python -- both available for Linux and Windows -- is Eric: http://eric-ide.python-projects.org/ Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: some sort of suppress-accidental?
> Please don't extend the syntax lightly. Try to make something based > on music functions or \tweak first; if it finds wide spread > adoption, you can always add cute syntax later. Given the infrequency of this request, I second this. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: some sort of suppress-accidental?
>> > Please don't extend the syntax lightly. Try to make something >> > based on music functions or \tweak first; if it finds wide spread >> > adoption, you can always add cute syntax later. >> >> Given the infrequency of this request, I second this. > > Just found this... (: > > http://lists.gnu.org/archive/html/lilypond-devel/2005-04/msg00081.html A request again after four years: I call this infrequent :-) Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: define-grobs.scm properties not alphabetical
>> > Alphabetical order makes the most sense to me in this case, with >> > the grob alist. Yes. > I prefer case-insensitive so X-offset and Y-offset are near the > bottom (where I expect to find them). Let me know if you object. Please use the alphabetical ordering used in other SCM files. I don't mind if you move around the uppercased properties in all SCM files, but it should be consistent -- maybe it makes sense to document the ordering in the SCM files itself... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: proposals for LM B. Scheme tutorial
>> The formatting is bad. >> >> > #(begin >> >(define foo 0) >> >(define bar 1)) >> >> Parentheses are never left alone on a line. > > I respectfully* disagree: [...] Well, putting trailing parentheses into separate lines is useful while writing code -- I do this too, but finally they get condensed into a single line. We do this everywhere in the SCM files. As a rule, we indent Scheme code almost always in the same way as the Scheme mode of Emacs does. There, a simple TAB keypress indents correctly. Additionally, Emacs provides functions to find the matching opening parenthesis; another reason to condense parentheses. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: type-check list in NR 6.1.1
> Alternatively, a new .scm file (similar to define-grobs.scm or > define-grob-interfaces.scm) could be created: define-predicates.scm. > This would define an alist of predicate types and predicates, and > any predicates that were found by your routine and were not included > in the define-predicates alist would be classified as "Other" or > "Unknown". To me, this sounds like the right and probably easiest way to go. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Solving segmentation fault problem in gdb
> Any thoughts on how to debug this segmentation fault in gdb? You might try to run valgrind on lilypond, ignoring the zillions of warnings regarding Scheme (or use a valgrind suppress file -- a few years ago Han-Wen has posted something): This should give you the `hot spot' which causes the segfault. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: new vertical layout engine
>> Thanks, these are both fixed now. I've configured PianoStaff to >> stretch by default, but by a smaller amount than the other staff >> groups. At this point, though, all of the default settings are >> provisional (ie. if someone would try out different values and >> choose something that looks good (or looks like professional >> scores), that would be much appreciated). > > I might be totally out of place here, but could we imagine that this > could be a good time to consider implementing #442? I second this. However, I would prefer if the selection of staves which survive harakiri can be selected on a more fine-grained level (possibly in addition to Kieren's suggestion). Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
fuzzy horizontal positioning
I would like to see the following implemented, which would *greatly* enhance typesetting, reducing manual positioning a lot. The problem: A symbol like `f' is normally positioned below the note it is attached to. However, since `f' is quite a tall glyph, it needs a large amount of vertical space. Especially in full scores, this can lead to serious vertical spacing issues. In many cases, however, the `f' can be moved up considerably if it is slightly moved to the left at the same time: either there is a rest before the note, or the distance to the previous note is sufficiently large to do such a shift without collision. Obviously, this must be done manually currently. The idea: We could introduce `fuzzy horizontal positioning', allowing movable symbols like the `f' to deviate from its ideal position automatically. An algorithm could look like this: 1. Do a normal layout and check whether there are movable symbols which stick out extremely in the vertical direction, and which detoriorate the vertical layout. 2. Try to do a fuzzy horizontal positioning for all affected symbols. 3. Continue with layout. I have no idea whether this can be easily implemented... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
