Re: GDP: the snippets vs. texinfo
On 09.11.2007 (21:02), Graham Percival wrote: OK, it's finally time for the big fight! In managing the docs, I need to weigh multiple contradictory demands. PDF vs. HTML: pdf readers generally prefer to have consecutive documentation, with few links. HTML readers generally prefer to have links everywhere. Slight correction: pdf readers do like links -- internal ones -- it's a Good Thing. Having unneccessary divisions into separate documents which then cannot be linked, is a Bad Thing. Stable docs vs. wiki: some people want an unchanging, complete, finished set of docs, particularly if they print them out. Other people like the constant flux of web 2.0 stuff. I agree completely with your position that there should be one stable, complete, fixed set of docs, and that a wiki solution is not good for a complex piece of software like LP. On the other hand, I see the numerous private LP-tips-and-tricks-pages as a result of this: a feeling something like: I have figured out some neat things but since the docs are stable, complete, fixed, there is no way in there, so I'll make my own page. This is fine, but for the user who is looking for that extra information, it means that he has to hunt around among disparate pages of varying quality, organization, and up-to-date-ness. This may not be an accurate description anymore: with the LSR as a well-established and semi-official entity, there is hardly any need for the private pages anymore. In other words: I think it's fine as it is now: a fixed documentation and an officially endorsed repo of user-contributed stuff. One might still discuss practicalities: should the LSR only be snippets, is snippets the right term (or does it give too much associations in the direction of trifles?), etc. but that is another discussion for another thread. Out of all of these concerns, I naturally feel that my own position is the most important. If anybody wants me to relax my we don't have the resources to do this position, please volunteer in GDP. If I have more resources, of course I'll accept more good doc ideas, As an aside: I did volunteer, but I still get the we don't have the resources reply. :-) Some PDF users may not be so fond of the snippets because they move material out of the main docs. I'd like to point out that the Snippets are available as PDF, so that might mitigate this concern. The pdf does not contain the LP code, so it is fairly useless, at least in its current state. My proposal, taking into consideration all the contradictory demands laid out at the top of this email, is to have one or two tweaks in the @commonprop. The main goal of @commonprop is to pique the interest of a reader, to encourage him to follow the Snippets: foo, bar links. Finally, the reason why I started writing this: is this really the purpose of @commonprops? Or phrased differently: given the lack of resources and the concern that the documentation files grow too big, is it really a good idea to fill it up with appetizers? What I want to say is: if what you're saying is that everything which is now in @commonprop is just appetizers, some of it could even be removed, and what remains will remain as appetizers, I disagree, but if you're saying that the @commonprops should be revised so that all that which is necessary to accomplish normal typesetting tasks, i.e. solve commonly encountered problems, or as Trevor recently wrote: to reproduce anything in a score found on their bookshelves, should be elevated to main documentation text whereas that which is more of the btw, you can also do THIS kind could be moved to the LSR, I do agree. In any case, the flow should go in both directions: important tweaks in the LSR should be moved into the docs (but I think we agree on that). On the whole: the NR should contain everything and nothing but that which is necessary for the score on the bookshelf test. Eyolf -- Several years ago, an international chess tournament was being held in a swank hotel in New York. Most of the major stars of the chess world were there, and after a grueling day of chess, the players and their entourages retired to the lobby of the hotel for a little refreshment. In the lobby, some players got into a heated argument about who was the brightest, the fastest, and the best chess player in the world. The argument got quite loud, as various players claimed that honor. At that point, a security guard in the lobby turned to another guard and commented, If there's anything I just can't stand, it's chess nuts boasting in an open foyer. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: NR Specification
On 08.11.2007 (15:44), Graham Percival wrote: Based on the recent discussions, what should change in the written policy? I'd say: the following sentence: However, they should be familiar with the material in the Learning Manual (particularly ``Fundamental Concepts''), so do not repeat that material in this book. Also, you should assume that users Fundamental concepts should be explained in the NR also, but in a different style than in the LM: in the NR in a precise, technical man page-like way, in the LM in a tutorial style. There should not be *information* in the LM which is not also available from the NR, it should just be presented differently. Eyolf -- Sometimes I indulge myself in safaris which no other being may take. I strike inward along the axis of my memories. Like a schoolchild reporting on a vacation trip, I take up my subject. Let it be . . . female intellectuals! I course backward into the ocean which is my ancestors. I am a great winged fish in the depths. The mouth of my awareness opens and I scoop them up! Sometimes... sometimes I hunt out specific persons recorded in our histories. What a private joy to relive the life of such a one while I mock the academic pretentions which supposedly formed a biography. -- The Stolen Journals ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Centering bass figures vertically (lilypond-book)
Hi all,
I'm working on a LaTeX document with integrated Lilypond(2.11.34)
snippets. Mostly the snippets only consist of a bass figure, like this:
\begin[ragged-right, staffsize=12]{lilypond}
\new FiguredBass \figuremode { \set figuredBassAlterationDirection = #1
5! 4 }
\end{lilypond}
I would like to vertically center these figures in relation to the text
i.e. with \parbox[c]. But since Lilypond adds some whitespace above the
figures' top, this doesn't work. Is there a way to center the figures
vertically or to remove the free space above(or add some at the bottom,
too)?
Regards,
Michael
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: the snippets vs. texinfo
Eyolf Østrem wrote: On 09.11.2007 (21:02), Graham Percival wrote: PDF vs. HTML: pdf readers generally prefer to have consecutive documentation, with few links. HTML readers generally prefer to have links everywhere. Slight correction: pdf readers do like links -- internal ones -- it's a Good Thing. Having unneccessary divisions into separate documents which then cannot be linked, is a Bad Thing. Oh, was that your concern? Separate documents can still be linked. I thought we already had that, but apparently it wasn't working. Take a look at tomorrow's GDP. (I think the files need to be in the same directory, however) (also, they look uglier than they should. As always, I'm accepting technical help) However, these links don't help people who print out PDFs. (well, they help slightly, but they're not ideal. OTOH, there's no difference between a link to a different document and a link to the same document -- actually, if anything I'd suggest that links to other documents are better, since you can have two printed manuals open at the same time) On the other hand, I see the numerous private LP-tips-and-tricks-pages as a result of this: a feeling something like: I have figured out some neat things but since the docs are stable, complete, fixed, there is no way in there, so I'll make my own page. This is fine, but for the user who is looking for that extra information, it means that he has to hunt around among disparate pages of varying quality, organization, and up-to-date-ness. I would argue that this is _not_ fine, for precisely the reasons you state. Ideally, users should look for info in two places: - official docs (be it NR, IR, LM, etc) - LSR (which is massively promoted, and linked to, from the official docs) One might still discuss practicalities: should the LSR only be snippets, is snippets the right term (or does it give too much associations in the direction of trifles?), etc. but that is another discussion for another thread. The real music tag in LSR is aimed at longer pieces. (it currently doesn't do that, simply because we don't have any pieces to tag with this) Out of all of these concerns, I naturally feel that my own position is the most important. If anybody wants me to relax my we don't have the resources to do this position, please volunteer in GDP. If I have more resources, of course I'll accept more good doc ideas, As an aside: I did volunteer, but I still get the we don't have the resources reply. :-) The volunteer more. Eyolf, currently you are the *only* person working on Rewriting NR 1. The entire chapter needs to be done before the end of 2007. Now do you see why I keep on saying we can't do X? :( Some PDF users may not be so fond of the snippets because they move material out of the main docs. I'd like to point out that the Snippets are available as PDF, so that might mitigate this concern. The pdf does not contain the LP code, so it is fairly useless, at least in its current state. That's on the todo list. My proposal, taking into consideration all the contradictory demands laid out at the top of this email, is to have one or two tweaks in the @commonprop. The main goal of @commonprop is to pique the interest of a reader, to encourage him to follow the Snippets: foo, bar links. Finally, the reason why I started writing this: is this really the purpose of @commonprops? Well, that's the main question in this discussion. :-) My proposal -- only a *proposal* -- is to use it as appetizers. In any case, the flow should go in both directions: important tweaks in the LSR should be moved into the docs (but I think we agree on that). Important tweaks in LSR are moved into the docs by giving them a docs tag. My rule of thumb for the docs: after the end of GDP, the NR should not change for the next five years. This obviously isn't possible -- no matter how careful we are, we'll miss a few typos or have some badly worded English. Lilypond will get some new features, which will need to some docs. The syntax will change, but this can/should/might be updateable with convert-ly. The non-tweaking syntax is fairly stable, at least. Stuff which might be changing more often -- the exact syntax of tweaks, making tweaks more interesting/complicated/simpler/etc, adding new tweaks -- should be done in a manner which allows easy updating. LSR is such a method. In this case, about 80% of my argument relies on lack of resources rather than I think that documentation looks better this way. Or in other words, documentation is a process, not a product. And we have very few resources which we direct towards that process. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: the snippets vs. texinfo
On 10.11.2007 (06:17), Graham Percival wrote: Eyolf Østrem wrote: Slight correction: pdf readers do like links -- internal ones -- it's a Good Thing. Having unneccessary divisions into separate documents which then cannot be linked, is a Bad Thing. Oh, was that your concern? Half of it. The other -- main -- half is searching. Furthermore, cross-document linking isn't as uncomplicated as you make it appear: as you say, the files must be in the same dir, and they have to exist in the first place (what if I use my own copy of the NR and for some reason haven't downloaded the PU?). On the other hand, I see the numerous private LP-tips-and-tricks-pages as a result of this: a feeling something like: I have figured out some neat things but since the docs are stable, complete, fixed, there is no way in there, so I'll make my own page. This is fine, but for the user who is looking for that extra information, it means that he has to hunt around among disparate pages of varying quality, organization, and up-to-date-ness. I would argue that this is _not_ fine, for precisely the reasons you state. Ideally, users should look for info in two places: - official docs (be it NR, IR, LM, etc) - LSR (which is massively promoted, and linked to, from the official docs) Agreed - that's what I meant too, and I think it's a great step when we have in fact got these two channels. At the time, i.e. before LSR was firmly established, it was fine, because there was no easy outlet for that kind of wiki-like contributions, but now the LSR should take care of that. As an aside: I did volunteer, but I still get the we don't have the resources reply. :-) The volunteer more. Eyolf, currently you are the *only* person working on Rewriting NR 1. The entire chapter needs to be done before the end of 2007. Well, if what you say below is the goal, that on the whole the docs should not change after the GDP, I'd say there is no need to rush it, especially if there are so few people to do the work. As for me, I have a daytime job too... Now do you see why I keep on saying we can't do X? :( Of course. As long as it doesn't turn into a We can't do X, so we won't even consider it, not even if it would make Y -- which we can and must do -- easier. But I'm not advocating featuritis. Finally, the reason why I started writing this: is this really the purpose of @commonprops? Well, that's the main question in this discussion. :-) My proposal -- only a *proposal* -- is to use it as appetizers. In any case, the flow should go in both directions: important tweaks in the LSR should be moved into the docs (but I think we agree on that). Important tweaks in LSR are moved into the docs by giving them a docs tag. but that will only include them in the snippet part of the docs, right? This may of course be enough in many cases, but there are some snippets which are central enough to merit inclusion in the main text as well. The snippet Adding an extra staff (http://lsr.dsi.unimi.it/LSR/Item?id=110) IMHO should be included directly, and Adding beams, slurs, ties, etc. (http://lsr.dsi.unimi.it/LSR/Item?id=321) is even *formulated* in a Documentation way, as an extension to what is already in there, rather than an additional piece of information. Those two could go almost straight in. eyolf (who will now stop spending time writing list mail and instead do some volunteer work...) -- Delay not, Caesar. Read it instantly. -- Shakespeare, Julius Caesar 3,1 Here is a letter, read it at your leisure. -- Shakespeare, Merchant of Venice 5,1 [Quoted in VMS Internals and Data Structures, V4.4, when referring to I/O system services.] ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: the snippets vs. texinfo
Eyolf Østrem wrote: The entire chapter needs to be done before the end of 2007. Well, if what you say below is the goal, that on the whole the docs should not change after the GDP, I'd say there is no need to rush it, especially if there are so few people to do the work. Two phases: before 2007, get GDP no worse than the 2.11 docs. That means somebody spending a week looking at each section in NR 1 and cleaning up the worst TODO / FIXMEs. After 2007, if anybody is still interested, we'll try go bring GDP from not worse than to significantly better than. Or perhaps even perfect. :) Now do you see why I keep on saying we can't do X? :( Of course. As long as it doesn't turn into a We can't do X, so we won't even consider it, not even if it would make Y -- which we can and must do -- easier. True. Important tweaks in LSR are moved into the docs by giving them a docs tag. but that will only include them in the snippet part of the docs, right? This may of course be enough in many cases, but there are some snippets which are central enough to merit inclusion in the main text as well. The snippet Adding an extra staff (http://lsr.dsi.unimi.it/LSR/Item?id=110) IMHO should be included directly, and Adding beams, slurs, ties, etc. (http://lsr.dsi.unimi.it/LSR/Item?id=321) is even *formulated* in a Documentation way, as an extension to what is already in there, rather than an additional piece of information. Those two could go almost straight in. First, THANK YOU!!! for bringing up specific examples. Especially in this case, since I was thought you were talking about a totally different kind of snippet. Second, yes I totally agree; these kinds of snippets should be in the main docs. In fact, 321 is already verbatim in LM 3.3.1. 110 doesn't appear anywhere, but I'm adding it to LM 3 right now. eyolf (who will now stop spending time writing list mail and instead do some volunteer work...) :) Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
octava line broken in polyphony
Why does the octava line in this example get broken up?
\relative c' {
\clef treble
\time 2/2
{ r2 b'4 b8 c ~ | c2 e4 e8 f | #(set-octavation 1) r4 g'2 c,4 ~
| c e2. | r4 a2 e4 ~ | e f2. | } \\ { e,,4 e8 f e2 | a4 a8 bes a2 |
a' a | a f | e g | a1 | }
{ r4 g'2 c,4 ~ | c e2. | r4 a2 e4 ~ | e f2. | #(set-octavation
0) } \\ { a,2 a | a f | e g | a1 | } \clef bass { r4 ees,, aes
c } \\ { c } \clef treble d' d'2 | b b'1 | r1 |
}
Charles
--
http://www.campdeadly.com
http://www.campdeadly.com/blog
octava-test.ly
Description: Binary data
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: page breaks related to header size
I also have (just last night) had a similar vertical spacing problem (2.11.34). I had a piece covering two pages, the majority on the first page, and the page break was where I wanted it. Then I change a bit of the spacing of a text markup (extra-offset) and I lost one of the systems on the first page. I thought, no problem I'll just adjust some of the parameters ( like between-system-padding, between-system-space). But I couldn't get the last system (or sometimes last two systems), back onto the first page. I could get the systems to be closer together, but that would just leave even more space at the bottom of the page (more than enough space for one if not two systems). I adjusted the top margin to something like 1mm and I got my system back, but the systems were way more spaced out than they needed to be, and the small margin at the top was too small. I ended up with finding a different place to break the pages. Maybe I should note that each system contained a ChordNames, one regular Staff, and another special Staff which had a linecount of 0. I had wondered if that last Staff might be confusing the vertical spacing. Jeff. On 10-Nov-07, at 1:38 AM, Paul Scott wrote: Michael David Crawford wrote: Paul Scott wrote: 2.11.34 In this example there is clearly room for another system on the first page. Removing anything from the header will allow another system to move to the first page. Whatever is removed from the header clearly doesn't take as much vertical space as one system. I have also found that increasing the height of the text at the bottom of the first page will increase the page count. My piece Recursion was seven pages, but when I reformatted its Creative Commons license to be a couple lines longer, the score went to eight pages. I fiddled with it for quite a while, but was completely unable to get it back to seven pages and still be sensibly laid out. Thanks for replying. It seems to me there might be a bug in how the vertical size of the next system is calculated or subtracted from the available vertical space on the current page. I have posted this in case there is some setting I am missing. Paul ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
line-width in \markuplines
Hello. According to the 2.11 docs (8.1.9), I should be able to change the line width in \markuplines using \override #'(line-width . X) but it doesn't seem to work. example: http://www.tcgalaska.com/kliros/ly/esauWood.ly Is it a bug? -- Monk Panteleimon Hermitage of the Holy Cross Wayne, WV, USA [EMAIL PROTECTED] + IC + XC + + + + + NI + KA + ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: page breaks related to header size
Jeff Elliott wrote: I also have (just last night) had a similar vertical spacing problem (2.11.34). I had a piece covering two pages, the majority on the first page, and the page break was where I wanted it. Then I change a bit of the spacing of a text markup (extra-offset) and I lost one of the systems on the first page. I thought, no problem I'll just adjust some of the parameters ( like between-system-padding, between-system-space). But I couldn't get the last system (or sometimes last two systems), back onto the first page. I could get the systems to be closer together, but that would just leave even more space at the bottom of the page (more than enough space for one if not two systems). I adjusted the top margin to something like 1mm and I got my system back, but the systems were way more spaced out than they needed to be, and the small margin at the top was too small. I ended up with finding a different place to break the pages. Maybe I should note that each system contained a ChordNames, one regular Staff, and another special Staff which had a linecount of 0. I had wondered if that last Staff might be confusing the vertical spacing. I also could get the page breaking to change with many different small changes in a system. Just moving either of the pitches in my example closer to the staff will allow another staff to from the second page to the first page. In my case it could be related to \RemoveEmptyStaffContext. Paul ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
How to put chords on a score automatically
Hi list, I'm working on a four-part score for barbershop chorus. It has four separate voices of course, and words to the lead line, as well as words to various parts of other voices. My question is this: As I arrange this, I want to have the chords I am creating displayed so I can see where the parts should go. Is there a way to have LilyPond display the chords I have created in these disparate voices? I know that the chords thus formed are not very smart (i.e. it can't recognise inversions) but that's OK -- I will remove these when the arrangement is complete. BTW, I *did* search through the Manual to see if there was something there, but could not find it -- if it *is* there, I will be happy to read the relevant entries, once they are pointed out. Thanks, Fr. Gordon Gilbert+ -- Fr. Gordon Gilbert Penetanguishene, ON ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: How to put chords on a score automatically
Father Gordon Gilbert skrev:
My question is this: As I arrange this, I want to have the chords I am
creating displayed
I am not sure I understand.
Something like this?
%%% BEGIN %%%
\version 2.10.0
sop = { g' a' }
alt = { e' f' }
bas = { c' d' }
{
\new ChordNames \sop \alt \bas
\new ChoirStaff
\new Staff \sop
\new Staff \alt
\new Staff \bas
}
%%% END %%%
-Rune
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: page breaks related to header size
On Sat, 10 Nov 2007 14:58:45 Paul Scott wrote: 2.11.34 In this example there is clearly room for another system on the first page. Removing anything from the header will allow another system to move to the first page. Whatever is removed from the header clearly doesn't take as much vertical space as one system. Thanks for the report. There was a bug (now fixed in git) that caused a miscalculation of the page height if the page began with a title. Joe ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: How to put chords on a score automatically
Rune -
Your example works on its own, and is roughly what I'm looking for, but when
I try to incorporate that syntax into my own (2.11.32) score, it doesn't
work. I'd like to see the chordnames at the top of the choirstaff so I can
check my work.
My score is such that I can't really boil it down to a minimum example, but
here is the whole thing so you can see what I'm doing. (Keep in mind that
it's not finished -- but it does compile at this stage. And having used
templates from previous works it's probably got a whole bunch of sloppy
code.)
Thanks for any help you can give.
Fr. Gordon_
\header {
filename = AmazingGrace-Sweet-Ads.ly
enteredby = Gordon Gilbert
composer = Traditional American Melody
poet = words: Rev'd John Newton, 1779
arranger = arr. Gordon Gilbert 2007
date=
title = Amazing Grace
subtitle = Arr. for Barbershop Chorus
metre =
meter = \metre
copyright = Public Domain - Permission granted to perform this
arrangement in a not-for-profit setting
style = Hymn
}
\version 2.11.23
\paper{
#(set-paper-size letter)
}
global= {
\time 3/4
\key g \major
}
tenor = \context Voice = tenor \relative c' {
\voiceOne
\override NoteHead #'color = #green
\override Stem #'color = #green
\override Beam #'color = #green {
\partial 4 r4
b'2 d8 b d2 dis4 e2 c4 b2
a4 b2 d4 e2 e4 fis2 e4 ^ like d4( ^ me c)
b4 b2 d4 d2 b4 c4.( e8 e c) b2
a4 b2 d4 d cis c b4( d) c4 ^ I b2 ^ see
r4
b4 c \times 2/3 {d8( c b)} d2 dis4 e( d) c4 b4 c
a4 b2 \times 2/3 {d8( c b)} e4( fis) g4 fis4( g) ( e4 d c)
b4 d2 \times 2/3 {d4 e8} f2 d4 c2 c4 b2
a4 b4 c d4 d( cis) c b2 c4 b2
r4
b2 ^ \markup \italic {Bluesy} d4 d2 d4 ees2 c4 b2
a4 b2 d4 ees2 ees4 f2 e4 d2
d4 b2 d4 d2 b4 c4.( ees8 ees c) b2
a4 b2 d4 d cis c b2.
e2. d e b2
\new Voice = tenorDivisi { \voiceOne
\transpose g b'
{
\override NoteHead #'color = #green
\override Stem #'color = #green
\override Beam #'color = #green {
r4 r b4 b r4 r d'4 d'4 dis' e'2. c'4 b2. r4
r d' e' e'4 fis'4 fis'4 fis' g' a' g' fis' e'
d'( e'4 f'2 ~ f'4) f'4 d'2. d'4 g'2. d'4 c'2. c'4 b a
b2. d'4 c'( d' e') g' g'2
a'2 gis'1
}}
}}
}
lead = \context Voice = lead \relative c' {
\voiceTwo
\override NoteHead #'color = #red
\override Stem #'color = #red
\override Beam #'color = #red {
\partial 4 d4
g2 b8( g) b2 a4 g2 e4 d2
d4 g2 b8( g) b2 a4 d2. ~ d2
b4 d4.^ x( b8) d( b) g2 d4 e4.( g8) g( e) d2
d4 g2 b8( g) b2 a4 g2 ( fis4 g2)
%verse 2
d4
g2 \times 2/3 {b8( a g)} b2 a4 g2 e4 d2
d4 g2 \times 2/3 {b8( a g)} b2 \times 2/3 {a4( b8)} d2. ~ d2
b4 d2 \times 2/3 {b8( a g)} b2 \times 2/3{b4( a8)} g2 \times 2/3 {e4(
d8)} d2
\times 2/3 {d4( e8)} g2 \times 2/3 {b8( a g)} b2 a4 g2. ~ g2
%verse 3
d4
g2 b8( g) b2 a4 g2 e4 d2
d4 g2 b8( g) b2 a8( b) d2. ~ d2
b4 d4.^ x( b8) d( b) g2 d4 e4.( g8) g( e) d2
d4 g2 b8( g) b2 a4 g2.
%bridge
a ^ \markup \italic {Bridge} b g fis2
%verse 4
\key b \major
\transpose g b'
{
d4 \time 4/4
g2. b8( g) b2. a4 g2. e4 d2.
d4 g2. b8( g) b2. a8( b) d'1 ~ d'2.
b4 d'2 ~ d'8( b8) d'( b) g2. d4 e2 ~ e8 ( g8) g( e) d2.
d4 g2. b8( g) b2. a4 g2 g2
b1 ^ \markup \italic {Tag}
a4 ^ \fermata b ^ \fermata c' ^ \fermata
r8 ^ \fermata d'8 d'1 d' ^ \fermata
}
\bar ||
}
}
bari = \context Voice = bari \relative c'' {
\voiceOne
\override NoteHead #'color = #blue
\override Stem #'color = #blue
\override Beam #'color = #blue {
\partial 4 d,4
g2 g4 g2 fis4 g2 a4 g2
a4 b2 b4 cis2 a4 d2 a4 ^ like a2 ^ me
g4 g2 g4 d2 g4 c2 a4 g2
a4 b2 g4 fis4. g8 fis4 g4( b) a ^ I g2 ^ see
d4
g2 g4 d'2 b4 c2 a4 g2
a4 b2 b4 a2 a4 d2 a4 a2
g4 b2 b4 d2 b4 c2 a4 g2
a4 b2 g4 fis4. e8 fis4 g2. ~ g2
d4
f2 ^ \markup \italic {Bluesy} f4 c'2 b4 bes2 bes4 g2
a4 f'2 f4 g2 g4 d2 a'4 a2
g4 f2 f4 d2 b4 bes2 a4 g2
a4 d2 f,4 fis4. e8 fis4 g2.
cis2. g b dis2
\new Voice = bariDivisi { \voiceOne
\transpose g b'
{
\override NoteHead #'color = #blue
\override Stem #'color = #blue
\override Beam #'color = #blue {
r4 r f f r r b b
fis bes2. c'4 b?2.
r4 r d' d' e' fis'2. e'4 d'
}}}
}
}
bass = \context Voice = bass \relative c' {
\voiceTwo
\override NoteHead #'color = #magenta
\override Stem #'color = #magenta
\override Beam #'color = #magenta {
\partial 4 d4
d2 b4 d2 b4 c2 e4 g2
fis4 e2 e4 a2 cis,4 d2 e4 _ like fis( _ me e)
d b2 d4 g,2 d'4 c2 e4 g2
fis4 e2 e4 d e fis g2 d4 _ I g,2 _ see
d'4
g,4 b d4 g4 d4 b c4. d8 e fis g2
fis4 e2 e4 a,4 b c4 b2.( a2) d4
g2 g4 g2 b4 c2 a4 g4( g)
fis4 e2 e4 d e fis g2 d4 g2
d4
g,2 b4 f'2 f4 c2 e4 e2
Re: page breaks related to header size
Joe Neeman wrote: On Sat, 10 Nov 2007 14:58:45 Paul Scott wrote: 2.11.34 In this example there is clearly room for another system on the first page. Removing anything from the header will allow another system to move to the first page. Whatever is removed from the header clearly doesn't take as much vertical space as one system. Thanks for the report. There was a bug (now fixed in git) that caused a miscalculation of the page height if the page began with a title. Thanks very much. Sorry I missed the bug report. Will there be a 2.11.35? Paul ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: page breaks related to header size
2007/11/11, Paul Scott [EMAIL PROTECTED]: Thanks very much. Sorry I missed the bug report. Will there be a 2.11.35? Yes. There is finally light at the end of the GUB tunnel, so hopefully this or next week. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: page breaks related to header size
Han-Wen Nienhuys wrote: 2007/11/11, Paul Scott [EMAIL PROTECTED]: Thanks very much. Sorry I missed the bug report. Will there be a 2.11.35? Yes. There is finally light at the end of the GUB tunnel, so hopefully this or next week. Great! Thanks, Paul ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
