Re: GOP2-3 - GLISS or not
On Tue, Jul 24, 2012 at 3:09 AM, Graham Percival wrote: > Some “computer languages” are fairly stable. A TeX or C++ program > written 10 years ago will probably still compile with no > modifications (notwithstanding the g++ 4.3 header and namespace > changes). The same is not true of LilyPond; even after using > convert-ly, there are still bits that require manual updating. > As another example, I regularly use scientific Fortran codes that are 30 or 40 years old and have been made available as Python modules. Stability is certainly a good thing so long as it doesn't prevent genuine improvements in LilyPond. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
autoconf not mentioned in build dependencies
I'm building from scratch on a new Ubuntu install and autoconf is not mentioned as a requirement: http://lilypond.org/doc/v2.13/Documentation/contributor/requirements-for-compiling-lilypond Is this an omission in the documentation or a problem with the packaging (i.e. sudo apt-get build-dep lilypond)? Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: feedback: general thoughts about using LilyPond
2011/3/13 Janek Warchoł :
> 3. I have serious troubles with vertical layout of choral scores containing
> anything besides notes. Slurs, and especially dynamics, tend to make systems
> very high; i struggle to achieve 4 systems-per-page layout, which is always
> certainly possible, but tweaking needed to achieve this is always
> hit-and-miss. It looks like Lily tries *too* hard to avoid objects being too
> close and colliding; this leads to problems.
Some of this is caused by the rectangular skylines that LilyPond uses
around slurs:
\version "2.13.54"
#(ly:set-option 'debug-skylines #t)
\relative c' { << {e4( f g c b1)} \\ {c,4( d e f g1)\p} >>}
(A longer slur would produce a more extreme example.) Segmenting the
skyline into a number of tangent lines would improve things (even two
or three would help), but that's pretty far beyond my skills right
now.
- Just a tadpole, a.k.a. Andrew
<>___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch: doc typo
On Tue, Mar 1, 2011 at 9:54 PM, Werner LEMBERG wrote:
>
>> +requires additional calculations. To speed up processing slighty, this
> ^^^
>
> slightly :-)
>
>
> Werner
>
Thanks!
{dumb typo} * 2
From e154cf8e2e3cbed2a2fed9876d92d57f127637ff Mon Sep 17 00:00:00 2001
From: Andrew Hawryluk
Date: Tue, 1 Mar 2011 20:35:34 -0700
Subject: [PATCH] Doc: typos in vocals.
---
Documentation/notation/vocal.itely |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/notation/vocal.itely b/Documentation/notation/vocal.itely
index e63729b..b337d26 100644
--- a/Documentation/notation/vocal.itely
+++ b/Documentation/notation/vocal.itely
@@ -1159,7 +1159,7 @@ To make this change for all lyrics in the score, set the property in the
@c TODO: move to LSR -vv
Checking to make sure that text scripts and lyrics are within the margins
-required additional calculations. To speed up processing slighty, this
+requires additional calculations. To speed up processing slightly, this
feature can be disabled:
@example
--
1.7.1
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Patch: doc typo
Just found a dumb typo in my recent edits (regarding keep-inside-line = ##t). Thanks! From b5900c53d179cbff1c08e3ff5c78ec2adf14fff1 Mon Sep 17 00:00:00 2001 From: Andrew Hawryluk Date: Tue, 1 Mar 2011 20:35:34 -0700 Subject: [PATCH] Doc: typo in vocals. --- Documentation/notation/vocal.itely |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/notation/vocal.itely b/Documentation/notation/vocal.itely index e63729b..99d0353 100644 --- a/Documentation/notation/vocal.itely +++ b/Documentation/notation/vocal.itely @@ -1159,7 +1159,7 @@ To make this change for all lyrics in the score, set the property in the @c TODO: move to LSR -vv Checking to make sure that text scripts and lyrics are within the margins -required additional calculations. To speed up processing slighty, this +requires additional calculations. To speed up processing slighty, this feature can be disabled: @example -- 1.7.1 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Change keep-inside-line defaults to true. (issue4243041)
My bad!
The attached post corrects this oversight. Graham, can you upload
this? I won't get a chance to figure out that git-cl this week.
Andrew
On Sun, Feb 27, 2011 at 5:16 PM, wrote:
>
> http://codereview.appspot.com/4243041/diff/1/Documentation/snippets/editorial-headword.ly
> File Documentation/snippets/editorial-headword.ly (right):
>
> http://codereview.appspot.com/4243041/diff/1/Documentation/snippets/editorial-headword.ly#newcode2
> Documentation/snippets/editorial-headword.ly:2: % generated from
> Documentation/snippets/new
> why is this editing a file marked DO NOT EDIT ?
>
> http://codereview.appspot.com/4243041/
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-devel
>
From db329c3acaee4d7d0e4b7efa6f8bef98f96aaf45 Mon Sep 17 00:00:00 2001
From: Andrew Hawryluk
Date: Sat, 15 Jan 2011 13:42:03 -0700
Subject: [PATCH] Change keep-inside-line defaults to true.
As discussed in Issue #1470, the default should be changed so that
good layout with a slight performance hit is the default.
---
Documentation/learning/tweaks.itely| 35 ---
Documentation/notation/text.itely |7 +-
Documentation/notation/vocal.itely |8 +-
Documentation/snippets/new/ancient-headword.ly |8 --
Documentation/snippets/new/chords-headword.ly |8 --
Documentation/snippets/new/editorial-headword.ly |8 --
.../snippets/new/figured-bass-headword.ly |8 --
Documentation/snippets/new/fretted-headword.ly |2 -
Documentation/snippets/new/pitches-headword.ly |8 --
.../snippets/new/simultaneous-headword.ly |9 --
Documentation/snippets/new/text-headword.ly|8 --
Documentation/web/ly-examples/example-header.ily |8 --
input/regression/balloon.ly| 19 +++-
input/regression/font-bogus-ligature.ly| 13 ++-
input/regression/font-family-override.ly | 32 --
input/regression/font-name.ly |1 +
input/regression/hairpin-ending.ly |1 +
input/regression/harp-pedals-sanity-checks.ly |1 +
input/regression/harp-pedals-tweaking.ly |1 +
input/regression/lyric-extender-right-margin.ly|3 +-
input/regression/lyrics-no-notes.ly|1 +
input/regression/markup-commands.ly| 55 ++-
input/regression/markup-note.ly| 100 +++-
input/regression/markup-syntax.ly | 88 ++
input/regression/markup-user.ly| 15 ++-
input/regression/skyline-vertical-placement.ly |1 +
input/regression/spacing-stick-out.ly |7 +-
scm/define-grobs.scm |2 +
28 files changed, 212 insertions(+), 245 deletions(-)
diff --git a/Documentation/learning/tweaks.itely b/Documentation/learning/tweaks.itely
index 844399d..99cfcf6 100644
--- a/Documentation/learning/tweaks.itely
+++ b/Documentation/learning/tweaks.itely
@@ -3422,7 +3422,6 @@ lhMusic = \relative c' {
* Using variables for tweaks::
* Style sheets::
* Other sources of information::
-* Avoiding tweaks with slower processing::
* Advanced tweaks with Scheme::
@end menu
@@ -4106,40 +4105,6 @@ interest are:
@end multitable
-
-@node Avoiding tweaks with slower processing
-@subsection Avoiding tweaks with slower processing
-
-LilyPond can perform extra checks while it processes input files.
-These checks will take extra time to perform, but fewer manual tweaks
-may be required to obtain an acceptable result. If a text script
-or part of the lyrics extends over the margins these checks will
-compress that line of the score just enough to fit within the
-margins.
-
-To be effective under all circumstances these checks must be enabled
-by placing the overrides using @code{\context} within a @code{\layout}
-block, rather than in-line in music, as follows:
-
-@example
-\score @{
- @{ @dots{}notes@dots{} @}
- \layout @{
-\context @{
- \Score
- % Makes sure text scripts and lyrics are within the paper margins
- \override PaperColumn #'keep-inside-line = ##t
- \override NonMusicalPaperColumn #'keep-inside-line = ##t
-@}
- @}
-@}
-@end example
-
-However, @code{keep-inside-line} is expensive and the recommendation
-is to not enable it, to allow for faster processing, until creating
-a final version. This way you do not need to manually add @code{\break}
-commands to avoid text running off the right-hand side of the page.
-
@node Advanced tweaks with Scheme
@subsection Advanced tweaks with Scheme
diff --git a/Documentation/notation/text.itely b/Documentation/notation/text.itely
index 6841e44..406f6be 100644
--- a/Documentation/notation/text.itely
+++
Re: Potential fix for issue 37
2011/1/8 Werner LEMBERG : > BTW, has someone done some research in trying to find printed, > well-engraved examples? I've only got one off the top of my head, the final example on this page: http://www.musicbyandrew.ca/finale-lilypond-2.html It's only one data point, but it does argue in favour of a sloped-but-damped approach. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Black mensural notation
I tried running it on a current development snapshot this week, but it didn't have enough memory to run nicely and bogged down my computer with swap traffic (I've got 2 MB here). I gave up on it before it finished. Does it take long to compile the PDF on your system? Andrew On Tue, Jan 4, 2011 at 6:14 AM, Lukas Pietsch wrote: > On Tue, 2011-01-04 at 11:49 +0100, Werner LEMBERG wrote: > >> Very impressive! Could you try to make it work with the current >> development version? The next steps could then be adding the missing >> glyph shapes to the lilypond fonts, followed by either writing a new >> engraver or modifying/fixing/correcting the existing ones.q > > Unfortunately, I've had some problems getting any other version than the > current standard package from my Linux distribution cleanly installed on > my system (probably I'm just not Linux-savvy enough). I've now uploaded > a test file http://lukas-pietsch.de/Music/mensuraltest.ly and the > expected output http://lukas-pietsch.de/Music/mensuraltest.pdf, with the > same snippets as in the documentation pdf. If anybody could be so kind > as to try and run that through their Lilypond installation? > > I'd heard about the possibility of writing one's own engravers in > Scheme, which would certainly have been the more elegant way of doing > most of this, but I couldn't find it accessibly documented anywhere and > it didn't seem to be supported on the older versions anyway. > Lukas > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Doc: NR: Reformat ly code.
I only checked the keyboards part that I helped with, but I like the improvements. Thanks! On Fri, May 21, 2010 at 7:04 PM, Mark Polesky wrote: > Warning. This is a monstrously huge patch, with an > potentially overwhelming number of (mostly) tiny changes. > > However, I think it's a worthwhile improvement to the text; > one that makes the NR a lot more readable, and fixes a lot > of sloppy code. > > I'm hoping that some of the usual players will at least be > able to look part of this over, and make some comments. But > don't say I didn't warn you! > > http://codereview.appspot.com/1242044 > > - Mark > > > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Essay status
On Sat, Dec 26, 2009 at 10:22 AM, Graham Percival wrote: > On Sat, Dec 26, 2009 at 06:18:13PM +0100, John Mandereau wrote: >> What's the completion status of the essay? Are at least some chapters >> stabilized enough so that they can be translated, reusing translations >> of former Chapter 1 Introduction of the Learning Manual and the Essay on >> the old website? I can't figure it out myself from Git history. Probably not stable enough to translate, but getting close. (I'm assuming that the translators would not want any changes to the English version once they start, correct me if I'm wrong.) The first two-thirds of the text are nearly stable from my point of view. I have just a few tiny edits to make and it will be ready to ask for complaints from the user list one last time. The last third is basically untouched and covers issues of LilyPond architecture and input format. I have to do some thinking about which of this content is out of date or better presented in the newer sections of the Learning Guide or the website. So this may change substantially. That said, I have only been reading the PDF output as I worked, so the HTML version is still a formatting disaster. (I have tried to include the highest resolution images I could for the PDF version, so the web version needs another complete set of images at screen width. Maybe 865 px wide like the LilyPond snippets?) So I expect that lots of the image files will still change and I can't say if other formatting tweaks will show up in the .itely file. > We believe that the "new" essay material has superceeded the old > essay. We're not certain, though, and I'm not certain how much of > the old stuff I've removed. I deliberately didn't delete the > files, but I forget whether essay.tely still includes them. True. All the files are still there but none of the old material is included in the output anymore. On the engraving topics, I feel that all of the best material has been retained, with the possible exception of the 2.1 benchmarking example, where I can't find a PDF version of the output. On the program architecture topics I can't really say yet. > It's definitely not ready for translators. But I'm pretty certain > that when the time comes, translating from scratch will be the way > to go. Yes. The parts that have been stolen from the earlier versions are mixed in so finely that they would be pretty hard to identify. If I were using my poor foreign language skills to translate, I would read through the old Spanish essay to get warmed up, but I would start with an empty file. Thanks for checking on this. Heckling encouraged! I hope to make some more progress next week. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book is hosed
2009/12/23 John Mandereau : > Hi guys, > > In my way of fixing lilypond-book hashing, I'm afraid I'll have to > revert 4c5a581ca25398669b9ecbc7a606febb09e60214 "lilypond-book: Change > md5 hashing strategy", because ignoring fragment options for the hash > which have an impact on music typesetting is wrong. +1 I noticed this behaviour on the essay work where I adjust staff sizes to allow visual comparisons between current LilyPond output and other images. I suspected it had something to do with the hash strategy, but I wasn't sure until you mentioned this. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Issue 638 Autobeaming
On Wed, Dec 16, 2009 at 1:20 PM, Carl Sorensen wrote: > At last, thanks to help above and beyond the call of duty by Neil, I have > finally got the autobeam engraver fixed so it beams 4 4 right when there are > 16th notes in the 2nd or 4th beat of the measure. Bravo, Carl! I can't really comment on the code (still way over my head), but the resulting image is very exciting. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 'make all' fails
2009/12/4 John Mandereau : > Hi guys, > > Please always check that Lily and docs compile (make all && make doc) > before pushing, or push to a branch different from master. > > /home/lilydev/git/lily/master/Documentation/out//essay/engraving.texi:950: > Prev reference to nonexistent node `Notation benchmarking' (perhaps incorrect > sectioning?). > /home/lilydev/git/lily/master/Documentation/out//essay/engraving.texi:786: > `Getting things right' has no Up field (perhaps incorrect sectioning?). > /home/lilydev/git/lily/master/Documentation/out//essay/engraving.texi:699: > `Improvement by benchmarking' has no Up field (perhaps incorrect sectioning?). > /home/lilydev/git/lily/master/Documentation/out//essay/engraving.texi:564: > Next reference to nonexistent node `Notation benchmarking' (perhaps incorrect > sectioning?). > /home/lilydev/git/lily/master/Documentation/out//essay/engraving.texi:560: > Menu reference to nonexistent node `Notation benchmarking' (perhaps incorrect > sectioning?). > /home/lilydev/git/lily/master/Documentation/out//essay/engraving.texi:786: > warning: unreferenced node `Getting things right'. > /home/lilydev/git/lily/master/Documentation/out//essay/engraving.texi:699: > warning: unreferenced node `Improvement by benchmarking'. > Reading changes.tely... > Dissecting...makeinfo: Removing output file `out/lilypond-essay.info' due to > errors; use --force to preserve. > make[1]: *** [out/lilypond-essay.info] Error 1 > > > Cheers, > John > My bad (in part). Graham had some script that he ran to fix the info structuring as each time I messed with stuff, but I guess that didn't happen this time. You can revert commit 1b63a66da62353e7a0d6075160f4cba095305332 until he or I get to the bottom of that. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: nifty grid view of issues
On Fri, Nov 27, 2009 at 2:29 PM, Graham Percival wrote: > After a bit of experimenting, I think this is the best way to view issues: > > http://code.google.com/p/lilypond/issues/list?mode=grid&y=Priority&x=Type&cells=ids > > Neat, huh? I'll add it to the CG. Yes! That is very cool. Somehow they seem less daunting in that format ... maybe because they take up so little space. > Note that anything in the High or Regression range stops 2.14 from > being released. > > > BTW, my initial guess is that 787 could be fixed with less than 5 > lines of scheme; I think some code is doing a simple comparison rather > than sorting through a list. > > Also, could somebody on OSX check 752 (high defect) ? I suspect this > has been fixed by bumping pango. > > Also, 818 (high defect)? > > Cheers, > - Graham > > > ___ > bug-lilypond mailing list > bug-lilyp...@gnu.org > http://lists.gnu.org/mailman/listinfo/bug-lilypond > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Engraving essay questions and RFC
On Sun, Oct 11, 2009 at 8:58 PM, Joe Neeman wrote:
> On Wed, 2009-10-07 at 22:18 -0600, Andrew Hawryluk wrote:
>> - LilyPond 2.13.5 currently has a vertical spacing problem (no padding
>> between staves).
>
> how about this:
> \layout {
> \context {
> \PianoStaff
> \override StaffGrouper #'between-staff-spacing #'padding = #0.5
> }
> }
>
> If you find a good value, I'll make it the default.
>
> Cheers,
> Joe
I propose #'padding = #1 as the default value for PianoStaff.
Are there other default values in the new spacing engine that need to
be selected, perhaps by referencing good published scores? Overall,
I'm very impressed with the new layout algorithms, and I'd be happy to
pitch in a bit of score measuring if it will help to get the constants
right.
Andrew
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Engraving essay questions and RFC
On Fri, Oct 9, 2009 at 3:18 AM, Trevor Daniels wrote: > Hi Andrew > > Generally looking good. A few comments, mostly minor: > > a) Page 2 has the phrase "Not let down, we created a font of musical > symbols" > "Not to be deterred," or "Undiscouraged," would be better. > > b) Where you compare the shapes of the quarter rests on page 2 it might be > better to draw attention to the three sharp points in the middle, as the one > at the bottom seems to exhibit the point :) being made the least. > > c) Page 3: the last para of the text immediately below the first music > example has the references to the two examples the wrong way round - the > _lower_ measures contain the correction. > > d) Page 5, where you compare Lily 1.4 output, I suggest you make it clear > when 1.4 is first mentioned that this is a very old version. This would not > be immediately obvious to someone coming to LilyPond for the first time. > > Trevor Thanks for the detailed proofreading! The changes will appear in my next patch. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Engraving essay questions and RFC
On Thu, Oct 8, 2009 at 3:59 PM, Jonathan Wilkes wrote: > >> Message: 2 >> Date: Wed, 7 Oct 2009 22:18:12 -0600 >> From: Andrew Hawryluk >> Subject: Engraving essay questions and RFC >> To: lilypond-devel >> Message-ID: >> <11cc7c4f0910072118p562a3e4fj2d167172fcb88...@mail.gmail.com> >> Content-Type: text/plain; charset=windows-1252 >> > > Hi Andrew, > This looks great to me- I like seeing Lilypond compared to several > other editions of the same piece at the end. > I just have one comment about the following: > >> - Finale’s beamed stems are almost always too long when >> they extend >> off the staff. > > Your benchmarking method currently takes the default output and compares it > to classic engravings. But this means you're considering things > like the "Patterson Beams" plugin in Finale a tweak; yet it is an > automated tool that takes two or three mouse-clicks and is a standard part > of the engraving process for any serious Finale user. Yes, I do consider "Patterson Beams" a tweak, but it would be worth stating this explicitly in the text. My reasoning is that the plugin is an additional step I have to remember before I print the score, and if I do any additional note editing, the edited regions revert to Finale's default beams (IIRC). The same thing is certainly true about horizontal note-spacing adjustments, and it drives me nuts (I refer to "beat spacing" with the measure tool). When working in Finale, I have to always follow an optimum order of operations, e.g. "Oh, that alto stem collides with the lyrics, but I don't want to fix it now because I haven't selected the best line breaks yet and I can't choose the best inter-stave spacing until then. I hope I'll still remember this collision is there before I upload it." > Also, I really think it would be helpful to additionally show fully > tweaked versions of both the Finale and Lilypond scores, to give an idea > of the techniques/time necessary to get optimal output in both pieces of > software. I think I can get a copyist to do this on the Finale > side if you're interested. I was going to remark that some fine-tuning can bring either score into conformance with the engraved editions, but actually doing it would be more convincing, no? I have a tiny adjustment to make on the Finale score, but once I've done it I can send you the file. Thanks for your input, Andrew > -Jonathan > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Engraving essay questions and RFC
On Thu, Oct 8, 2009 at 1:25 AM, Jan Nieuwenhuizen wrote: > Op woensdag 07-10-2009 om 22:18 uur [tijdzone -0600], schreef Andrew > Hawryluk: > >> Have I missed anything? >> Please discuss? > > What about the bland look of the henle 666 edition of the solo cello > suites compared with baerenreiter's? > > For me, this grasps the essence of > > * what is wrong with computer notated music > > ie: why the graham's mao did we start this insane job of building > lilypond? [and why should the reader junk the piece of sh*t she's > using now to enrgave her scores?], so it sets the stage for > > * why should I care and learn about/use lilypond > > It is kind of hard to immediately see what's wrong with the henle > edition. Everything looks neat and okay. Possibly even "better", > more computerized and thus possibly unescapably more sterile than > the hand-engraved version. It really puzzled Han-Wen and me for > quite a while why computer music notation is bad. We really wanted > to fix that, but we first had to find why it's bad. > > This intriguing quest[ion] could make someone want to read the rest > of the essay too. It now starts off with a nice history of [plate] > engraving, but why would I want to know or read about that? > > This start was part of the talk that Han-Wen and I gave for a while. > You'll have to note the exact vertical lines (grid-lines, almost) > that the barlines and individual notes are on. That's the most > noticable clue here, which leads to the small note+accidental spacing > differences and the optical note spacing corrections, that give > a score a much more lively/alive look, making it also more readable > and less awkward (esp. the optical spacing). Thanks, those are good points. Do you have copies of the scores in question? For the PDF version I'd love to get some scans at 300 or 600 dpi so they could be reproduced at (nearly) full size. > I'm not sure if you'd want to visually annotate any typography > errors. It was possibly a bit awkwardly done, but visual marks > do make errors immediately clear; much easier than reading text > and then comparing it to a picture? Yes, the annotations speed up the reader's job a lot. I also like seeing the 'unmarked' version to see the effect of those details on the total impression, so I will play around with that. > I also like the lyrics benchmarking bit :-) Do you mean the Schubert (Sängers Morgenlied)? Speaking of the benchmarking examples, do you (or anyone else) have PDF versions of the old LilyPond output? (e.g. version 1.4 or 2.1.5?) I know the odds are low, but if they were easy to find I would use them. Thanks again, Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Engraving essay questions and RFC
Hi everyone, I'm working on the LilyPond essay, and I'm ready to ask
you some questions.
You can read my current draft at http://www.musicbyandrew.ca/essay.pdf
(this is identical to a doc build with my latest patch, except that I
have only updated the pages containing the new essay, leaving out the
original, the GPL stuff, and the index.) The source file in question
is Documentation/essay/engraving.itely
Questions:
1. Multiple staff sizes and optical line weights. I have a piano +
violin excerpt on page 4 (PDF page 6). If I modify the staff-space and
thickness by the same number then I don't get the relatively heavier
lines that I would naturally get using "set-global-staff-size". I am
currently using this:
\new Staff \with {
fontSize = #-4
\override StaffSymbol #'staff-space = #(magstep -4)
\override StaffSymbol #'thickness = #(magstep -3)
}
This gives me staff lines that I like, but they may not match the
carefully tunes weights of "set-global-staff-size". Also, I think I
should be thickening up the barlines and stems as well.
- Any suggestions on the tweaks I should do to match the
"set-global-staff-size" appearance?
(A previous discussion suggested magstep = 3.5 for these cases, but I
am trying to increase the contrast a bit.)
2. Something is wrong with my beaming on page 6 (PDF 8). Any guesses?
The source is
\relative c {
\clef "bass"
\key d \minor
\time 3/4
\mergeDifferentlyDottedOn
<< {\slurDashed d8.-\flageolet( e16) e4.-\trill( d16 e)}
\\ {d4_2 a2}
>>
\slurDashed
4. e8( d c)
\slurSolid
bes g' f e16( f g_1 a_2 bes_3 d,_2)
\slurDashed
cis4.-\trill b8_3( a g)
<< {\slurDashed d'8.( e16) e4.-\trill( d16 e)}
\\ {4 a2}
>>
}
3. As you can see, I have started a comparison of Finale / LilyPond /
real engravings. The scores are on the last 3 pages. (Note that the
Finale example has been clipped just a bit to close on the right hand
side. I will fix this.) My preliminary observations are
- Finale rests are always at the same heights (in v1/v2 situations).
- Finale doesn’t interlock notes nicely (mm. 28–29).
- Finale misses the B-flat in mm. 33!
- Finale’s beamed stems are almost always too long when they extend
off the staff.
- LilyPond 2.13.5 currently has a vertical spacing problem (no padding
between staves).
- LilyPond could use a little more space before the first note of mm. 30, 33–34.
- LilyPond’s ties to beat 1 of mm. 31 are shorter than any of the
reference scores, and Finale’s are even worse.
- LilyPond’s stems are often shorter than any of the references,
especially RH mm. 31.
Have I missed anything?
Please discuss?
Maybe a couple of those items should be bug reports? Although I want
to be fair in this essay, I also don't want to
4. I believe that I have now incorporated the most valuable elements
of the original essay into the nicer structure that Trevor began. Do
you agree or did I miss something? (There are probably still things to
add, but I don't think they will come from the old essay.)
5. Any other thoughts? The essay has been a prominent piece of
LilyPond 'marketing' and I want to know that community is getting the
upgraded essay that they want.
Thanks,
Andrew
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Patch for updated essay work.
Some more work done, mostly on benchmarking.
Andrew
From 6ee065b8eb6ff844b8e093fb6cacd7ac18de4561 Mon Sep 17 00:00:00 2001
From: Andrew Hawryluk
Date: Wed, 7 Oct 2009 21:32:25 -0600
Subject: [PATCH] Doc: work on essay benchmarking text
---
Documentation/essay/engraving.itely | 123 +-
1 files changed, 90 insertions(+), 33 deletions(-)
diff --git a/Documentation/essay/engraving.itely b/Documentation/essay/engraving.itely
index 18cc010..435d823 100644
--- a/Documentation/essay/engraving.itely
+++ b/Documentation/essay/engraving.itely
@@ -34,17 +34,26 @@ LilyPond.
@cindex plate engraving
@cindex music engraving
-The art of music typography is called @emph{(plate) engraving}. The term
-derives from the traditional process of music printing. Just a few
-decades ago, sheet music was made by cutting and stamping the music into
-a zinc or pewter plate in mirror image. The plate would be inked, and
-the depressions caused by the cutting and stamping would hold ink. An
-image was formed by pressing paper to the plate. The stamping and
-cutting was done completely by hand. Making a correction was cumbersome,
-so the engraving had to be nearly perfect in one go. Engraving was a
-highly specialized skill; a craftsman had to complete around five years
-of training before earning the title of master engraver, and another
-five years of experience were necessary to become truly skilled.
+The art of music typography is called @emph{(plate) engraving}, a term
+that derives from the manual process of music print...@footnote{early
+european printers explored several processes, including hand-carved
+wooden blocks, movable type, and engraved sheets of thin metal.
+Typesetting had the advantage of being more easily corrected and
+facilitating the inclusion of text and lyrics, but only engraving
+offered the ability to do unimpeded layout and unanticipated notation.
+In the end, hand-engraved scores became the standard for all printed
+music, with the exception of some hymnals and songbooks where
+typesetting was justified by its ease and economy, even into the
+twentieth century.}. Just a few decades ago, sheet music was made by
+cutting and stamping the music into a zinc or pewter plate in mirror
+image. The plate would be inked, and the depressions caused by the
+cutting and stamping would hold ink. An image was formed by pressing
+paper to the plate. The stamping and cutting was done completely by hand
+and making a correction was cumbersome, so the engraving had to be
+nearly perfect in one go. Engraving was a highly specialized skill; a
+craftsman had to complete around five years of training before earning
+the title of master engraver, and another five years of experience were
+necessary to become truly skilled.
@quotation
@iftex
@@ -55,7 +64,7 @@ five years of experience were necessary to become truly skilled.
@end ifnottex
@end quotation
-Nowadays, all newly printed music is produced with computers. This has
+Now all newly printed music is produced with computers. This has
obvious advantages: prints are cheaper to make, editorial work can be
delivered by email, and the original data can be easily stored.
Unfortunately, computer-generated scores rarely match the quality of
@@ -492,9 +501,9 @@ hand-engraved edition (Bärenreiter BA320), and as engraved by LilyPond
@sourceimage{lily14-sarabande,,,png}
@end ifnottex
-...@noindent
-On careful inspection, there are a number of errors in the LilyPond 1.4
-output:
+...@noindent The LilyPond 1.4 output is certainly readable, but close
+comparison with the hand-engraved score showed a lot of errors in the
+formatting details:
@itemize @bullet
@item most of the stems are too long
@@ -502,16 +511,24 @@ output:
@item the second and fourth measures are too narrow
@item the slur is awkward-looking
@item the stems are too thin
+...@item there was too much space before the time signature
@end itemize
@noindent
(There were also two missing notes, and one wrong one!)
By adjusting the layout rules and font design, the output has improved
-considerably. This is the same piece, engraved by the current version of
-LilyPond (@version{}):
+considerably. This is the same musical quotation compared to the output
+from the current version of LilyPond (@version{}):
-...@lilypond[staffsize=19,line-width=15.9\cm]
+...@iftex
+...@sourceimage{baer-sarabande-hires,16cm,,}
+...@end iftex
+...@ifnottex
+...@sourceimage{baer-sarabande,,,png}
+...@end ifnottex
+
+...@lilypond[staffsize=17.5,line-width=15.9\cm]
\relative c {
\clef "bass"
\key d \minor
@@ -532,31 +549,71 @@ LilyPond (@version{}):
}
@end lilypond
-[AH: I have not written or edited beyond this point. Here I want to do a
-comparison of the last seven measures of Bach's Fugue in G minor from
-the Well-Tempered Clavier, Book I, BWV 861. The appendix has all of the
-source material, but I have some writing to do. This should demonstrate
-LilyPond
Re: doc reorg (especially Usage) possibly finished
On Sun, Sep 27, 2009 at 6:57 AM, Graham Percival wrote: > What do people think about the doc reorg shown in: > http://kainhofer.com/~lilypond/Documentation/general/Manuals.html > (and the actual manual pages, of course) Is it worth mentioning in the essay page that the detailed typographical examples are easier to analyze in the PDF version than the HTML version? -AH ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
What does force-assignment do?
The paper block created by lilypond-book includes the line force-assignment = #"" A git grep shows that "force-assignment" only shows up in two places: scripts/lilypond-book.py - the source of the paper blocks created by lilypond-book Documentation/contributor/doc-work.itexi - and example of the paper blocks created by lilypond-book Does this command do anything? Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: @sourceimage breaking doc build
On Sat, Aug 22, 2009 at 6:24 PM, Andrew Hawryluk wrote: > On Sat, Aug 22, 2009 at 4:53 PM, Graham Percival > wrote: >> >> On Sat, Aug 22, 2009 at 02:34:40PM -0600, Andrew Hawryluk wrote: >> > All of the @sourceimage commands are causing build problems: >> > introduction.itexi >> > download.itexi >> > >> > I've commented them out to continue my work, since I don't know how >> > they >> > are supposed to work! >> >> Why are you trying to build the docs? Or rather... are you sure >> that you're trying to build the docs with the main build system, >> rather than the shell script I gave you? That shell script isn't >> guaranteed to always work. >> >> @sourceimage works fine here with a ./autogen.sh && make && make >> doc. At least, it works fine with my partially-built docs; I >> haven't tested doing a make doc-clean yet. >> >> Cheers, >> - Graham > > I was just running 'make' and 'make doc', so maybe I need another run of > autogen.sh. > I'll give it another go later tonight or tomorrow. > > Thanks, > Andrew > Yes, my 'problem' is solved. I'll get the hang of this yet! Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: @sourceimage breaking doc build
On Sat, Aug 22, 2009 at 4:53 PM, Graham Percival wrote: > On Sat, Aug 22, 2009 at 02:34:40PM -0600, Andrew Hawryluk wrote: > >All of the @sourceimage commands are causing build problems: > > introduction.itexi > > download.itexi > > > >I've commented them out to continue my work, since I don't know how > they > >are supposed to work! > > Why are you trying to build the docs? Or rather... are you sure > that you're trying to build the docs with the main build system, > rather than the shell script I gave you? That shell script isn't > guaranteed to always work. > > @sourceimage works fine here with a ./autogen.sh && make && make > doc. At least, it works fine with my partially-built docs; I > haven't tested doing a make doc-clean yet. > > Cheers, > - Graham > I was just running 'make' and 'make doc', so maybe I need another run of autogen.sh. I'll give it another go later tonight or tomorrow. Thanks, Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
@sourceimage breaking doc build
All of the @sourceimage commands are causing build problems: introduction.itexi download.itexi I've commented them out to continue my work, since I don't know how they are supposed to work! Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web examples now in master. (was: integrating)
On Sat, Aug 15, 2009 at 5:03 PM, Graham
Percival wrote:
> On Sat, Aug 15, 2009 at 04:57:26PM -0600, Andrew Hawryluk wrote:
>> On Sat, Aug 15, 2009 at 4:07 PM, Graham
>> Percival wrote:
>> > Yes. Even though people say "oh, I'd like to help, but I don't
>> > want to use git", and I supply them with a list of 7 or 8 things
>> > they can do without git -- including simply writing a maoing .ly
>> > file, which one assumes that lilypond users would be capable of
>> > doing -- nothing has happened. :/
>>
>> Indeed. Even after you used that atrocity of HTML: blinking text!
>> Here's an improved chart.ly - someone may submit a better one before
>> go-live, but this is definitely better than "we need words!"
>
> Hmm. Please generate it with
> lilypond -dpreview -dresolution=150
>
> What do you think of the spacing? I'm not at all wild about the
> "cannot see" part. Could you remove a bar or so, or maybe reduce
> the font size, to give a wider spacing?
>
> Cheers,
> - Graham
>
Size 18 does the trick nicely. Thanks!
\version "2.12.0"
\include "example-header.ily"
\include "predefined-guitar-fretboards.ly"
#(set-global-staff-size 18)
global = {
\time 4/4
\key g \major
\partial 4
\numericTimeSignature
}
melody = \relative c' {
\global
d4
g4 b8( a) g4 fis
e e e e
a c8( b) a4 g
fis a d
}
harmonies = \chordmode {
\global
s4 g1 | c | a:m | d % 1-3
}
text = \lyricmode {
My eyes are dim, I can -- not see,
I have not brought my specs with me!
}
\score {
<<
\new ChordNames { \harmonies }
\new FretBoards { \harmonies }
\new Staff {
\context Voice = "vocal" { \melody }
}
\new Lyrics \lyricsto "vocal" \text
>>
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web examples now in master. (was: integrating)
On Sat, Aug 15, 2009 at 4:07 PM, Graham
Percival wrote:
> On Sat, Aug 15, 2009 at 04:41:34PM -0500, Jonathan Kulp wrote:
>> On Sat, Aug 15, 2009 at 4:31 PM, Graham Percival
>> wrote:
>> Now the only missing examples are the orchestra one (for which we
>> might want a different image, anyway), plus any replacement pop or
>> tablature ones. All of these can wait. :)
>>
>> I'd welcome a different orchestral image. (didn't I put a big flashing help
>> signal there asking for one? No one has responded to those things...)
>
> Yes. Even though people say "oh, I'd like to help, but I don't
> want to use git", and I supply them with a list of 7 or 8 things
> they can do without git -- including simply writing a maoing .ly
> file, which one assumes that lilypond users would be capable of
> doing -- nothing has happened. :/
Indeed. Even after you used that atrocity of HTML: blinking text!
Here's an improved chart.ly - someone may submit a better one before
go-live, but this is definitely better than "we need words!"
Andrew
\version "2.12.0"
\include "example-header.ily"
\include "predefined-guitar-fretboards.ly"
global = {
\time 4/4
\key g \major
\partial 4
\numericTimeSignature
#(set-global-staff-size 20)
}
melody = \relative c' {
\global
d4
g4 b8( a) g4 fis
e e e e
a c8( b) a4 g
fis a d
}
harmonies = \chordmode {
\global
s4 g1 | c | a:m | d % 1-3
}
text = \lyricmode {
My eyes are dim, I can -- not see,
I have not brought my specs with me!
}
\score {
<<
\new ChordNames { \harmonies }
\new FretBoards { \harmonies }
\new Staff {
\context Voice = "vocal" { \melody }
}
\new Lyrics \lyricsto "vocal" \text
>>
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: patch to fix text color in PDF output
On Thu, Aug 13, 2009 at 10:49 PM, David Kastrup wrote: > Andrew Hawryluk writes: > >> On Thu, Aug 13, 2009 at 7:33 AM, David Kastrup wrote: >>> >>> Sure do. So what driver with what setting converts your PDF to the >>> respective printer language? >> >> Good question. >> At home: Samsung ML-2010, SpliX V. 2.0.0 on Ubuntu 9.04 (evince or >> acroread) > > What printer driver is configured with what settings? Ubuntu has a > printer dialogue. Here's the relevant info from the 'Printer Properties' dialogue. Make and model = Samsung ML-2010 Foomatic/gdi Resolution = 600 DPI Economy mode = Off Media type = Normal Paper Page size = Letter Halftoning Algorithm = Accurate (the other options are 'standard' and 'well-tempered screening' - is that the print setting Bach would have used?) Toner density = 3 (on a scale of 1-5) >> I have also now tried monochrome black with CMYK red, which is >> probably the best output option, but the TeX code could be cleaned up. > > Maybe. But CMYK black really should be black. If it isn't, there is > something wrong, likely in the printer driver which could be > GhostScript. The printer, incidentally, is a B&W or a color printer? B&W. I've only printed TexInfo output on B&W printers to date. and I always get the same results. >> I have attached sample pages of the original and my latest variation >> for comparison. Perhaps someone else can print both pages and see a >> difference. > > Didn't make it to the list. Download location? OK, here's three renderings of the 'short essay' (the LM version, abridged by Trevor): www.musicbyandrew.ca/essayCMYKblack.pdf - original www.musicbyandrew.ca/essayRGBblack.pdf - my original patch, red & black in RGB color space www.musicbyandrew.ca/essayMonoBlack.pdf - my new suggestion, monochrome black with the orignal CMYK red left unchanged On every combination of OS, PDF viewer, and B&W laser printer that I have tried, the original text is rendered just a shade lighter than true black, both on-screen and in print. Can anyone confirm this? On screen you can take a screenshot and measure the color of the text (e.g. in GIMP). In print, the effect is most visible in the body text. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: patch to fix text color in PDF output
On Thu, Aug 13, 2009 at 10:22 PM, Andrew Hawryluk wrote: > On Thu, Aug 13, 2009 at 7:33 AM, David Kastrup wrote: >> Andrew Hawryluk writes: >> >>> On Thu, Aug 13, 2009 at 3:11 AM, David Kastrup wrote: >>>> Andrew Hawryluk writes: >>>> >>>>> Hi all, >>>>> >>>>> Long ago I noticed that the text in our PDF manuals is fully black, >>>>> which results in rough-looking text when printed: >>>>> http://lists.gnu.org/archive/html/lilypond-devel/2008-10/msg00059.html >>>>> >>>>> Attached is a patch which corrects this, and the printed output is >>>>> noticeably improved. (The on-screen output is nearly >>>>> indistinguishable.) >>>>> >>>>> I'll send this to the TexInfo folks as well. >>>>> >>>>> Andrew >>>>> From b2608a3c68f677729d5b72379d18b978b8c6236a Mon Sep 17 00:00:00 2001 >>>>> From: Andrew Hawryluk >>>>> Date: Wed, 12 Aug 2009 21:14:42 -0600 >>>>> Subject: [PATCH] Fix TexInfo PDF output text color >>>>> >>>>> Changed CMKY colors to RGB colors, as RGB black prints >>>>> better than CMYK black on home printers. >>>> >>>> In that case, the "home printer" is broken. It might be conceivable to >>>> use greyscale black as an alternative, but RGB black appears like a bad >>>> choice for printing. >>>> >>>> Could you specify the details of your "home printer"? >>> >>> I have had identical results on two monochrome laser printers, using >>> both Evince and Acrobat Reader. The home printer is a Samsung ML-2010; >>> I don't remember what the work printer is. In either case, they seem >>> to compensate for the fact that cmyk (0 0 0 1) is not the darkest tone >>> available. Do you get different results in print? >> >> Sure do. So what driver with what setting converts your PDF to the >> respective printer language? >> >> -- >> David Kastrup >> > > Good question. > At home: Samsung ML-2010, SpliX V. 2.0.0 on Ubuntu 9.04 (evince or acroread) > At work: not sure, Windows XP and Adobe Acrobat 9.0 (Yes, I have just > confessed to having printed a bit of LilyPond documentation at work.) > > I have also now tried monochrome black with CMYK red, which is > probably the best output option, but the TeX code could be cleaned up. > I have attached sample pages of the original and my latest variation > for comparison. Perhaps someone else can print both pages and see a > difference. > > Thanks, David, for humoring me as I figure this out! > > Andrew > Attachments actually attached this time. essayCMYKblack.pdf Description: Adobe PDF document essayMonoBlack.pdf Description: Adobe PDF document ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: patch to fix text color in PDF output
On Thu, Aug 13, 2009 at 7:33 AM, David Kastrup wrote: > Andrew Hawryluk writes: > >> On Thu, Aug 13, 2009 at 3:11 AM, David Kastrup wrote: >>> Andrew Hawryluk writes: >>> >>>> Hi all, >>>> >>>> Long ago I noticed that the text in our PDF manuals is fully black, >>>> which results in rough-looking text when printed: >>>> http://lists.gnu.org/archive/html/lilypond-devel/2008-10/msg00059.html >>>> >>>> Attached is a patch which corrects this, and the printed output is >>>> noticeably improved. (The on-screen output is nearly >>>> indistinguishable.) >>>> >>>> I'll send this to the TexInfo folks as well. >>>> >>>> Andrew >>>> From b2608a3c68f677729d5b72379d18b978b8c6236a Mon Sep 17 00:00:00 2001 >>>> From: Andrew Hawryluk >>>> Date: Wed, 12 Aug 2009 21:14:42 -0600 >>>> Subject: [PATCH] Fix TexInfo PDF output text color >>>> >>>> Changed CMKY colors to RGB colors, as RGB black prints >>>> better than CMYK black on home printers. >>> >>> In that case, the "home printer" is broken. It might be conceivable to >>> use greyscale black as an alternative, but RGB black appears like a bad >>> choice for printing. >>> >>> Could you specify the details of your "home printer"? >> >> I have had identical results on two monochrome laser printers, using >> both Evince and Acrobat Reader. The home printer is a Samsung ML-2010; >> I don't remember what the work printer is. In either case, they seem >> to compensate for the fact that cmyk (0 0 0 1) is not the darkest tone >> available. Do you get different results in print? > > Sure do. So what driver with what setting converts your PDF to the > respective printer language? > > -- > David Kastrup > Good question. At home: Samsung ML-2010, SpliX V. 2.0.0 on Ubuntu 9.04 (evince or acroread) At work: not sure, Windows XP and Adobe Acrobat 9.0 (Yes, I have just confessed to having printed a bit of LilyPond documentation at work.) I have also now tried monochrome black with CMYK red, which is probably the best output option, but the TeX code could be cleaned up. I have attached sample pages of the original and my latest variation for comparison. Perhaps someone else can print both pages and see a difference. Thanks, David, for humoring me as I figure this out! Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: patch to fix text color in PDF output
On Thu, Aug 13, 2009 at 3:11 AM, David Kastrup wrote: > Andrew Hawryluk writes: > >> Hi all, >> >> Long ago I noticed that the text in our PDF manuals is fully black, >> which results in rough-looking text when printed: >> http://lists.gnu.org/archive/html/lilypond-devel/2008-10/msg00059.html >> >> Attached is a patch which corrects this, and the printed output is >> noticeably improved. (The on-screen output is nearly >> indistinguishable.) >> >> I'll send this to the TexInfo folks as well. >> >> Andrew >> From b2608a3c68f677729d5b72379d18b978b8c6236a Mon Sep 17 00:00:00 2001 >> From: Andrew Hawryluk >> Date: Wed, 12 Aug 2009 21:14:42 -0600 >> Subject: [PATCH] Fix TexInfo PDF output text color >> >> Changed CMKY colors to RGB colors, as RGB black prints >> better than CMYK black on home printers. > > In that case, the "home printer" is broken. It might be conceivable to > use greyscale black as an alternative, but RGB black appears like a bad > choice for printing. > > Could you specify the details of your "home printer"? > > -- > David Kastrup > > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel > I have had identical results on two monochrome laser printers, using both Evince and Acrobat Reader. The home printer is a Samsung ML-2010; I don't remember what the work printer is. In either case, they seem to compensate for the fact that cmyk (0 0 0 1) is not the darkest tone available. Do you get different results in print? Ideally, the main color would be set to a monochrome black in the PDF, which requires either that color-setting syntax in texinfo.tex be written to accept different color spaces, or that the colors hold the expanded PDF literal. The first is beyond my TeX skills, while the second seems like a kludge, but I can try it later tonight to see if it solves the problem. I also forgot "Doc:" in the commit message, so I'll change that. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
patch to fix text color in PDF output
Hi all,
Long ago I noticed that the text in our PDF manuals is fully black,
which results in rough-looking text when printed:
http://lists.gnu.org/archive/html/lilypond-devel/2008-10/msg00059.html
Attached is a patch which corrects this, and the printed output is
noticeably improved. (The on-screen output is nearly
indistinguishable.)
I'll send this to the TexInfo folks as well.
Andrew
From b2608a3c68f677729d5b72379d18b978b8c6236a Mon Sep 17 00:00:00 2001
From: Andrew Hawryluk
Date: Wed, 12 Aug 2009 21:14:42 -0600
Subject: [PATCH] Fix TexInfo PDF output text color
Changed CMKY colors to RGB colors, as RGB black prints
better than CMYK black on home printers.
---
tex/texinfo.tex | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/tex/texinfo.tex b/tex/texinfo.tex
index c7c92b8..8d86b92 100644
--- a/tex/texinfo.tex
+++ b/tex/texinfo.tex
@@ -1332,12 +1332,12 @@ output) for that.)}
\ifpdf
%
% Color manipulation macros based on pdfcolor.tex.
- \def\cmykDarkRed{0.28 1 1 0.35}
- \def\cmykBlack{0 0 0 1}
+ \def\rgbDarkRed{0.50 0.09 0.12}
+ \def\rgbBlack{0 0 0}
%
% k sets the color for filling (usual text, etc.);
% K sets the color for stroking (thin rules, e.g., normal _'s).
- \def\pdfsetcolor#1{\pdfliteral{#1 k #1 K}}
+ \def\pdfsetcolor#1{\pdfliteral{#1 rg #1 RG}}
%
% Set color, and create a mark which defines \thiscolor accordingly,
% so that \makeheadline knows which color to restore.
@@ -1347,7 +1347,7 @@ output) for that.)}
\pdfsetcolor{#1}%
}
%
- \def\maincolor{\cmykBlack}
+ \def\maincolor{\rgbBlack}
\pdfsetcolor{\maincolor}
\edef\thiscolor{\maincolor}
\def\lastcolordefs{}
@@ -1442,8 +1442,8 @@ output) for that.)}
%
% by default, use a color that is dark enough to print on paper as
% nearly black, but still distinguishable for online viewing.
- \def\urlcolor{\cmykDarkRed}
- \def\linkcolor{\cmykDarkRed}
+ \def\urlcolor{\rgbDarkRed}
+ \def\linkcolor{\rgbDarkRed}
\def\endlink{\setcolor{\maincolor}\pdfendlink}
%
% Adding outlines to PDF; macros for calculating structure of outlines
--
1.6.0.4
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: error in bar number snippet?
On Sun, Aug 9, 2009 at 6:09 PM, Patrick McCarty wrote: > On Sun, Aug 09, 2009 at 05:52:41PM -0600, Andrew Hawryluk wrote: >> In the snippet printing-the-bar-number-for-the-first-measure.ly (NR >> 1.2.5), there appears to be an error. >> It recommends >> >> \set Score.barNumberVisibility = #all-bar-numbers-visible >> \bar "" >> >> but the first line gives a warning: type check for >> `barNumberVisibility' failed; value `#' must be of type >> `procedure' > > For me, this snippet compiles fine (latest git). > >> It turns out that I can get a bar number on the first line just from >> the empty bar line, no \set required. > > Hmm... if I remove the \set, no bar number is created, and I get the > following warning: > > warning: cannot find or create `Timing' called `' > > Are you compiling from git? > > > -Patrick > OK, the \set works great (and is required) on 2.13.x. My report applied only to 2.12.x, and the snippet in question does not appear in the 2.12 manual, Sorry for the noise, thanks for your help Patrick. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
error in bar number snippet?
In the snippet printing-the-bar-number-for-the-first-measure.ly (NR 1.2.5), there appears to be an error. It recommends \set Score.barNumberVisibility = #all-bar-numbers-visible \bar "" but the first line gives a warning: type check for `barNumberVisibility' failed; value `#' must be of type `procedure' It turns out that I can get a bar number on the first line just from the empty bar line, no \set required. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the "separate, but integrated" website proposal
On Fri, Aug 7, 2009 at 12:40 PM, Till Paala wrote: > Hello Graham and John > > Graham Percival schrieb: > > On Tue, Aug 04, 2009 at 02:53:51PM +0200, John Mandereau wrote: > > > Le mardi 04 août 2009 à 05:20 -0700, Graham Percival a écrit : > > > Eh? Why on earth would the Examples change for different > languages? IIRC, we currently have French lyrics, Italian musical > terms, German titles, Italian lyrics, an English instrument name, > Italian instrument names, a Hungarian (?) title, Italian titles, > some English lyrics and directions... if there was ever part of > the docs that we could say "yeah, we really don't need any > translations here", it would be the pngs on > Introduction->Examples. > > > I was thinking on annotated SVG examples, which should be created for > the essay BTW -- I believed Till had taken this over a while ago, but I > never got news about this. > > > Do you mean the annotated SVGs in web->Introduction->Text input? > > > > I read this only today, the volume on -devel ist just a bit too strong for > my present pace. > > I had had a look at this svg generation a long time ago and was able to > understand how svgs work as well as change a string inside of a file > manually but I have no idea about the building scripts and so I didn't go > further here. So far the web/switch/howto.html has svgs that ge translated > in all languages. I thought it would be nice to have also other annotated > examples especially in the essay to be translated according to language (e.g > the notation examples that show how the software improved). But as said I > gave up long ago neither have the time for it at the present moment. I can't speak for the future content of http://lilypond.org/~graham/Text-input.html, but I will be working on the next version of the essay (once the directory structure for images in Documentation/ stabilizes), and it should not require any bit-mapped text. Even in cases such as http://lilypond.org/web/images/lily14-sarabande-correct.png, the corrections could be highlighted visually without requiring that descriptions occur in the image. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the "r" in "git pull -r"
On Fri, Aug 7, 2009 at 8:45 PM, Patrick McCarty wrote: > On Fri, Aug 07, 2009 at 07:34:01PM -0700, Mark Polesky wrote: >> >> Regarding CG 1.2.2: >> http://kainhofer.com/~lilypond/Documentation/contributor/Update-command.html >> >> What does "-r" do in "git pull -r"? I don't see "-r" >> listed as an option here: >> http://www.kernel.org/pub/software/scm/git/docs/git-pull.html > > It's undocumented, unfortunately. :-) > > The equivalent long option (that *is* documented) is > > git pull --rebase > > I think it would be nice to have an entire CG section devoted to > explaining what "rebasing" means, but the "git rebase" man page > provides a reasonably good explanation in the meantime. > > http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html I'm currently reading 'Pro Git' by Scott Chacon (http://progit.org/book/) and it's a very nice introduction to using git for version control. It might make a nice link from the CG. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Should Dot_column_engraver be in Voice instead of Staff?
2009/8/5 John Mandereau : > dots.ly before > dots.ly after > > collision-mesh.ly before > collision-mesh.ly after I think even this simple case might fail if the dots were placed in the Voice context: << c''4. \\ b'4. >> In the example that Mark found, the non-aligned notes are certainly superior, but I'm not sure what rule would determine whether the alignment is desired for every case. Would it be as simple as 'keep the dots unaligned unless collisions result' ? I guess this would require significant surgery to the Dot_column_engraver, no? Andrew <>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: new vertical layout engine
On Thu, Jul 30, 2009 at 7:18 PM, Joe Neeman wrote: > After fixing the latest round of bugs (pointed out by Neil Puttock and > Michael Käppler), I've pushed the changes to git's master branch. That > is, you should test master instead of dev/jneeman and bugs now belong on > the bug list instead of in this thread. Just tried the latest version, and it looks awesome! A pleasant, but unexpected side-effect of the new logic is that it accepts more compact systems: the first piece I tried it on went from 11 pages to 8, and only the first system looked too squished. (Attached.) I tried \override StaffGrouper #'between-staff-spacing #'padding = #1 with no effect. Should this pad the skylines or just the staff itself? Andrew <>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: working on the new website
On Mon, Aug 3, 2009 at 6:05 AM, Graham Percival wrote: > On Sun, Aug 02, 2009 at 07:55:14PM +0200, John Mandereau wrote: >> Le samedi 01 août 2009 à 20:22 -0700, Graham Percival a écrit : >> > You're on osx, right? Or linux? I've attached a shell script >> > that just builds the essay. >> >> Please don't write, use and spread such scripts, or make sure I won't >> notice them nor their consequences: they will likely break next time >> makefiles are changed, and there are already so many issues and >> questions with the official build system that we don't want to be >> bothered by halping contributors that use such alternative building >> methods. > > Oops, I meant to warn Andrew that it was fragile. Andrew: if it > stops working at some point, let me know and I'll whip up another > script. Consider me warned! I may use said script to quickly check for dumb errors, but it didn't seem to import the images, and if I run 'make doc' twice the second run only takes 33 seconds, so I'll still build the full set regularly. On that note, the LM version of the essay includes three images that are stored in Documentation/, but the next version will probably have several others. Is there a way to move any included images to Documentation/essay/ so I'm not cluttering things up? Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: working on the new website
On Sat, Aug 1, 2009 at 9:22 PM, Graham Percival wrote: > On Sat, Aug 01, 2009 at 07:32:21PM -0600, Andrew Hawryluk wrote: >> On Sat, Aug 1, 2009 at 4:44 PM, Graham Percival >> wrote: >> > Great! Now that that's working, you can delete the web-gop repo >> > and move back to main repo Documentation/essay/. :P >> > Just a few days ago, we set up this new location for the essay. >> > In the coming days, I'll move the long bibliography into that dir >> > as well. >> >> OK, sounds good. New questions then: >> - do I need to run 'make doc' to build the essay in the new location? > > Mao, I forgot about that. That'd take ages. > > You're on osx, right? Or linux? Ubuntu 9.04 > Save the attached file in Documentation/, then run "sh > make-essay.sh" (or make it executable and do ./make-essay). The script is working. Thanks! I'll read up on inserting images, and read both existing versions one more time before I dive in. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: working on the new website
On Sat, Aug 1, 2009 at 4:44 PM, Graham Percival wrote: > On Sat, Aug 01, 2009 at 12:30:01PM -0600, Andrew Hawryluk wrote: >> On Sat, Aug 1, 2009 at 12:18 PM, Francisco Vila wrote: >> > 2009/8/1 Andrew Hawryluk : > >> First question: I've pulled the web-gop repo. Should 'make' build it? >> > >> > yes, from the texinfo directory. >> > >> Ah, that was my problem! Thanks. > > Great! Now that that's working, you can delete the web-gop repo > and move back to main repo Documentation/essay/. :P > Just a few days ago, we set up this new location for the essay. > In the coming days, I'll move the long bibliography into that dir > as well. > > - Documentation/essay/engraving.itely: this is the old essay from > LM 1.1. The website essay is on the website; if you want the > (html) source, you could keep web-gop around and look in there. > Feel free to snarf any pictures you want from the old website, > too. > - feel free to add more chapters if you want... maybe one chapter > about traditional music engraving, one chapter about computer > music engraving, and one chapter comparing lilypond output to > finale/sibelius output? > Up to you. Adding a new chapter needs to modify > Documentation/essay.tely, but that should be fairly > straightforward. > > Cheers, > - Graham > OK, sounds good. New questions then: - do I need to run 'make doc' to build the essay in the new location? - is the essay going to be rendered in PDF & HTML or just HTML? - where does the rendered output appear? do I need to 'make install' to find them all? Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: working on the new website
On Sat, Aug 1, 2009 at 12:18 PM, Francisco Vila wrote: > 2009/8/1 Andrew Hawryluk : >> On Mon, Jun 15, 2009 at 10:35 PM, Graham >> Percival wrote: >> >>> Andrew, I know that you offered to work on the essay; if you're >>> still willing, then let's talk. The only real question (in my >>> mind) is how much lilypond you want to include, and whether we >>> need to drag in lilypond-book for the website, or if we can do it >>> another way. My hope is to do it another way. >>> If plain texinfo is fine, go ahead and do whatever you want in >>> texinfo/essay.itexi, as long as the result compiles. :) >> >> Sorry for the long absence, and yes, I am still interested in the >> essay. It was very influential in luring me to try lilypond, so count >> me in. >> >> First question: I've pulled the web-gop repo. Should 'make' build it? > > yes, from the texinfo directory. > Ah, that was my problem! Thanks. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: working on the new website
On Mon, Jun 15, 2009 at 10:35 PM, Graham Percival wrote: > Andrew, I know that you offered to work on the essay; if you're > still willing, then let's talk. The only real question (in my > mind) is how much lilypond you want to include, and whether we > need to drag in lilypond-book for the website, or if we can do it > another way. My hope is to do it another way. > If plain texinfo is fine, go ahead and do whatever you want in > texinfo/essay.itexi, as long as the result compiles. :) Sorry for the long absence, and yes, I am still interested in the essay. It was very influential in luring me to try lilypond, so count me in. First question: I've pulled the web-gop repo. Should 'make' build it? For me, make ends with a python KeyError in line 124 of versiondb.py Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: new vertical layout engine
On Fri, Jul 10, 2009 at 9:09 AM, Reinhold Kainhofer wrote: > Am Montag, 22. Juni 2009 15:31:14 schrieb Joe Neeman: >> A quick update on the new vertical spacing: [...] >> Anything I've missed? > > While the new vertical spacing looks great for full scores (one system per > page), I have now run into a case where the old system worked much better. In > particular, the spacing between the systems is too small with the new system, > while in the old system it was easy to see where the systems end and new > systems begin. (On the positive side: The piano staff looks much better with > the new system). > > PDFs: > Old: (enough space between systems) > http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/Franck_PanisAngelicus_Score_Full.old.pdf > > New: (not enough space between systems) > http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/Franck_PanisAngelicus_Score_Full.new.pdf > > Lilypond code: > http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/0054_Franck_Panis_angelicus.zip > > Cheers, > Reinhold I haven't had time to try the new code yet, but can the problem be resolved by a property that sets the spring constant between systems relative to the springs between staves? Sorry if this is already how it works ... I'll probably get to try the new branch when I get our ceiling put back together. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: RFC: new vertical layout engine
On Tue, Jun 16, 2009 at 3:52 AM, Joe Neeman wrote: > On Mon, Jun 15, 2009 at 9:05 PM, Reinhold Kainhofer > wrote: >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Am Montag, 15. Juni 2009 17:25:54 schrieb Joe Neeman: >> > I've started working on a new system for doing vertical layout in one >> > pass >> > (ie. positioning and stretching the systems simultaneously). >> >> Since I have also attempted to improve the vertical stretching of >> orchestral >> (choir + full orchestra) full scores (but failed, since I couldn't get the >> springs-and-rods problem to return any useful solution), I spend a while >> thinking about what should be done: > > Those are some comprehensive comments, thanks! Some remarks/questions > below... >> >> - -) Being able to set stretching factors on a StaffGroup-level. In >> particular, >> for full scores there are staff groups for woodwind, brass, vocal voices, >> strings etc. When the whole system is stretched vertically, there is more >> space in printed scores between the groups than between the staves inside >> the >> individual groups (i.e. the instrumental staff groups use a different >> spring >> constant than the staff group for the whole system). See e.g. a modern >> Bärenreiter edition: >> >> http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/Schubert_StabatMater_0050.pdf >> Current bad lilypond results (with huge stretching) are: >> >> http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/stretching_oly_largestretch.pdf >> >> This is really necessary for full scores for the conductor to get a quick >> overview over the instrument groups. In particular, look at the >> stretching_oly_vocalstaves.pdf file (current results with lilypond!), hide >> the >> group brackets at the left and try to guess which staves belong >> together... >> Sample file (with hardly any stretching): >> >> http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/stretching_oly_vocalstaves.pdf >> >> You would never guess which staves belong together.. > > This will certainly the possible in the layout code, but I don't see how to > make it nicely accessible through properties. Currently, the information > about staff groups doesn't make it as far as the backend. If I can't find a > nice way to do this, the functionality will be available anyway by setting > 'previous-space on the first staff and 'next-space on the last staff of a > staff group. > >> - -) The stretching should not be done by simply inserting the same space >> between all the staves, since then staves with a high skyline (e.g. one >> staff >> has some dynamic signs, while other don't) will be spaced too much >> compared to >> staves with a low skyline. The stretching should rather attempt to space >> the >> center-line of the staves (almost) equally. > > This is already done (assuming it works; I haven't checked carefully). > >> >> - -) For staves with lyrics it might give better results to almost ignore >> the >> lyrics for spacing and then squeeze in the lyrics in the remaining space. >> Otherwise the vocal staves with lyrics will be spaced way too much >> compared to >> e.g. the strings section. For a hand-engraving, see e.g. the 1897 >> Breitkopf >> edition of Schubert's Stabat mater: >> >> http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/Partitur_Breitkopf1897- >> Seite2.pdf >> Compare this to the current LilyPond output: >> >> http://www.fam.tuwien.ac.at/~reinhold/LilyPond/VerticalStretching/stretching_oly_vocalstaves.pdf > > Ok, I was planning anyway to divide VerticalAxisGroups into "spaceable" (eg. > staves) and "non-spaceable" > (eg. dynamics in a piano staff) categories. The "spaceable" lines will > participate in the layout algorithm (ensuring that space is reserved for the > non-spaceable lines) and then the non-spaceable lines will be distributed > somehow in between the spaceable ones. This is how I intend to do centered > dynamics for piano staves; I could do something similar for lyrics (maybe > for figured bass also?). Could there be a property that specifies whether the non-spaceable are to be a) centered bewteen the neighboring lines, b) positioned as close to the upper line as possible, or c) positioned as close to the lower line as possible? This would cover (a) piano-centered dynamics and lyrics between choral staves, (b) lyrics below single staves and figured bass, and (c) chords and lyrics above single staves (rare, but seen in choral works with divisi). >> - -) It should be possible to keep one context (in particular FiguredBass) >> as >> close as possible to another staff (yes, we have that already by disabling >> stretching above). >> >> >> - -) Fixed positioning of staves/contexts should be possible, even if some >> contexts are killed (in particular, when there are several measures where >> a >> vocal voice is quiet, the lyrics context is automatically killed meanwhile >> and >> the explicit positioning is messed up right now. > > I'm not
Re: Doc-build failure: pdfetex exit with bad status
On Wed, Jun 10, 2009 at 5:45 AM, Jonathan Kulp wrote: > On a fresh installation of Linux Mint (and previously of xubuntu, ubuntu, > crunchbang, and ubuntulite) I can't get the docs to build properly. It's > taking several "make doc" commands to get each of the pdf files to be > written, and then when they appear they're missing all the images. Here's > the tail of the terminal output: > > /b > luesky/cm/cmtt12.pfb>> > Output written on lilypond.pdf (453 pages, 1615070 bytes). > Transcript written on lilypond.log. > /usr/bin/texi2dvi: pdfetex exited with bad status, quitting. > make[1]: *** [out-www/lilypond.pdf] Error 1 > make[1]: Leaving directory `/home/jon/lilypond/Documentation/user' > make: *** [doc-stage-1] Error 2 When I was getting the same error a couple of moths ago I dug further into the .log file and found a line somewhere telling me which TeX package I was missing. (I think it was the 'epsf' package in my case.) Granted, you are already getting some output, so that may not be the case for you. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Numbered musical notation (Jianpu)
On Sat, Jun 6, 2009 at 1:59 PM, Silas Brown wrote: > Continuing the thread from November 2007: > (see http://www.mail-archive.com/lilypond-u...@gnu.org/msg32740.html ) > > Here is a Python hack that can add numbered notation (Chinese jianpu) to a > line > of music. The numbered notation is added as ^\markup commands that include > appropriate EPS files. These EPS files are generated using pslatex (you need > the PostScript fonts for LaTeX, although you could substitute Computer Modern > fonts by replacing pslatex with latex but then the jianpu numbers will not > match > Lilypond's other text). The music parser is extremely basic, so don't try it > on > anything too complicated. Octaves must be absolute, and must be in the range > c' > to b'''. However it is OK not to specify length on every note. Numbering > with > 1=C is assumed (although the script can easily be adapted to other > numberings). > > The script works well for me in Lilypond 2.10.33. However it does not work so > well in 2.12.2 because the ^\markup commands are re-positioned so much (which > is > a good attempt to avoid collisions, but it often results in the jianpu numbers > being printed at different heights just because they are a little close to > each > other). Does anybody know how to do it better in 2.12.2? Have you tried \textLengthOn? See Notation Reference 1.8.1 Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mergin web/ with master/
On Fri, Jun 5, 2009 at 12:18 PM, Graham Percival wrote: > Do we need a separate branch (or even repository) for web/ stuff? > I propose that we merge this with the main branch. > > PRO: > + one less branch/repo to track > + easier to fix typos in the web pages > + we can direct everybody to look at the CG (no more README in the > newweb/ branch) > + allows better integration with the other docs (this is more a > post-GOP feature) > > CON: > - adds 30 megs to the main branch (including the .git dir) > - makes translations harder? (maybe? ... I don't know if this is > true, but IMO this is the only real reason to avoid doing this) Another small pro: it would make things simpler for the newcomers. At the risk of opening up a previous discussion, would this allow us to simplify CG 1.1.2 - 1.1.3 to 'git clone' ? My $0.02 are in favour of the merge. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] patch for issue 708
On Sun, May 24, 2009 at 7:14 AM, Carl D. Sorensen wrote: > > > > On 5/24/09 4:49 AM, "Neil Puttock" wrote: > >> 2009/5/24 Carl D. Sorensen : >>> Thanks, Applied. >> >> Unfortunately, there are two serious flaws here: >> >> - keySignature alists which aren't backquoted (e.g., the example in >> the bug tracker) will be ignored >> >> - entries of the form (notename . alteration) are mangled: >> >> \set Staff.keySignature = #'((0 . 2) (1 . 2) (4 . 2)) >> >> -> \set Staff.keySignature = #`(((0 . 2) . ,SEMI-SHARP) >> ((2 . 4) . ,SHARP)) >> >> Less seriously, the two conversion functions appear to be identical >> apart from the different dictionaries for alterations. Would it be >> possible to use a single `fixKS' function with the dictionaries passed >> as an argument to cut down on the duplication? > > > Thanks for catching this, Neil. > > Andrew, I've reverted the patch. Could you rewrite it to fix these issues? Yes, I'll take a look at it. Thanks, Neil for catching those! Won't be this week, but I'll keep you posted. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
patch for issue 708
This patch will allow convert-ly to process this:
\version "2.11.0"
{
c d'4 ees
\set Staff.keySignature = #`(((1 . 4) . 2) ((1 . 3) . 2) ((3 . 3) 2))
f^"some text"
\set Staff.keySignature = #`(((1 . 4) . -2)
((1 . 3) . -4))
}
and output this:
convert-ly (GNU LilyPond) 2.13.1
Processing `test.ly'...
Applying conversion: 2.11.2, 2.11.3, 2.11.5, 2.11.6, 2.11.10, 2.11.11,
2.11.13, 2.11.15, 2.11.23, 2.11.35, 2.11.38, 2.11.46, 2.11.48,
2.11.50, 2.11.51, 2.11.52, 2.11.53, 2.11.55, 2.11.57, 2.11.60,
2.11.61, 2.11.62, 2.11.64, 2.12.0, 2.12.3, 2.13.0,
Not smart enough to convert Staff.keySignature - the alist is no
longer in reversed order.
2.13.1
\version "2.13.1"
{
c d'4 ees
\set Staff.keySignature = #`(((1 . 4) . ,SHARP)
((1 . 3) . ,SHARP)
((3 . 3) . ,SHARP))
f^"some text"
\set Staff.keySignature = #`(((1 . 4) . ,FLAT)
((1 . 3) . ,DOUBLE-FLAT))
}
From d60c53f7d8d6b94acc029f5040c69ee48639df26 Mon Sep 17 00:00:00 2001
From: Andrew Hawryluk
Date: Fri, 22 May 2009 20:57:24 -0600
Subject: [PATCH] Improved keySignature support in convert-ly
Added rules to convert pitch numbers to names, fixed
a bug that prevented the 2.13.0 rule from warning the
user that the keySignature alist order had changed.
---
python/convertrules.py | 64 ++--
1 files changed, 56 insertions(+), 8 deletions(-)
diff --git a/python/convertrules.py b/python/convertrules.py
index c9a8394..fb14f3b 100644
--- a/python/convertrules.py
+++ b/python/convertrules.py
@@ -1420,6 +1420,26 @@ def conv (str):
return '(ly:make-pitch %s %s %s)' % (m.group(1), m.group (2),
alt)
+def fixKS(m):
+words = { '-2': "DOUBLE-FLAT",
+ '-1': "FLAT",
+ '0': "NATURAL",
+ '1': "SHARP",
+ '2': "DOUBLE-SHARP"}
+parts = m.group().split("`")
+if len(parts) != 2:
+return m.group()
+numbers = re.findall(r'-?\d+',parts[1])
+if len(numbers) % 3 != 0:
+return m.group()
+newalterations = []
+for i in range(len(numbers) / 3):
+newalterations.append('(('+numbers[i*3]+' . '+numbers[i*3+1]+') . ,'+
+ words[numbers[i*3+2]]+')')
+whitespace = '\n'+' '*(len(parts[0])+2)
+output = parts[0]+'`('+whitespace.join(newalterations)+')'
+return output
+
str =re.sub ("\\(ly:make-pitch *([0-9-]+) *([0-9-]+) *([0-9-]+) *\\)",
sub_alteration, str)
@@ -1437,19 +1457,19 @@ Please hand-edit, using
as a substitution text.""") % (m.group (1), m.group (2)) )
raise FatalConversionError ()
-if re.search ("ly:(make-pitch|pitch-alteration)", str) \
- or re.search ("keySignature", str):
+if re.search ("ly:(make-pitch|pitch-alteration)", str):
stderr_write ('\n')
stderr_write (NOT_SMART % "pitches")
stderr_write ('\n')
stderr_write (
_ ("""The alteration field of Scheme pitches was multiplied by 2
-to support quarter tone accidentals. You must update the following constructs manually:
-
-* calls of ly:make-pitch and ly:pitch-alteration
-* keySignature settings made with \property
+to support quarter tone accidentals. You must update the following construct
+manually: calls of ly:make-pitch and ly:pitch-alteration
"""))
raise FatalConversionError ()
+
+findKeySig = re.compile(r'\\property\s+\w+\.keySignature .*?\)\s*\)',re.DOTALL)
+str = findKeySig.sub(fixKS,str)
return str
@@ -2616,6 +2636,34 @@ def conv (str):
## FIXME: standard vs default, alteration-FOO vs FOO-alteration
str = str.replace ('alteration-default-glyph-name-alist',
'standard-alteration-glyph-name-alist')
+
+def fixKS(m):
+words = { '-4': "DOUBLE-FLAT",
+ '-3': "THREE-Q-FLAT",
+ '-2': "FLAT",
+ '-1': "SEMI-FLAT",
+ '0': "NATURAL",
+ '1': "SEMI-SHARP",
+ '2': "SHARP",
+ '3': "THREE-Q-SHARP",
+ '4': "DOUBLE-SHARP"}
+parts = m.group().split("`")
+if len(parts) != 2:
+return m.group()
+numbers = re.findall(r'-?\d+',parts[1])
+if len(numbers) % 3 != 0:
Re: [frogs] Re: convert-ly keySignautre issue nearly solved
On Wed, May 13, 2009 at 7:40 AM, Mats Bengtsson wrote: > Quoting "Carl D. Sorensen" : > >> >> >> >> On 5/12/09 11:14 PM, "Andrew Hawryluk" wrote: >> >>> I think I have figured out issue 708: >>> http://code.google.com/p/lilypond/issues/detail?id=708 >>> Before I submit a patch, how do I decide which LP version this goes >>> under for convert-ly? >> >> You will want to see where the keySignature syntax changed. > > No it's not that simple. The solution proposed in the bug tracker is really > only relevant for scores older than version 2.0 (I haven't checked exactly > which 1.9 version the change happened), when the internal representation for > accidentals changed to be able to handle quarter tones. In version 1.8 and > earlier, the alteration +1 meant sharp and -1 meant flat, whereas from > version 2.0 to version 2.10, +1 meant semi-sharp, +2 meant sharp, -2 meant > flat and so on. ... > However, in version 2.11.6, the next change happened to the internal > representation of alterations. From then, a sharp is represented by +1/2, a > flat by -1/2 and so on. For all the people who had already used the macros > SHARP, FLAT, DOUBLE-FLAT and so on, this didn't cause any problems, but for > those who had kept the numeric representation, you all of a sudden end up > with a "missing glyph" error if you for example specify +2 or -2. Excellent. Thanks for the helpful background! I can piece together the rest of the info I need from convertrules.py. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
convert-ly keySignautre issue nearly solved
I think I have figured out issue 708: http://code.google.com/p/lilypond/issues/detail?id=708 Before I submit a patch, how do I decide which LP version this goes under for convert-ly? Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: recent beaming change?
Thanks Trevor and Patrick for the explanation! It sounds like the new
system will make a lot more sense, and if it beaming 4 eighth notes /
quavers together is the only exceptional case not covered by the new
system, then that exception is probably best added after they have got
their final version working. In the mean time, I will just finalize
this short project with LP 2.12.
Cheers,
Andrew
On Sun, Apr 26, 2009 at 8:31 AM, Trevor Daniels wrote:
>
> Patrick McCarty wrote Re: recent beaming change?
>
>
>>> On Sat, Apr 25, 2009 at 8:31 AM, Andrew Hawryluk
>>> wrote:
>>>>
>>>> My latest LilyPond build (2.13.1, 24 Apr 2009) produces different
>>>> beaming than my last build.
>>>>
>>>> e.g. {c''8 c'' c'' c''}
>>>> used to produce |_|_|_|
>>>> and now it gives me |_| |_|
>>>>
>>>> Was this intentional?
>>>
>>> Yes, this was changed recently. The reasons are listed here:
>>>
>>> http://lists.gnu.org/archive/html/bug-lilypond/2009-03/msg00126.html
>>>
>>> I don't know if the plans to revise the auto-beaming code (being
>>> discussed by Carl, Trevor, and Neil) will address this issue.
>>> Clearly, it would be better to allow for this "special case", since
>>>
>>> |_|_|_|
>>>
>>> is much more common than
>>>
>>> |_| |_|
>>
>> Oops. I should elaborate a little more about this.
>>
>> The first beaming pattern used to be the default in certain cases
>> (e.g. 4/4 time on beats 1 and 3), and this beaming pattern can still
>> be used by modifying beatLength, as Trevor described.
>>
>> But it is reasonable to expect users to use "\set beatLength =
>> #(ly:make-moment 1 2)" if they want the first beaming pattern, which
>> is more common?
>
> I can only repeat what I said in the thread referenced above, namely
> that the new default permits the correct beaming of
>
> \relative c'' {
> a16 a a8 a a
> a8 a16 a a8 a
> a8 a a16 a a8
> a8 a a a16 a % beaming is different
> }
>
> Also, it seems easier to set beatLength to go from 2 to 4 beamed
> quavers than to revert auto-beaming rules if you wanted 2 rather
> than 4 beamed quavers. Lily can't do both by default, and I think
> the new behaviour makes the better compromise. I tried to reduce
> the number of auto-beaming rules to minimise the need to revert
> them. But I'm quite happy to change the beaming rules back if a
> majority of users prefer the old default.
>
> That said, Carl is still hoping to unify the behaviour which would
> make overrides to the beaming behaviour far more rational.
>
> Trevor
>
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
recent beaming change?
My latest LilyPond build (2.13.1, 24 Apr 2009) produces different
beaming than my last build.
e.g. {c''8 c'' c'' c''}
used to produce |_|_|_|
and now it gives me|_| |_|
Was this intentional?
Andrew
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: should 'make web' take several attempts?
Good news, I got the docs built! (I was missing a TeX package.) AH On Mon, Apr 13, 2009 at 10:52 AM, Graham Percival wrote: > On Sat, Apr 11, 2009 at 05:29:09PM -0600, Carl D. Sorensen wrote: >> >> On 4/11/09 5:21 PM, "Andrew Hawryluk" wrote: >> >> > I am trying to build the docs, and I get "pdfetex exited with bad >> > status, quitting" errors. However, each time I reattempt it, it seems >> > to get further along before quitting. Does a full doc build from >> > scratch require numerous build attempts, in a similar way that LaTeX >> > must be run twice to get its cross-references correct? >> >> No, once should do it. > > To add to this: if you've modified the docs and they now require > multiple runs, then you broke something. > > If this is your first time building the docs, then you're probably > missing some requiement... hmm, maybe the utf-8 fonts? I always > need to fumble around to find the right packages to install in > Linux; I end up looking at the package suggestions in > input/regression/utf-8.ly > > Every time, I make a mental note to update the INSTALL file to > match whatever was in utf-8.ly, but I always forget before I > actually do it. > > Cheers, > - Graham > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
should 'make web' take several attempts?
I am trying to build the docs, and I get "pdfetex exited with bad status, quitting" errors. However, each time I reattempt it, it seems to get further along before quitting. Does a full doc build from scratch require numerous build attempts, in a similar way that LaTeX must be run twice to get its cross-references correct? Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: patch for bug 729
On Fri, Feb 27, 2009 at 1:17 PM, Carl D. Sorensen wrote:
>
>
>
> On 2/27/09 9:52 AM, "Mats Bengtsson" wrote:
>
>> Not to mention the following example:
>> input/lsr/demo-midiinstruments.ly
>> Hmm, there's some special procedure to update the LSR related stuff, so
>> check out how to
>> get this file updated the proper way.
>
> Don't modify the snippets. That's handled by running convert-ly on the
> those files. That's why we try to keep as much syntax as possible in the
> snippets; they're automatically fixed.
>
>
> You only need to modify text in the body of the documentation, including any
> examples that are inline in the docs.
>
> Carl
>
>
Here's the new version with the documentation change.
Andrew
From 404d16892a75df797f0f5c4f893ccbf3fd5b08ec Mon Sep 17 00:00:00 2001
From: Andrew Hawryluk
Date: Fri, 27 Feb 2009 15:29:39 -0700
Subject: [PATCH] MIDI 47: orchestral strings -> orchestral harp
---
Documentation/user/notation-appendices.itely |2 +-
python/convertrules.py |4 +++-
scm/midi.scm |2 +-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/Documentation/user/notation-appendices.itely b/Documentation/user/notation-appendices.itely
index a2b0550..94ece24 100644
--- a/Documentation/user/notation-appendices.itely
+++ b/Documentation/user/notation-appendices.itely
@@ -421,7 +421,7 @@ The following is a list of names that can be used for the
acoustic grandcontrabass lead 7 (fifths)
bright acoustic tremolo strings lead 8 (bass+lead)
electric grandpizzicato stringspad 1 (new age)
-honky-tonkorchestral strings pad 2 (warm)
+honky-tonkorchestral harp pad 2 (warm)
electric piano 1 timpani pad 3 (polysynth)
electric piano 2 string ensemble 1pad 4 (choir)
harpsichord string ensemble 2pad 5 (bowed)
diff --git a/python/convertrules.py b/python/convertrules.py
index 574e64b..010bf3d 100644
--- a/python/convertrules.py
+++ b/python/convertrules.py
@@ -2874,12 +2874,14 @@ def conv(str):
raise FatalConversionError ()
return str
-...@rule ((2, 13, 0), _ ("keySignature property not reversed any more"))
+...@rule ((2, 13, 0), _ ("keySignature property not reversed any more\n\
+MIDI 47: orchestral strings -> orchestral harp"))
def conv(str):
if re.search(r'\set Staff.keySignature', str):
stderr_write ("\n")
stderr_write (NOT_SMART % _("The alist for Staff.keySignature is no \
longer in reversed order.\n"))
+str = str.replace('#"orchestral strings"', '#"orchestral harp"')
return str
# Guidelines to write rules (please keep this at the end of this file)
diff --git a/scm/midi.scm b/scm/midi.scm
index cb0c0e6..5e956d1 100644
--- a/scm/midi.scm
+++ b/scm/midi.scm
@@ -122,7 +122,7 @@
("contrabass" . ,(- 44 1))
("tremolo strings" . ,(- 45 1))
("pizzicato strings" . ,(- 46 1))
- ("orchestral strings" . ,(- 47 1))
+ ("orchestral harp" . ,(- 47 1))
("timpani" . ,(- 48 1))
; (49-56 ensemble)
--
1.5.6.3
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
patch for bug 729
Attached is my fix for bug #729 and a convert-ly rule.
http://code.google.com/p/lilypond/issues/detail?id=729
If I can keep finding bugs that simple, I'll be sending patches weekly!
Andrew
From 2311c16f64a21247017cd0dafca5a177f676e506 Mon Sep 17 00:00:00 2001
From: Andrew Hawryluk
Date: Fri, 27 Feb 2009 09:15:19 -0700
Subject: [PATCH] MIDI 47: orchestral strings -> orchestral harp
---
python/convertrules.py |5 -
scm/midi.scm |2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/python/convertrules.py b/python/convertrules.py
index 574e64b..d27be1f 100644
--- a/python/convertrules.py
+++ b/python/convertrules.py
@@ -2874,14 +2874,17 @@ def conv(str):
raise FatalConversionError ()
return str
-...@rule ((2, 13, 0), _ ("keySignature property not reversed any more"))
+...@rule ((2, 13, 0), _ ("keySignature property not reversed any more,\n\
+MIDI instrument #47 orchestral strings -> orchestral harp"))
def conv(str):
if re.search(r'\set Staff.keySignature', str):
stderr_write ("\n")
stderr_write (NOT_SMART % _("The alist for Staff.keySignature is no \
longer in reversed order.\n"))
+str = str.replace('#"orchestral strings"', '#"orchestral harp"')
return str
+
# Guidelines to write rules (please keep this at the end of this file)
#
# - keep at most one rule per version; if several conversions should be done,
diff --git a/scm/midi.scm b/scm/midi.scm
index cb0c0e6..5e956d1 100644
--- a/scm/midi.scm
+++ b/scm/midi.scm
@@ -122,7 +122,7 @@
("contrabass" . ,(- 44 1))
("tremolo strings" . ,(- 45 1))
("pizzicato strings" . ,(- 46 1))
- ("orchestral strings" . ,(- 47 1))
+ ("orchestral harp" . ,(- 47 1))
("timpani" . ,(- 48 1))
; (49-56 ensemble)
--
1.5.6.3
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
which version to use for a convert-ly rule?
I've pulled from origin and fixed a bug (don't get too excited - it may have been the tiniest bug ever): http://code.google.com/p/lilypond/issues/detail?id=729 I see that the most recent rule is 2.13.0, so my rule should be 2.13.x where x >= 0. Do I use the current development version or current + 1 and how do I check which version we're up to? Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
CM 1.1 git question
Graham et al, In the instructions for getting the source code, why not just use git-clone? Is there a difference? The currently suggested method of remote-add + checkout produces a bunch of warnings (below). Andrew and...@obi-wan:~$ mkdir lilypond-web and...@obi-wan:~$ cd lilypond-web and...@obi-wan:~/lilypond-web$ git init-db Initialized empty Git repository in /home/andrew/lilypond-web/.git/ and...@obi-wan:~/lilypond-web$ git remote add -f -t web -m web origin git://git.sv.gnu.org/lilypond.git/ Updating origin warning: no common commits remote: Counting objects: 12367, done. remote: Compressing objects: 100% (3257/3257), done. remote: Total 12367 (delta 9143), reused 12249 (delta 9065) Receiving objects: 100% (12367/12367), 11.39 MiB | 313 KiB/s, done. Resolving deltas: 100% (9143/9143), done. >From git://git.sv.gnu.org/lilypond * [new branch] web-> origin/web and...@obi-wan:~/lilypond-web$ git checkout -b web origin/web warning: You appear to be on a branch yet to be born. warning: Forcing checkout of origin/web. Branch web set up to track remote branch refs/remotes/origin/web. Switched to a new branch "web" ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Frog git question
Carl, when you are working on something, do you commit your changes to your local repository every day? Would my final patch become a single commit even if I made the changes in several small commits locally? (I'm trying to avoid commit clutter on the Savannah repo.) How often do you re-sync with Savannah? Also, I think I have 7 out of 8 doc strings done, but the acciaccatura doesn't use define-music-function, so I will try to grep those definitions and find out where the doc string should go. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: doc work
I had NR 2.2 and 2.6. NR 2.2 is done and 2.6 has one TBC about fingerings, which I still intend to address. Andrew On Sat, Jan 3, 2009 at 4:35 PM, Graham Percival wrote: > If we get anybody volunteering to do doc work as part of GOP, I'll > need to know what's happening. What are people currently working > on? > > Trevor: LM Master, polishing it to perfection. > Carl: NR 6. > > Is anybody else working on anything? > > > (I'm going to re-advertize GOP in 2 or 3 weeks, once I've settled > in and we have the CG in git and online) > > Cheers, > - Graham > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP website; please add tasks
I can't think of anything you've missed, but if we get another pair of hands running the LSR, would it be useful/reasonable to have a weekly or monthly email to -user listing the new snippets? OR Could LSR have a "browse by date added" feature added? Andrew On Fri, Dec 26, 2008 at 5:40 PM, Graham Percival wrote: > I have the initial GOP website up now: > http://percival-music.ca/gop/ > > If I've missed any ongoing or temporary jobs that we'd like > filled, please let me know. I'm planning on sending the first > round of pleas out to -user in a few days. > > > I'm not including jobs that are single-person and clearly defined; > for example, there's no point asking for a volunteer to take over > the completion of the translation infrastructure, since it would > probably take longer for John to explain what to do than it would > to do it himself. > > Cheers, > - Graham > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch for the stylesheets
Maybe you would like a dark green based on the main green in your colour scheme (#7b925a). You could try #3a452b or somewhere thereabouts. It's almost hard to believe how much the HTML docs have improved in the past few months! Andrew On Sat, Oct 25, 2008 at 4:58 PM, Patrick McCarty <[EMAIL PROTECTED]> wrote: > On Sat, Oct 25, 2008 at 3:51 PM, Reinhold Kainhofer > <[EMAIL PROTECTED]> wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Am Samstag, 25. Oktober 2008 schrieb Patrick McCarty: >>> This patch includes some color changes, so that documentation passes >>> the WCAG for color contrast. I have tried listening to everyone's >>> suggestions, and I hope this color scheme is a suitable compromise. >> >> To be honest, I don't like the green links in the sidebar, mainly because on >> my laptop's screen the background is quit light and the green text somehow >> appears "glowing" to me, drawing more attention than the main pane, which >> clearly defeats the purpose of a navigation bar :( > > Hmm. I originally tried using blue for all links, but the blue in the > TOC was way too bright for my taste. Do you think I should try a > darker green for these links? Or a darker blue? > > -Patrick > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Docs - unfretted strings
On Mon, Sep 29, 2008 at 1:28 AM, Trevor Daniels <[EMAIL PROTECTED]> wrote: > > Andrew Hawryluk wrote Monday, September 29, 2008 1:44 AM >> >> I thought of this while writing the keyboards part but didn't say >> anything because I didn't want to upset the established dichotomy of >> fretted vs. unfretted strings. Since it is now upset, we should >> consider simply moving all the harp material to keyboards. As far as >> the typesetting is concerned, harp music is piano music with unique >> tuning issues and a higher number of glissandi. Conversely, Hindemith >> called the piano "a harp with hammers". >> >> This would leave us with the guitar/banjo/frets section and the >> orchestral strings section. > > I came to the same conclusion. It is also far easier > to do this - no new files are needed, as the common > notation for keyboards is pretty well right for the > harp, and Harp slots in after Piano and Accordion. > > Perhaps we should change the heading slightly from > "Keyboard instruments" to "Keyboards and other many-stringed instruments". > It's a bit long, but > I'll go with this unless there are better suggestions. > > Andrew - I'll make the heading changes right away. > Do you want to flesh out the Harp section? Valentin > has done most of the pedal bits towards the bottom of App B.8.5, so not a > lot is required. >> >> Andrew > > Trevor > I can do that as soon as I am done my review of NR 1.5 and 1.6 (80% finished). How about "Keyboards and other multi-staff instruments" or "Keyboards and related instruments"? The existing keyboard material also applies directly to celestas and vibraphones, to name a few. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Docs - unfretted strings
On Sun, Sep 28, 2008 at 9:52 AM, Valentin Villenave <[EMAIL PROTECTED]> wrote: > By the way, guitar/harp/piano/percussions are a same group in > orchestras, whereas strings are another group. Besides, harp notation > is (on a semantic/symbolic level) much closer to keyboards or guitar > stuff than to violins, and strictly speaking the harp is as much > (less) of an unfretted string instrument as the piano. I thought of this while writing the keyboards part but didn't say anything because I didn't want to upset the established dichotomy of fretted vs. unfretted strings. Since it is now upset, we should consider simply moving all the harp material to keyboards. As far as the typesetting is concerned, harp music is piano music with unique tuning issues and a higher number of glissandi. Conversely, Hindemith called the piano "a harp with hammers". This would leave us with the guitar/banjo/frets section and the orchestral strings section. Any thoughts or objections? Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: WANTED: Design for documentation (Photoshop power users!)
On Fri, Sep 12, 2008 at 4:43 PM, John Mandereau <[EMAIL PROTECTED]> wrote: >>> - the colors are taken from the Monet "Waterlilies" on the LilyPond homepage > > I find it a good idea, even if we might decide to change this image: > it's a small heavily compressed JPEG image, this is not appealing > enough, LilyPond deserves better graphics on its start page. Feel free > to propose a replacement for it, e.g. a graphical mixture of Monet > Waterlilies and some LilyPond output... I just learned that there are a lot of Monet Waterlilies to choose from, so maybe this will be helpful to anyone on the list with graphics skills: http://commons.wikimedia.org/wiki/Claude_Monet Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \sustainOff confused by staff-switching
I guess this happens because the Piano_pedal_engraver lives in the
Staff context. The way to engrave your example would be
\version "2.11.57-1"
\new PianoStaff <<
\new Staff = RH { s4 }
\new Staff = LH <<
{\clef bass c8 \change Staff = RH c'' r4 r2}
\new voice {s8\sustainOn s8\sustainOff}
>>
>>
Should I add a comment to the keyboards section? It's not a bug, but
it could trip someone up.
Andrew
On Sat, Sep 13, 2008 at 12:44 AM, Mark Polesky <[EMAIL PROTECTED]> wrote:
> Hey all,
>
> Running this file...
>
>
> \version "2.11.57-1"
> \new PianoStaff <<
> \new Staff = RH { s4 }
> \new Staff = LH {
>\clef bass c8\sustainOn \change Staff = RH c''\sustainOff r4 r2
> }
>>>
>
>
> ...generates this warning...
>
> 5:56: warning: cannot find start of piano pedal: `Sustain'
> \clef bass c8\sustainOn \change Staff = RH c''
> \sustainOff r4 r2
>
> ...and the pedal asterisk I was expecting does not get drawn.
>
> If for some reason this isn't a bug, I guess it should be noted
> in the "Known issues and warnings" section (NR 2.2.2 "Piano Pedals").
>
> Happy to help,
> Mark
>
>
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-devel
>
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: WANTED: Design for documentation (Photoshop power users!)
> Andrew, feel free to suggest a new color for the footer :-) > > Cheers, > John You could change the footer from #e8ffe8 to #e7efe3 and the border from #c0ffc0 to #ccd3cc. It looks like the padding/spacing in the footer could be improved but for now I'm more curious to see Patrick's design (and others). Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Status of manuals
Sounds good. I'll read through NR 1.5 and 1.6 next week. Andrew On Fri, Sep 12, 2008 at 2:34 PM, Patrick McCarty <[EMAIL PROTECTED]> wrote: > On Fri, Sep 12, 2008 at 02:02:21PM -0600, Andrew Hawryluk wrote: >> I'd be up for some reviewing. I'm still new enough at LilyPond that >> I'd learn a lot from some 'assigned readings' and I could probably >> tell if they make sense to someone that doesn't compile their own >> LilyPond binaries over breakfast. > > This literally made me laugh, since I think this description applies > to me. :-) Thanks, Andrew. > > If you would like to review NR 1.6, that would be great. I am done > with the main docs in this section now (in git), but not the snippets > sections, so just ignore those for now. Once Reinhold rebuilds the > docs on his site, my latest changes will show up. > > Thanks, > Patrick > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Status of manuals
I'd be up for some reviewing. I'm still new enough at LilyPond that I'd learn a lot from some 'assigned readings' and I could probably tell if they make sense to someone that doesn't compile their own LilyPond binaries over breakfast. Andrew On Fri, Sep 12, 2008 at 1:43 PM, Trevor Daniels <[EMAIL PROTECTED]> wrote: > > Andrew Hawryluk Friday, September 12, 2008 8:27 PM > > >>> Are you up for more doc work? >>> >>> Trevor >> >> Yes, I'm up for more. I'm a slow doc writer, but I'm willing. :) > > Great! What sort of work would you like? There are > a few sections that still need fairly major revision > and editing; there are some that need "formating" (adding refs, applying > what Graham called "policy", > etc); and some are ready for reviewing (making sure > everything is correct, complete, clear by someone > other than the author). >> >> Also, I did go through the "Winds" section during GDP and got it all >> cleaned up except the fingerings section, so you can change the "not >> yet started" label. I expect to have something to add under >> 'fingerings' in the near future. > > OK. I've marked it as being edited by you, and > placed your name on the active contributors' list :) > >> Andrew >> > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Status of manuals
> Are you up for more doc work? > > Trevor Yes, I'm up for more. I'm a slow doc writer, but I'm willing. :) Also, I did go through the "Winds" section during GDP and got it all cleaned up except the fingerings section, so you can change the "not yet started" label. I expect to have something to add under 'fingerings' in the near future. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Status of manuals
Keyboards is done, as far as I can see. Andrew On Wed, Sep 10, 2008 at 3:09 PM, Patrick McCarty <[EMAIL PROTECTED]> wrote: > On Wed, Sep 10, 2008 at 01:43:53PM -0700, Patrick McCarty wrote: >> >> It is about 80% completed and ready for the first >> draft. > > Just to clarify, I should have said: > > It is about 80% completed. Then it will be ready for the first draft. > > Thanks, > Patrick > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: WANTED: Design for documentation (Photoshop power users!)
Here's my initial design submission for the docs - it's just a gentle
modification of the CSS file:
- use "Century Schoolbook L" if available to match the LilyPond output
(Georgia is also a good option)
- links are only underlined when hovered upon
- the colors are taken from the Monet "Waterlilies" on the LilyPond homepage
I didn't change the color of the box at the bottom ("This page is for
LilyPond-2.11.58") because it was styled right in the HTML file.
Hope you get lots of good ideas from the list!
Andrew
On Mon, Aug 11, 2008 at 1:55 PM, Reinhold Kainhofer
<[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Dear all,
> I suppose my last mail sounded too technical (thanks Valentin for pointing
> this out), so here I'm again with some clarifications:
>
> For the new Lilypond documentation we are looking for a good screen design
> (i.e. a mockup image of how the page should look like. You don't need to
> implement it!).
>
> The current, unpolished docs are e.g. at:
> http://kainhofer.com/~lilypond/texi2html-out/Documentation/user/lilypond/index.html
>
> It works fine (should also work with IE now), but doesn't look very good yet.
>
>
> All we need from you is a mockup image of how the pages should look like. I
> will do the actual implementation in HTML / CSS etc., so you don't need to
> know anything technical, all you need to do is to create a good design (in
> whatever format you like best: You can send images, html pages, etc.).
>
>
> Since after the release, we'll probably also tackle the general lilypond
> homepage, it would be a plus if the design could also be re-used (with some
> adaptions, of course) for the lilypond.org homepage.
>
>
> Cheers,
> Reinhold
>
> PS: The complete documentation index to all different parts of our
> documentation is at http://kainhofer.com/~lilypond/texi2html-out/
> Please notice that this page does not use the documentation style, but
> rather the homepage style and thus won't be affected by any design changes
> to the docs yet.
>
>
> - --
> - --
> Reinhold Kainhofer, Vienna University of Technology, Austria
> email: [EMAIL PROTECTED], http://reinhold.kainhofer.com/
> * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
> * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
> * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIoJkiTqjEwhXvPN0RAkEMAKCGNpsDkJJfxSVUWlzofnnJUITUGgCfVEeh
> yqdmvJ3zrjBZli9qIKriEoo=
> =HyaP
> -END PGP SIGNATURE-
>
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-devel
>
/***/
/* PAGE-WIDE SETTINGS */
/**/
html {
height:100%;
}
body {
margin: 0;
padding: 0;
height: 100%;
font-size: 100%;
font-family: "Century Schoolbook L", Georgia, serif;
margin-right: auto;
margin-left: auto;
}
/***/
/* HEADERS*/
/***/
h4 {
color: #151959;
}
h3 {
color: #151959;
}
h2 {
font-size: x-large;
color: #151959;
}
.unnumberedsubsubsec, .subsubheading {
font-size: large;
color: #151959;
}
/***/
/* LINKS */
/***/
a:link, a:visited, a:hover, a:active {color:#2E5479; text-decoration: none;}
a:hover {text-decoration: underline;}
a:active {color:#CCF;}
/***/
/* BLOCK FORMATTING */
/***/
blockquote {
border: 1px solid #cc;
padding: 3px;
width: 40em;
}
.verbatim, .example {
font-family: "Courier New",Courier,monospace;
}
hr {
border: none;
height: 1px;
color: #66;
background-color: #66;
}
table.cartouche {
border: 2px dotted #cc;
margin-left: auto;
margin-right: auto;
width: 85%;
}
table.cartouche td {
border: none;
}
/***/
/*MAIN CONTENT */
/***/
div#main {
position: absolute;
top: 0;
right: 0;
bottom: 0;
left: 27%;
padding: 0 1em;
margin: 0;
overflow: auto;
}
#languages {
padding-bottom: 1em;
}
/***/
/*TOC SIDEBAR */
/**
Re: finished second draft?
I'm done with Keyboards. Cheers, Andrew On Wed, Aug 6, 2008 at 8:48 AM, Carl D. Sorensen <[EMAIL PROTECTED]> wrote: > Please hold on Fretted String Instruments. > > I'm currently almost done with Predefined Fret Diagrams, which will add a > section to Fretted String Instruments (and will lead to reorganization). > The new organization on Fret Diagrams will be: > Fret Diagram Markups > Predefined Fret Diagrams > Automatic Fret Diagrams. > > Thanks, > > Carl > > > On 8/6/08 1:17 AM, "Graham Percival" <[EMAIL PROTECTED]> wrote: > >> Currently officially on Second draft: >> 1.3 Expressive marks >> >> 1.5 Simultaneous notes >> >> 2.2 Keyboard instruments >> >> 2.4 Fretted string instruments >> >> >> If any of these are finished, let me know and I'll move them into >> the ``finished'' category, and Ralph will start indexing them. >> >> Cheers, >> - Graham > > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GDP: only 3 weeks left
On 7/27/08, Graham Percival <[EMAIL PROTECTED]> wrote: > Hi, GDP contributors! > > Andrew: I know I asked you this a few days ago, but I've forgotten > already -- are we ready for the second draft? And do you have any > experience/interest in Winds? I don't have anybody down for that > section yet. > I think we're ready for the second draft of keyboards. I have some experience writing for and playing winds, so I can clean it up and add some references (unless someone else has already started on it). Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: keyboard-headword.ly
I like the Ravel. Sergei will have to wait another 5.5 years before appearing in the LP docs. Andrew On Tue, Jul 1, 2008 at 4:50 PM, Graham Percival <[EMAIL PROTECTED]> wrote: > On Tue, 1 Jul 2008 23:34:17 +0100 > "Neil Puttock" <[EMAIL PROTECTED]> wrote: > >> BTW, I think some of the headwords would look better without >> ragged-right = ##t. > > Modify at will. :) > In this case, please change the actual .ly. > > Cheers, > - Graham > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GDP question about piano templates & dynamics
Well, at least that explains what the New_fingering_engraver is! As long as the engraver is under construction, is it easy to make the skyline 'disappear' between dynamic marks so that it behaves more like the figured bass engraver (see image)? Currently the entire row of dynamic marks are shifted vertically to avoid a collision that can't happen. Andrew On Sat, Jun 28, 2008 at 3:20 PM, Neil Puttock <[EMAIL PROTECTED]> wrote: > 2008/6/28 Andrew Hawryluk <[EMAIL PROTECTED]>: >> I will leave the Piano docs as they are with respect to dynamics and >> the templates, at least for now. In the meanwhile, I am looking >> forward to the New_dynamic_engraver very much! > > Hehe, I wouldn't get too excited; the new engravers are already in use > (the old dynamics engraver is commented out in engraver-init.ly). > AFAIK, they don't add anything new; the old engraver was too > complicated, so its functionality has been split into two engravers. > > Regards, > Neil > <>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GDP question about piano templates & dynamics
I will leave the Piano docs as they are with respect to dynamics and
the templates, at least for now. In the meanwhile, I am looking
forward to the New_dynamic_engraver very much!
Andrew
On Sat, Jun 28, 2008 at 9:02 AM, Neil Puttock <[EMAIL PROTECTED]> wrote:
> 2008/6/25 Graham Percival <[EMAIL PROTECTED]>:
>> Neil,
>>
>> If you're not busy finishing the markup stuff, could you take a
>> look at this?
>
> I don't think it's a good idea to implement a PianoDynamics context
> until it's working properly; while the centring works fine, there are
> problems with the horizontal alignment because the dynamics aren't in
> the same voice context as the notes (see Issue 620). In addition, the
> New_dynamic_engraver isn't quite ready to be used here, since there
> are some callback changes required to prevent warning messages.
>
>> BTW, why *aren't* the markup docs finished yet? I mean, a whole
>> bunch of Font stuff aren't done. All the \bigger \smaller \teeny
>> etc can use practically the same example;
>> \markup{ one \command two}
>>
>> I know it's not exciting work, but that's life doing docs. Just
>> grab a bottle of wine or bag of candy[1] and get it over with. I
>> bet you could finish 95% of \markup commands in an hour,
>
> I wish that were the case; got any tips on working faster (without
> causing massive breakage)? :)
>
> Regards,
> Neil
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: proposed enhancement to vertical stretching logic
On Wed, Jun 25, 2008 at 2:48 AM, Joe Neeman <[EMAIL PROTECTED]> wrote: > On Wed, Jun 25, 2008 at 7:03 AM, Andrew Hawryluk <[EMAIL PROTECTED]> > wrote: >> >> Reinhold started a recent thread on -user about some problems with the >> current vertical spacing behaviour, particularly when stretching large >> systems to fill a page: >> http://lists.gnu.org/archive/html/lilypond-user/2008-06/msg00309.html >> >> To summarize, vertical stretching should be smart enough to add extra >> space where it is needed most rather than equally distributing it >> between all the staves. >> >> After giving it some thought, I believe that the desired behaviour can >> be achieved by a system of 'pre-stretched' springs. Since I'm not >> fluent enough in LP internals to send it as C++, it's in English & >> pseudocode. It's too big for the email attachment limit, so I have >> posted it here: >> http://www.musicbyandrew.ca/springs.pdf > > Thanks for the detailed description. I have had a short look and will have a > longer one once I have access to a printer (I hate trying to read things > like this on-screen). However, I think that LilyPond´s spring algorithms are > already close to the ones you are describing. Have a look in > simple-spacer.cc -- it is reasonably self-contained. Unfortunately, these > spring algorithms aren´t used in the vertical stretching step, which is > completely naive; they are only used in horizontal and vertical spacing (ie. > between systems, not within them). Also, our springs have an ideal length as > well as parallel (and even overlapping) rods. This allows us to express the > fact that the "best" spacing (ie. the one with the least force) is not > necessarily the closest spacing. > > Joe > > > Yes, simple-spacer.cc is very encouraging. I will take a closer look at it (and springs.cc), but at first glance it appears to do everything we would need for a 'smart' vertical stretching routine, and more. Anything we don't have to write is a good thing! Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
proposed enhancement to vertical stretching logic
Reinhold started a recent thread on -user about some problems with the current vertical spacing behaviour, particularly when stretching large systems to fill a page: http://lists.gnu.org/archive/html/lilypond-user/2008-06/msg00309.html To summarize, vertical stretching should be smart enough to add extra space where it is needed most rather than equally distributing it between all the staves. After giving it some thought, I believe that the desired behaviour can be achieved by a system of 'pre-stretched' springs. Since I'm not fluent enough in LP internals to send it as C++, it's in English & pseudocode. It's too big for the email attachment limit, so I have posted it here: http://www.musicbyandrew.ca/springs.pdf I realize that it may be too late in the 2.11 development cycle to start in on something like this right away, but I'd like to hear what you think and how hard it would be to accomplish. I'm very excited about the way this reasonably simple model could accomplish all the objectives of vertical stretching. I'm looking forward to hear what you have to say! If you want, I have also posted the LaTeX file and the figure image: http://www.musicbyandrew.ca/springs.tex http://www.musicbyandrew.ca/prestretchedsprings.png Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Alignment of metronome marks
If its any help, the marks that are centered over time signatures can
be left-aligned by the command
\once \override Score.TimeSignature #'break-align-anchor-alignment = #LEFT
Andrew
On Tue, Jun 24, 2008 at 12:57 PM, Till Rettig <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Reinhold Kainhofer schrieb:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Am Dienstag, 24. Juni 2008 schrieben Sie:
>
>
> I don't know about that one, or about how it was before. My Gardner
> Notation (did I recall the name correctly) said it should always be aligned
> with the middle of the key if any, else with the middle of the time
> signature.
>
>
> Actually, my copy of "Music notation" by Gardner Read says on page 278:
> "The initial letter of the term (usually a capital) customarily is aligned
> over the meter signature, or -- if none is present -- over the first
> notational element of the measure, such as note-heads, accidentals, repeat
> signs, and so on."
>
>
> That's what I meant and remembered wrong, this solution seems much easier. I
> send you the test file I created some time ago, I took it from rehearsal
> marks alignment might be that this is broken. I created the file sometimes
> in march I think, my last saving date is the 4. of April, so that would be
> some .3x-version. On 2.11.45 it works as expected. I removed the \once from
> the alignment and they align then correct to where they should.
>
> Till
>
> \relative {
>
> c1
>
> \key cis \major
>
> \clef alto
>
> %\time 5/4
>
> \once \override Score.RehearsalMark #'self-alignment-X = #left
>
> \override Score.RehearsalMark #'break-align-symbols =
> #'(key-signature)
>
> % \override Score.RehearsalMark #'break-align-symbols =
> #'(time-signature)
>\time 5/4
>
> \mark "on key"
>
> cis
>
> \key ces \major
>
> \override Score.RehearsalMark #'break-align-symbols = #'(clef)
>
> \clef treble
>
> \mark "on clef"
>
> ces
>
> \override Score.RehearsalMark #'break-align-symbols =
> #'(time-signature)
>
> \key d \minor
>
> \clef tenor
>
> \time 3/4
>
> \mark "on time"
>
> c
>
> }
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-devel
>
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
GDP question about piano templates & dynamics
I'm working on the Piano section of the GDP and had a question. The notation manual includes a template for piano music with centered dynamics, and there was some discussion a while back about including a PianoDynamics context in LilyPond itself: http://lists.gnu.org/archive/html/lilypond-devel/2008-02/msg00072.html http://code.google.com/p/lilypond/issues/detail?id=581 Is this still being considered for inclusion? If so, I'll modify the piano docs to match, and I could also test the proposed context against some typographically challenging piano music to make sure we haven't missed anything obvious. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Should \relative be the default for musicxml2ly
I, too, am in favour of relative as the default. -AH On Feb 8, 2008 9:40 AM, Reinhold Kainhofer <[EMAIL PROTECTED]> wrote: > Hi all, > Musicxml2ly supports converting to both relative pitches and absolute pitches. > The question I have is, which one should be the default? The other would be > available via a command-line option (either -r / --relative > or -a / --absolute) to musicxml2ly. > > I actually prefer relative pitches, so I'm in favor of using -r by default and > absolute only when given on the command line. > What do you think? > > Cheers, > Reinhold > -- > -- > Reinhold Kainhofer, Vienna University of Technology, Austria > email: [EMAIL PROTECTED], http://reinhold.kainhofer.com/ > * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ > * K Desktop Environment, http://www.kde.org, KOrganizer maintainer > * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
