Re: Implements the 2nd of 5 legs of getting footnotes up and running. (issue4254055)
On Mar 7, 2011, at 11:27 PM, n.putt...@gmail.com wrote: LGTM. http://codereview.appspot.com/4254055/diff/6001/lily/balloon.cc File lily/balloon.cc (right): http://codereview.appspot.com/4254055/diff/6001/lily/balloon.cc#newcode47 lily/balloon.cc:47: if (Item *item = dynamic_castItem *(me)) dynamic_castItem * (me)) Thanks! Pushed. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: shortened flags affair, part 3 - 32nds stem length
On 3/8/11, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: i don't see any discussion going on here, so i assume you agree to shortening the 32nd unbeamed stem. I attach the patch. IMO, there are two steps to this type of change: 1. discuss the aesthetics (or beautiful notation). That discussion seems to be over. 2. discuss the technical patch. That discussion may or may not be over, but I haven't seen it officially start. Could you upload this patch to rietveld? Once that's done, if the patch passes the obvious checks, I'll include it in a 48-hour patch countdown. Sorry for the extra caution, but I'm not going to push changes to the fonts on my own authority. I want to give plenty of time for people familiar with the topic to object, once it's clear that we have a precise patch on the table rather than a general discussion.. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: shortened flags affair, part 3 - 32nds stem length
On Mar 8, 2011, at 4:42 PM, Janek Warchoł wrote: Hm, i don't see any discussion going on here, so i assume you agree to shortening the 32nd unbeamed stem. I attach the patch. cheers, Janek 2011/3/5 Janek Warchoł lemniskata.bernoull...@gmail.com Carl, Han-Wen, Werner, Trevor, thanks for swift answers! 2011/3/5 Han-Wen Nienhuys hanw...@gmail.com Therefore i call for shortening 32nd unbeamed notes by 0.25 ss. Do you agree? SGTM - I don't think we ever put this much thought or analysis into the numbers we put there. :) I'm going to do more such analysis :) 2011/3/5 Werner LEMBERG w...@gnu.org: i suggest making unbeamed 32nd stems a bit shorter than they are now. The main reason for doing so is to better match the stem length of the beamed notes. While I generally agree with your suggestions, I'm not sure that it is the right solution. In many of the `red' cases of the `old' image, I think that the length of the unbeamed 32nd stems are fine, but the length of the beamed stems you are comparing to are too short. To be more precise, I would increase the minimum stem length for beamed 32nds so that the beams snap to the next, more distant staff line. Have you played with that also? No, but i did it now (by inserting \override Stem #'details #'beamed-lengths = #'(3.5 3.5 4.25) in line 21 of that proof-sheet, compiled proof-sheet with colors is here: http://www.sendspace.com/file/4ch1mg). The effects are quite what i expected - it introduces a lot of yellow and in my opinion starts looking weird in some places. Because of beam quanting, virtually all changes are of a whole staffspace, and it looks like too much, see too high.png - i prefer shorter stems in this case. However, i'm not familiar with internal workings of beam quanting - maybe changing some parameters would improve the situation without introducing new problems. By the way, what do engraving books say about it? 2011/3/5 Trevor Daniels t.dani...@treda.co.uk I was surprised to see the quite wide variation in the lengths of the beamed 32nd notes. Some seem too long and some too short. I agree that they look somewhat inconsistent. By that I mean moving them to the next quan position to make them shorter or longer respectively would seem to be an improvement. I wonder if the default quanting parameters are optimally tuned. Perhaps this should be investigated first? As we have seen above, simply changing beamed-lengths doesn't work very well. In my opinion we should decrease the length of unbeamed 32nds as i suggested, and also lenghten some beamed ones, but not by a whole staffspace. For example look at the some improvement.png. Current beam behaviour is on the left, and the beamed stems are too short there (and the unbeamed stem is shortened there by 0.25 ss as i suggested). On the right is my idea of fixing this. The trick is that the version on the right has exactly the same quanting problems, but they appear in the lower part of the beam instead of the upper part. Somehow LilyPond never uses this solution. Implementing this would fix 8 out of 18 oranges, and i have ideas how other oranges could be improved as well. (red - unbeamed stem is 1 staffspace longer than beamed stem, orange - 0.75 staffspace longer) As you can see, there is quite a lot of red and orange there. Now what would it look like if we changed the length of the unbeamed 32nd notes to 4.25 ss (instead of 4.5)? Look here: http://www.sendspace.com/file/2mzt4a Looks much better to me - no red, only orange. Unfortunately it introduces some yellow (unbeamed stem shorter than beamed one), but it's just a little. Agreed, irrespective of my comments on quanting above. Increasing the length of the very short beamed 32nds would remove some red, but reducing the length of the very long ones would introduce more, or at least more orange. Exactly. So, should i Prepare the Patch (it would be really tiny :D)? cheers, Janek Hey all, I don't have a particular opinion either way on this subject, but I would like to say that I trust Janek on this topic more than I trust myself and thus I defer to his judgement. Even if you don't have a strong opinion for or against this change, I'd still like to see more discussion on Janek's proposal so that he knows whether or not to move forward with it. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: shortened flags affair, part 3 - 32nds stem length
On Mar 9, 2011, at 12:43 PM, m...@apollinemike.com wrote: On Mar 8, 2011, at 4:42 PM, Janek Warchoł wrote: Hm, i don't see any discussion going on here, so i assume you agree to shortening the 32nd unbeamed stem. I attach the patch. cheers, Janek 2011/3/5 Janek Warchoł lemniskata.bernoull...@gmail.com Carl, Han-Wen, Werner, Trevor, thanks for swift answers! 2011/3/5 Han-Wen Nienhuys hanw...@gmail.com Therefore i call for shortening 32nd unbeamed notes by 0.25 ss. Do you agree? SGTM - I don't think we ever put this much thought or analysis into the numbers we put there. :) I'm going to do more such analysis :) 2011/3/5 Werner LEMBERG w...@gnu.org: i suggest making unbeamed 32nd stems a bit shorter than they are now. The main reason for doing so is to better match the stem length of the beamed notes. While I generally agree with your suggestions, I'm not sure that it is the right solution. In many of the `red' cases of the `old' image, I think that the length of the unbeamed 32nd stems are fine, but the length of the beamed stems you are comparing to are too short. To be more precise, I would increase the minimum stem length for beamed 32nds so that the beams snap to the next, more distant staff line. Have you played with that also? No, but i did it now (by inserting \override Stem #'details #'beamed-lengths = #'(3.5 3.5 4.25) in line 21 of that proof-sheet, compiled proof-sheet with colors is here: http://www.sendspace.com/file/4ch1mg). The effects are quite what i expected - it introduces a lot of yellow and in my opinion starts looking weird in some places. Because of beam quanting, virtually all changes are of a whole staffspace, and it looks like too much, see too high.png - i prefer shorter stems in this case. However, i'm not familiar with internal workings of beam quanting - maybe changing some parameters would improve the situation without introducing new problems. By the way, what do engraving books say about it? 2011/3/5 Trevor Daniels t.dani...@treda.co.uk I was surprised to see the quite wide variation in the lengths of the beamed 32nd notes. Some seem too long and some too short. I agree that they look somewhat inconsistent. By that I mean moving them to the next quan position to make them shorter or longer respectively would seem to be an improvement. I wonder if the default quanting parameters are optimally tuned. Perhaps this should be investigated first? As we have seen above, simply changing beamed-lengths doesn't work very well. In my opinion we should decrease the length of unbeamed 32nds as i suggested, and also lenghten some beamed ones, but not by a whole staffspace. For example look at the some improvement.png. Current beam behaviour is on the left, and the beamed stems are too short there (and the unbeamed stem is shortened there by 0.25 ss as i suggested). On the right is my idea of fixing this. The trick is that the version on the right has exactly the same quanting problems, but they appear in the lower part of the beam instead of the upper part. Somehow LilyPond never uses this solution. Implementing this would fix 8 out of 18 oranges, and i have ideas how other oranges could be improved as well. (red - unbeamed stem is 1 staffspace longer than beamed stem, orange - 0.75 staffspace longer) As you can see, there is quite a lot of red and orange there. Now what would it look like if we changed the length of the unbeamed 32nd notes to 4.25 ss (instead of 4.5)? Look here: http://www.sendspace.com/file/2mzt4a Looks much better to me - no red, only orange. Unfortunately it introduces some yellow (unbeamed stem shorter than beamed one), but it's just a little. Agreed, irrespective of my comments on quanting above. Increasing the length of the very short beamed 32nds would remove some red, but reducing the length of the very long ones would introduce more, or at least more orange. Exactly. So, should i Prepare the Patch (it would be really tiny :D)? cheers, Janek Oops...I responded to the wrong e-mail! I meant part 4 of the affair (about the gaps between the tip of the flag and the notehead). Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Adds automatic numbering to footnotes (issue4244064)
Long train rides = automatic footnotes. Two new regtests are included to show this in action. Cheers, MS http://codereview.appspot.com/4244064___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Using #(define fonts) gives me an ill-looking feta font
On Mar 9, 2011, at 12:14 AM, James Lowe james.l...@datacore.com wrote: Hello, I am using Mac OS X (in case that matters) and I am having an issue where using the following construct in a \paper block: myStaffSize = #24 #(define fonts (make-pango-font-tree Baskerville Optima Courier (/ myStaffSize 24))) Should be (/ myStaffSize 20). HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] ly/property-init.ly: remove cautionary accidentals in improvisation
Hello dear developers,
We got recently on lilypond-user-fr a message from a user that wanted
to remove cautionary accidentals from squashed passages (using
Pitch_squash_engraver and \improvisationOn).
Actually
\override Accidental #'stencil = ##f
is part of the definition of improvisationOn but not
\override AccidentalCautionary #'stencil = ##f
May I suggest to add it?
You'll find this change as PATCH in attachment.
Thanks in advance!
Cheers,
Xavier
--
Xavier Scheuer x.sche...@gmail.com
From f51968b9d3d3dbea3b7277dc86cce60fa794bff2 Mon Sep 17 00:00:00 2001
From: Xavier Scheuer x.sche...@gmail.com
Date: Wed, 9 Mar 2011 15:41:08 +0100
Subject: [PATCH] ly/property-init.ly: remove cautionary accidentals in improvisation
improvisationOn removes the stencil of Accidental but did not remove
the stencil of AccidentalCautionary .
This PATCH fix this (as well as the appropriate reciprocal in
improvisationOff ).
---
ly/property-init.ly |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/ly/property-init.ly b/ly/property-init.ly
index 3bed819..2e29335 100644
--- a/ly/property-init.ly
+++ b/ly/property-init.ly
@@ -252,11 +252,13 @@ improvisationOn = {
\set squashedPosition = #0
\override NoteHead #'style = #'slash
\override Accidental #'stencil = ##f
+ \override AccidentalCautionary #'stencil = ##f
}
improvisationOff = {
\unset squashedPosition
\revert NoteHead #'style
\revert Accidental #'stencil
+ \revert AccidentalCautionary #'stencil
}
--
1.7.1
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Adds automatic numbering to footnotes. (issue4244064)
Hi Mike,
Nice job, as usual !
However, I noticed some obvious problems. You probably already know
them.
Here, the padding :
\markup {
\footnote b c
\footnote e f
}
Here, the horizontal space between markup and number :
\markup {
\footnote d e
\footnote f g
}
Also : why are in-text numbers 0.75\mm higher than footnotes numbers ?
To conclude, this horizontal spacing bug (3 spacing bugs in 1) :
\markup {
\footnote a a \footnote a a \footnote a a
\footnote a a \footnote a a \footnote a a
\footnote a a \footnote a a \footnote a a
\footnote a a
}
Now, some suggestions :
Can you create another footnote-numbering-function that prints 1.
blablabla instead of the raised numbers ? Maybe with an argument to
define whether there should be a space after the dot.
Optionally another that handles [1] notation.
And maybe a property to change font-series and font-shape for these
numbers (those that are in the notes). Indeed, some editors use bold 1.
while others use italic raised numbers.
There is often a no-break thin space between a word and its note number
in french editions (Flammarion, Le livre de poche, etc).
It would be great if we could this input :
\markup \footnote a { bla bla bla bla bla bla [many others] bla bla bla
bla bla bla }
instead of :
\markup \footnote a \justify { bla bla bla bla bla bla [many others] bla
bla bla bla bla bla }
And it would be even greater if we could use :
\markup a \footnote { bla bla }
instead of :
\markup \footnote a { bla bla }
I know this last issue is very tricky... And it has a low priority.
And again, great job !
Regards,
Bertrand
http://codereview.appspot.com/4244064/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Makes the footnote separator span part of the page (issue4237059)
http://codereview.appspot.com/4237059/diff/1/scm/define-markup-commands.scm File scm/define-markup-commands.scm (right): http://codereview.appspot.com/4237059/diff/1/scm/define-markup-commands.scm#newcode159 scm/define-markup-commands.scm:159: (markup #:fill-line I suggest you move this fill-line to ly/paper-defaults-init.ly As left-aligned footnotes separators are more usual than the centered ones, it must be easy for users to modify this. http://codereview.appspot.com/4237059/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] ly/property-init.ly: remove cautionary accidentals inimprovisation
Hi Xavier Thanks. Pushed to origin/master. Trevor - Original Message - From: Xavier Scheuer x.sche...@gmail.com To: lilypond-devel lilypond-devel@gnu.org Cc: e.cauchemez e.cauche...@laposte.net Sent: Wednesday, March 09, 2011 2:51 PM Subject: [PATCH] ly/property-init.ly: remove cautionary accidentals inimprovisation Hello dear developers, We got recently on lilypond-user-fr a message from a user that wanted to remove cautionary accidentals from squashed passages (using Pitch_squash_engraver and \improvisationOn). Actually \override Accidental #'stencil = ##f is part of the definition of improvisationOn but not \override AccidentalCautionary #'stencil = ##f May I suggest to add it? You'll find this change as PATCH in attachment. Thanks in advance! Cheers, Xavier -- Xavier Scheuer x.sche...@gmail.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: Using #(define fonts) gives me an ill-looking feta font
Hello, -Original Message- From: Carl Sorensen c_soren...@byu.edu Date: Wed, 9 Mar 2011 05:53:34 -0700 To: James Lowe james.l...@datacore.com Cc: Lilypond Dev lilypond-devel@gnu.org, LilyPond User lilypond-u...@gnu.org Subject: Re: Using #(define fonts) gives me an ill-looking feta font On Mar 9, 2011, at 12:14 AM, James Lowe james.l...@datacore.com wrote: Hello, I am using Mac OS X (in case that matters) and I am having an issue where using the following construct in a \paper block: myStaffSize = #24 #(define fonts (make-pango-font-tree Baskerville Optima Courier (/ myStaffSize 24))) Should be (/ myStaffSize 20). That'll teach me for cross-posting, thanks Carl, but (cut pasted here as in User) Try changing the second number in the font tree parameter -- (/ myStaffSize 20) I have been using this parameter and find this fixed a similar problem I had. Can't remember why it had to be 20 but that's what worked for me. That, sadly didn't change anything, I also removed/commented my '#(set-global-staff-size 24)' in the main file and that did revert back to the correct-looking glyphs but the staff size is now too small and *just* using this 'define' setting seems to do nothing to the actual staff size of my file. The default is too small, so at this time as I still don't know what this 'myStaffSize' entry does or doesn't do and as this seems to be the only documented way of establishing whole document fonts, I am forced (unfortunately) to use explicit overrides in each of my sixteen scores (sigh). Do any 'schemers' understand this 'define' and perhaps give me some clues on how to use this without it affecting my glyphs? James ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: left-aligning grobs to other grobs
Hi David, thanks for sharing this! 2011/3/8 David Nalesnik dnale...@umail.iu.edu: Hi, all -- Attached is a function which started out as an attempt to get tempo indications to line up with the left edge of the time signature. It's been generalized so that you can left-align any grob responsive to 'extra-offset to the closest grob of a specified type in that system (as far as I can tell so far -- you could even left-align a notehead to a barline, if you were so inclined...) It locates the closest grob by first searching all of the grobs in a system for every instance of the target type, then selecting the one that is closest horizontally. (For example, if you want to align something to a barline, the function would determine where all the barlines are, then choose the nearest one). I have several questions: (1) Is there a way to locate the nearest grob more efficiently, so the routine doesn't have to search the entire system? (2) Is there a way to exclude grobs that are in the same system, but on a different staff? I've looked at the 'staff-symbol property, but it's empty in some cases. (3) Does anybody have any suggestions how to improve the coding? I'm enjoying learning Scheme, but my approach is rather hit-and-miss! Best, David ___ lilypond-user mailing list lilypond-u...@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds automatic numbering to footnotes. (issue4244064)
Thanks for the helpful comments! Responses inlined below.
On Mar 9, 2011, at 6:38 PM, bordage.bertr...@gmail.com wrote:
Hi Mike,
Nice job, as usual !
However, I noticed some obvious problems. You probably already know
them.
Here, the padding :
\markup {
\footnote b c
\footnote e f
}
Here, the horizontal space between markup and number :
\markup {
\footnote d e
\footnote f g
}
This is not untrue...I'll need to study the code a bit more to know if this is
elegantly modifiable. And by I I mean hopefully not just I.
If it is not elegantly modifiable, I think that the best way to handle this (as
annoying as it would be) would be to take every common glyph in the alphabet
and figure out the ideal spacing between it and a footnote.
Also : why are in-text numbers 0.75\mm higher than footnotes numbers ?
No good reason, but I'd be amenable to changing it to whatever.
To conclude, this horizontal spacing bug (3 spacing bugs in 1) :
\markup {
\footnote a a \footnote a a \footnote a a
\footnote a a \footnote a a \footnote a a
\footnote a a \footnote a a \footnote a a
\footnote a a
}
Yikes...I'll get on that!
Now, some suggestions :
Can you create another footnote-numbering-function that prints 1.
blablabla instead of the raised numbers ? Maybe with an argument to
define whether there should be a space after the dot.
Optionally another that handles [1] notation.
Yup! I'll work on that tomorrow.
And maybe a property to change font-series and font-shape for these
numbers (those that are in the notes). Indeed, some editors use bold 1.
while others use italic raised numbers.
Ditto - I'll make a collection of useful functions.
There is often a no-break thin space between a word and its note number
in french editions (Flammarion, Le livre de poche, etc).
I'll look into that (I have Dalloz Code de l'Urbanisme in front of me right
now...ugh).
It would be great if we could this input :
\markup \footnote a { bla bla bla bla bla bla [many others] bla bla bla
bla bla bla }
instead of :
\markup \footnote a \justify { bla bla bla bla bla bla [many others] bla
bla bla bla bla bla }
Yes, but this hits upon a bigger problem: LilyPond does not handle text very
well. At a certain point, it may be better to use LilyPond book and use
LaTeX's native text functionalities.
And it would be even greater if we could use :
\markup a \footnote { bla bla }
instead of :
\markup \footnote a { bla bla }
I know this last issue is very tricky... And it has a low priority.
True - I'll look into it, though.
And again, great job !
Thanks!
~Mike
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
unbeamed 32nd stem is shortened by 0.25 ss to fit beamed stems better. (issue4243071)
Graham wants us to discuss this, so let's do it :) I think that this is the only reasonable amount by which we can change 32nd stem length (4.25 ss instead of 4.5 ss); any remaining inconsistencies in proof-sheet posted by me (http://www.sendspace.com/file/2mzt4a) should be fixed by tweaking beams (if they are possible to fix at all). But fixing beams is a whole another topic, and a huge one. I'm already in the process of gathering examples for this, but it will take a lot more time. cheers, Janek http://codereview.appspot.com/4243071/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: unbeamed 32nd stem is shortened by 0.25 ss to fit beamed stems better. (issue4243071)
LGTM. Carl http://codereview.appspot.com/4243071/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: unbeamed 32nd stem is shortened by 0.25 ss to fit beamed stems better. (issue4243071)
Also, it's a simple enough change that I don't think any discussion is necessary. We should go ahead and push it. It's just a change of a single constant value. Carl http://codereview.appspot.com/4243071/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: shortened flags affair, part 3 - 32nds stem length
2011/3/9 Graham Percival gra...@percival-music.ca: On 3/8/11, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: i don't see any discussion going on here, so i assume you agree to shortening the 32nd unbeamed stem. I attach the patch. IMO, there are two steps to this type of change: 1. discuss the aesthetics (or beautiful notation). That discussion seems to be over. 2. discuss the technical patch. That discussion may or may not be over, but I haven't seen it officially start. Could you upload this patch to rietveld? Once that's done, if the patch passes the obvious checks, I'll include it in a 48-hour patch countdown. Done. http://codereview.appspot.com/4243071/ Sorry for the extra caution, but I'm not going to push changes to the fonts on my own authority. I want to give plenty of time for people familiar with the topic to object, once it's clear that we have a precise patch on the table rather than a general discussion.. No problem. I thought this patch is so simple (it's only changing one number in define-grobs.scm) that it doesn't need discussing. However, i forgot to modify downstem 32nd flag - it should be a bit shorter too. I'll fix this right now. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: unbeamed 32nd stem is shortened by 0.25 ss to fit beamed stems better. (issue4243071)
New patch handling downstem flag added. http://codereview.appspot.com/4243071/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds automatic numbering to footnotes. (issue4244064)
On 2011/03/09 19:13:20, mike_apollinemike.com wrote: Thanks for the helpful comments! Responses inlined below. Hi, Mike! Part-time patch helper Colin here. Mike, this patch has somehow poisoned the doc build and also the make test functionality, neither of which work since the patch was pushed. Also, I gather this patch is part of your work on issue, so I'll update the issue and set the status to Patch needs work. http://codereview.appspot.com/4244064/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds automatic numbering to footnotes. (issue4244064)
Hi Mike,
I've only given this a quick look so far, but it's looking great. :)
Here are a few thoughts:
The patch doesn't apply without rebasing `paper-defaults-init.ly'.
Does `annotation-whiteout' do anything special? If not, the existing
property `whiteout' should suffice.
`reset-footnotes-on-new-page' appears to be broken:
\paper {
reset-footnotes-on-new-page = ##f
}
\relative c' {
\autoFootnoteGrob #'NoteHead #'(0 . -1) first head
c1
}
\pageBreak
\relative c' {
\autoFootnoteGrob #'NoteHead #'(0 . -1) second head
c1
}
- 1, 1first head
- 1, 2second head
`footnote-auto-numbering.ly' also counts the toplevel markup on the
second page as 5, continuing the marker sequence on the grobs with
2, 3 etc.
The random hash you're creating is quite complicated; would a simple
(gensym footnote) suffice?
If a footnote reaches double digits on a toplevel markup, it messes up
the superscript alignment for all toplevel markup footnotes.
Cheers,
Neil
http://codereview.appspot.com/4244064/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Map voices to channels in MIDI output
On 9 March 2011 00:09, Keith OHara k-ohara5...@oco.net wrote: In 2.13.53, I cannot find a way to make midiInstrument have effect. I can't confirm this; apart from instruments which my MIDI output doesn't seem to support, every instrument I've tried works fine. Can you post a snippet showing the problem? Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond speed. Idea for Schikkers list
2011/3/6 Janek Warchoł lemniskata.bernoull...@gmail.com: Hi, how fast would be LilyPond if we turned off collision detecting, optical spacing, line breaking, beam quanting and sloping, slur shaping, etc etc etc - basically everything except placing symbols on paper in one infinately long system? You can easily try this out yourself. Just set ragged-right=##t and set linelength to 100 meters (or something). You may need to remove some internal sanity checks on distances. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Map voices to channels in MIDI output
Neil Puttock n.puttock at gmail.com writes:
On 9 March 2011 00:09, Keith OHara k-ohara5a5a at oco.net wrote:
In 2.13.53, I cannot find a way to make midiInstrument have effect.
Can you post a snippet showing the problem?
Let's use the manual example I linked earlier, but give names to the Voice
contexts. Obviously this needs further re-arrangement now that midi channels
go with the Voice, but I can't see a way to arrange it so it does work.
\score {
\new Staff {
\key g \major
\time 2/2
\set Staff.midiInstrument = #flute
\set Staff.midiMinimumVolume = #0.7
\set Staff.midiMaximumVolume = #0.9
\new Voice = flauto \relative c''' {
r2 g\mp g fis~
fis4 g8 fis e2~
e4 d8 cis d2
}
}
\new Staff {
\key g \major
\set Staff.midiInstrument = #clarinet
\set Staff.midiMinimumVolume = #0.3
\set Staff.midiMaximumVolume = #0.6
\new Voice = clarinetto \relative c'' {
b1\p a2. b8 a
g2. fis8 e
fis2 r
}
}
%{%}
\layout {}
\midi {
\context {
\Score
tempoWholesPerMinute = #(ly:make-moment 72 2)
}
}
}
The program change commands that set the midiInstrument go to channel 0. The
\xC049 below sets channel 0 to flute, then the other track has x\C047 trying to
set the same channel to clarinet.
030: 6f72 3a20 00ff 011e 474e 5520 4c69 6c79 or: GNU Lily
040: 506f 6e64 2032 2e31 332e 3534 2020 2020 Pond 2.13.54
050: 2020 2020 2020 00ff 5804 0201 1208 00ff..X...
060: 5103 065b 9a00 ff2f 004d 5472 6b00 Q..[.../.MTrk...
070: 7000 ff03 c049 00ff 0405 666c 7574 p..Iflut
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Potential fix for issue 1504. (issue4237057)
http://codereview.appspot.com/4237057/diff/1/lily/beam.cc File lily/beam.cc (right): http://codereview.appspot.com/4237057/diff/1/lily/beam.cc#newcode173 lily/beam.cc:173: span_data.push_back (get_beam_span (orig-broken_intos_[i], commonx)); this looks wrong - different broken pieces cannot ever share a commonx. http://codereview.appspot.com/4237057/diff/1/lily/spanner.cc File lily/spanner.cc (right): http://codereview.appspot.com/4237057/diff/1/lily/spanner.cc#newcode405 lily/spanner.cc:405: Spanner::broken_spanner_index (Spanner const *sp) why not make it a real member funtcion? http://codereview.appspot.com/4237057/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
shortened flags affair, part 5 - length of notes extending far from staff
Hi,
next thing is to decide what the output of { c32 c[ c] c64 c[ c] } should
be.
Currently the stems of unbeamed notes are lenghtened to middle line only
(current output.png).
In my opinion this looks weird, i'd suggest something like suggested
output.png.
However, this is only my personal opinion.
What do engraving books say about it? Or maybe do you recall some examples?
(i suppose randomly searching score databases like imslp.org has a little
chance of success in reasonable time...)
cheers,
Janek
attachment: current output.pngattachment: suggested output.png___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds automatic numbering to footnotes. (issue4244064)
Colin, -Original Message- From: Colin Campbell colinpkcampb...@gmail.com Reply-To: mts...@gmail.com, bordage.bertr...@gmail.com, m...@apollinemike.com, Colin Campbell colinpkcampb...@gmail.com, Lilypond Dev lilypond-devel@gnu.org, re...@codereview.appspotmail.com Date: Wed, 9 Mar 2011 21:14:09 + To: mts...@gmail.com, bordage.bertr...@gmail.com, m...@apollinemike.com Cc: re...@codereview.appspotmail.com, Lilypond Dev lilypond-devel@gnu.org Subject: Re: Adds automatic numbering to footnotes. (issue4244064) On 2011/03/09 19:13:20, mike_apollinemike.com wrote: Thanks for the helpful comments! Responses inlined below. Hi, Mike! Part-time patch helper Colin here. Mike, this patch has somehow poisoned the doc build and also the make test functionality, neither of which work since the patch was pushed. Did you do a new 'make' and then 'make doc'? Used to catch me out every time. Now when I see any .cc I re-run make, touch the notation.tely and then run make doc. Ditto for updated .ly files (although that might be overkill). It worked for me. James ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond speed. Idea for Schikkers list
Ha! -Original Message- From: Han-Wen Nienhuys hanw...@gmail.com Reply-To: han...@xs4all.nl Date: Wed, 9 Mar 2011 19:59:23 -0300 To: Janek Warchoł lemniskata.bernoull...@gmail.com Cc: Lilypond Dev lilypond-devel@gnu.org Subject: Re: LilyPond speed. Idea for Schikkers list 2011/3/6 Janek Warchoł lemniskata.bernoull...@gmail.com: Hi, how fast would be LilyPond if we turned off collision detecting, optical spacing, line breaking, beam quanting and sloping, slur shaping, etc etc etc - basically everything except placing symbols on paper in one infinately long system? You can easily try this out yourself. Just set ragged-right=##t and set linelength to 100 meters (or something). I knew Graham's new paper size was for something! http://article.gmane.org/gmane.comp.gnu.lilypond.devel/34808 That, Jean-Charles, is known in comedy as a 'back reference'! ;) .. And Goodnight! James ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond speed. Idea for Schikkers list
2011/3/9 Han-Wen Nienhuys hanw...@gmail.com 2011/3/6 Janek Warchoł lemniskata.bernoull...@gmail.com: Hi, how fast would be LilyPond if we turned off collision detecting, optical spacing, line breaking, beam quanting and sloping, slur shaping, etc etc etc - basically everything except placing symbols on paper in one infinately long system? You can easily try this out yourself. Just set ragged-right=##t and set linelength to 100 meters (or something). You may need to remove some internal sanity checks on distances. No, that's not what i meant. I want to ignore almost all aspects of engraving (for example calculating beam slopeness), not only line breaking. At first i thought that removing engravers would do the trick, but for example if i remove beam_engraver entirely, i won't get any beams at all. Maybe i should've explained why i ask this question. My idea for shikkers list is this: it would show a user only a rough preview of music, with everything in one infinite system (like scroll view in finale), and laid-out in a not-so-pretty way (for example with slur-accidental collisions and beams that are all flat). It would still be necessary to compile the score in order to see final result, but this rough preview would be easier to work with than pure text mode, at least for users used to GUI. The usability of this idea depends on the answer to this question: how much can we speed up compiling by skipping some calculations that are not totally crucial to displaying the music? If it's bigger than 90%, it may be worth a try. thanks, Janek PS Actually when i tried what you suggested compiling was twice longer than normally. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond speed. Idea for Schikkers list
On Thu, Mar 10, 2011 at 12:42:11AM +0100, Janek Warchoł wrote: 2011/3/9 Han-Wen Nienhuys hanw...@gmail.com You can easily try this out yourself. Just set ragged-right=##t and set linelength to 100 meters (or something). You may need to remove some internal sanity checks on distances. Maybe i should've explained why i ask this question. My idea for shikkers list is this: it would show a user only a rough preview of music, This has been proposed a few times in the past, but nobody has yet seriously investigated it. I think the first step would be to do exactly what Han-Wen suggests -- hey, it'll only take 5 minutes! (assuming that you choose a very large score to test with?) If you see a significant increase, then clearly it's worth investigating more. But that other investigation will probably require modifying the C++ code. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds automatic numbering to footnotes. (issue4244064)
On 11-03-09 04:21 PM, James Lowe wrote: Colin, -Original Message- From: Colin Campbellcolinpkcampb...@gmail.com Reply-To:mts...@gmail.com,bordage.bertr...@gmail.com, m...@apollinemike.com, Colin Campbellcolinpkcampb...@gmail.com, Lilypond Devlilypond-devel@gnu.org,re...@codereview.appspotmail.com Date: Wed, 9 Mar 2011 21:14:09 + To:mts...@gmail.com,bordage.bertr...@gmail.com, m...@apollinemike.com Cc:re...@codereview.appspotmail.com, Lilypond Dev lilypond-devel@gnu.org Subject: Re: Adds automatic numbering to footnotes. (issue4244064) On 2011/03/09 19:13:20, mike_apollinemike.com wrote: Thanks for the helpful comments! Responses inlined below. Hi, Mike! Part-time patch helper Colin here. Mike, this patch has somehow poisoned the doc build and also the make test functionality, neither of which work since the patch was pushed. Did you do a new 'make' and then 'make doc'? Used to catch me out every time. Now when I see any .cc I re-run make, touch the notation.tely and then run make doc. Ditto for updated .ly files (although that might be overkill). It worked for me. James I deleted my /build, did git pull -r, cd /build, ran make. So far so good, so I tried make doc, which ABENDed. Tried make test, also ABEND. Colin -- The test of our progress is not whether we add more to the abundance of those who have much, it is whether we provide enough for those who have too little. -Franklin D. Roosevelt, 32nd US President (1882-1945) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: shortened flags affair, part 5 - length of notes extending far from staff
next thing is to decide what the output of { c32 c[ c] c64 c[ c] }
should be. Currently the stems of unbeamed notes are lenghtened to
middle line only (current output.png). In my opinion this looks
weird, i'd suggest something like suggested output.png.
Again, I think that the stems of the beamed notes are too long; in
both cases, I would move the beams down one staff space...
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds automatic numbering to footnotes. (issue4244064)
On Mar 9, 2011, at 10:14 PM, colinpkcampb...@gmail.com wrote: On 2011/03/09 19:13:20, mike_apollinemike.com wrote: Thanks for the helpful comments! Responses inlined below. Hi, Mike! Part-time patch helper Colin here. Mike, this patch has somehow poisoned the doc build and also the make test functionality, neither of which work since the patch was pushed. Also, I gather this patch is part of your work on issue, so I'll update the issue and set the status to Patch needs work. Hey Collin, When you say pushed, do you mean to say that the auto-numbering patch was pushed to the master branch? I don't believe it was...I am looking at my current master and don't see it, but let me know if I'm wrong! Also, to respond to your other e-mail, all of my regtests work just fine: symbol-footnotes is defined in scm/output-lib and gets the desired result. Could you try it again and let me know if that works out? Thanks for your help! Cheers, Mike ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
