Re: Cleaning Feta flags code (issue4236043)
Hearing no objections to the contrary, let's move forward. Janek, could you send me a patch for pushing? http://codereview.appspot.com/4236043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES: 48-hour notice for segfault from orphaned-lines code
Thurs 12 noon. This is the last release-Critical issue. Fix segfault from orphaned-lines code http://codereview.appspot.com/4253061/ Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Scheme Tweak Help: Highlighting a Staff in a StaffGroup
I'd like to write a custom Scheme /tweak that will allow me to set the
background color of a staff within a staff group.
I am printing out a four-part SATB arrangement, and would like to be able to
highlight the parts individually (to simulate what singers often do-- using
a yellow highlighter to highlight their part within the score).
I did find the following tweak:
% move to right position
-\tweak #'extra-offset #'(-126 . -5.5)
% place in bottom layer
-\tweak #'layer #-1
^\markup {
% specify color
\with-color #(rgb-color 1 1 0)
% specify size
\filled-box #'(0 . 33) #'(0 . 6) #0
}
Unfortunately, the method above isn't really independent of the layout, so
if you manage to get the highlight positioned correctly, and then you change
the margins, the highlighting will be off.
If anyone can help me write a Scheme tweak for this, I'd appreciate it. Even
pointing me to a tweak that does some of the same things would be helpful
(i.e. tweaking output across an entire Staff in a StaffGroup, etc).
Thanks,
- Eugene
--
View this message in context:
http://old.nabble.com/Scheme-Tweak-Help%3A-Highlighting-a-Staff-in-a-StaffGroup-tp31091731p31091731.html
Sent from the Gnu - Lilypond - Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cleaning Feta flags code (issue4236043)
Here you are. 2011/3/8 percival.music...@gmail.com Hearing no objections to the contrary, let's move forward. Janek, could you send me a patch for pushing? http://codereview.appspot.com/4236043/ From 36fc7746295b387e297ce0e4999a166eac836307 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Janek=20Warcho=C5=82?= lemniskata.bernoulli...@gmail.com Date: Fri, 25 Feb 2011 11:16:33 +0100 Subject: [PATCH 1/2] Cleaning Feta flags code This patch makes flags code more uniform and easier to maintain. There is no actual change to the font itself, only to the way it is coded. --- mf/feta-flags.mf | 268 -- 1 files changed, 141 insertions(+), 127 deletions(-) diff --git a/mf/feta-flags.mf b/mf/feta-flags.mf index 9cf4903..521ecb8 100644 --- a/mf/feta-flags.mf +++ b/mf/feta-flags.mf @@ -135,24 +135,31 @@ enddef; fet_beginchar (8th Flag (up), u3); save flare, hip_depth_ratio, hip_width, foot_depth, foot_width_ratio; + save flagspace, total_depth, flag_count; + flag_count = 1; + total_depth# = 3 staff_space# - blot_diameter# / 2; flare = staff_space; + flagspace# = staff_space#; hip_depth_ratio = .72; - foot_width_ratio = .8; hip_width# = upflag_width# - hip_thickness# / 2; - foot_depth# = 3 staff_space# - blot_diameter# / 2; + foot_width_ratio = .8; + + (flag_count - 1) * flagspace# + foot_depth# = total_depth#; + define_pixels (hip_width, foot_depth); + define_whole_vertical_pixels (flagspace); - set_char_box (0, - hip_width# + stemthickness# / 2 + right_upflag_space#, + set_char_box (0, hip_width# + stemthickness# / 2 + right_upflag_space#, foot_depth# + foot_thickness# / 2, stemthickness# / 2); - draw_flag ((0,0), flare, (hip_width, foot_depth), + draw_flag ((0, -(flag_count - 1) * flagspace), + flare, (hip_width, foot_depth), hip_depth_ratio, foot_width_ratio, hip_thickness, foot_thickness, 1); - draw_square_block ((-0.5 stemthickness_rounded, -staff_space_rounded), - (0, 0)); + draw_square_block ((-0.5 stemthickness_rounded, 0), + (0, (-flag_count * staff_space_rounded))); fet_endchar; @@ -160,22 +167,24 @@ fet_beginchar (16th Flag (up), u4); save flare, hip_depth_ratio, hip_width, foot_depth, foot_width_ratio; save flagspace, total_depth, flag_count; - total_depth# = 3.5 staff_space# - blot_diameter# / 2; flag_count = 2; + total_depth# = 3.5 staff_space# - blot_diameter# / 2; flare = .85 staff_space; flagspace# = .85 staff_space#; hip_depth_ratio = .72; hip_width# = upflag_width# - hip_thickness# / 2; - flagspace# + foot_depth# = total_depth#; foot_width_ratio = .8; + + (flag_count - 1) * flagspace# + foot_depth# = total_depth#; + define_pixels (hip_width, foot_depth); define_whole_vertical_pixels (flagspace); - set_char_box (0, - hip_width# + stemthickness# / 2 + right_upflag_space#, + set_char_box (0, hip_width# + stemthickness# / 2 + right_upflag_space#, total_depth# + foot_thickness# / 2, stemthickness# / 2); - draw_flag ((0, -flagspace), flare, (hip_width, foot_depth), + draw_flag ((0, -(flag_count - 1) * flagspace), + flare, (hip_width, foot_depth), hip_depth_ratio, foot_width_ratio, hip_thickness, foot_thickness, 1); @@ -183,7 +192,7 @@ fet_beginchar (16th Flag (up), u4); hip_thickness, foot_thickness); draw_square_block ((-0.5 stemthickness_rounded, 0), - (0, -2 staff_space_rounded)); + (0, (-flag_count * staff_space_rounded))); fet_endchar; @@ -207,7 +216,8 @@ fet_beginchar (32nd Flag (up), u5); set_char_box (0, hip_width# + right_upflag_space#, total_depth# + foot_thickness# / 2, stemthickness# / 2); - draw_flag ((0, -2 flagspace), flare, (hip_width, foot_depth), + draw_flag ((0, -(flag_count - 1) * flagspace), + flare, (hip_width, foot_depth), hip_depth_ratio, foot_width_ratio, hip_thickness, foot_thickness, 1); @@ -217,7 +227,7 @@ fet_beginchar (32nd Flag (up), u5); hip_thickness, foot_thickness); draw_square_block ((-0.5 stemthickness_rounded, 0), - (0, -3 staff_space_rounded)); + (0, (-flag_count * staff_space_rounded))); fet_endchar; @@ -226,11 +236,11 @@ fet_beginchar (64th Flag (up), u6); save flagspace, total_depth, flag_count; flag_count = 4; + total_depth# = 5.25 staff_space#; flare = .85 staff_space; flagspace# = .9 staff_space#; hip_depth_ratio = .72; hip_width# = upflag_width# - hip_thickness# / 2; - total_depth# = 5.25 staff_space#; foot_width_ratio = .8; (flag_count - 1) * flagspace# + foot_depth# = total_depth#; @@ -241,8 +251,8 @@ fet_beginchar (64th Flag (up), u6); set_char_box (0, hip_width# + right_upflag_space#, total_depth# + foot_thickness# / 2, stemthickness# / 2); - draw_flag ((0, -(flag_count - 1) * flagspace), flare, - (hip_width, foot_depth), + draw_flag ((0, -(flag_count - 1) * flagspace), + flare, (hip_width, foot_depth), hip_depth_ratio,
Re: shortened flags affair, part 3 - 32nds stem length
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 From 7e285a6048ad269a203a7a4759d7c17b9e8ff2b2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Janek=20Warcho=C5=82?= lemniskata.bernoulli...@gmail.com Date: Tue, 8 Mar 2011 16:37:28 +0100 Subject: [PATCH] unbeamed 32nd stem is shortened by 0.25 ss to fit beamed stems better. as discussed in http://lists.gnu.org/archive/html/lilypond-devel/2011-03/msg00091.html --- scm/define-grobs.scm |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/scm/define-grobs.scm b/scm/define-grobs.scm index ac75852..74d5a40 100644 --- a/scm/define-grobs.scm +++ b/scm/define-grobs.scm @@ -1858,7 +1858,7 @@ . ( ;; 3.5 (or 3 measured from note head) is standard length ;; 32nd, 64th, 128th flagged stems should be longer - (lengths . (3.5 3.5 3.5 4.5 5.0 6.0)) + (lengths . (3.5 3.5 3.5 4.25 5.0 6.0)) ;; FIXME. 3.5 yields too long beams (according to Ross and ;; looking at Baerenreiter examples) for a number of common -- 1.7.0.4
Re: shortened flags affair, part 3 - 32nds stem length
Janek Warchoł wrote Tuesday, March 08, 2011 3:42 PM i don't see any discussion going on here, so i assume you agree to shortening the 32nd unbeamed stem. I attach the patch. I'm happy with it. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: left-aligning grobs to other grobs
David -Original Message- From: David Nalesnik dnale...@umail.iu.edu Date: Tue, 8 Mar 2011 11:44:44 -0600 To: LilyPond User lilypond-u...@gnu.org Subject: left-aligning grobs to other grobs 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! I think this is better asked on the lilypond-dev list as well. So while I don't have an answer (I am not a programmer) I have cc;d that list in case someone is reading that list and not the user lists. James ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
adding \header { } affects line breaks
Hello,
Here is my tiny example
--
\version 2.13.51
\header {
title = S C H E R Z O
}
\relative c'' {
\time 3/8
\compressFullBarRests
R1*19*3/8 \break| cis4. | d8 r r | R1*2*3/8 | cis4. | d8 r r | \break
R1*20*3/8
}
---
What I'd like to do is have one line of the 19 bar rest, the 4 bars of
music underneath and then 20 bars of rest on the next line
However for a reason I cannot fathom the 4 lines of music in between the
two rests split over two lines.
Now, if I remove the \header { } statement the line breaks as expected.
If I remove all entries from \header { } then the breaks are as I like, if
I add *any* header (arranger, instrument, tagline etc) then the breaks are
wrong.
What is the \header { } doing to the spacing and how can I prevent it - I
have tried using a fixed width with a \paper but this does nothing.
Thanks
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme Tweak Help: Highlighting a Staff in a StaffGroup
On 7 March 2011 21:11, emw ewal...@weisswalden.com wrote:
If anyone can help me write a Scheme tweak for this, I'd appreciate it. Even
pointing me to a tweak that does some of the same things would be helpful
(i.e. tweaking output across an entire Staff in a StaffGroup, etc).
Each Staff context contains a grouping object (a VerticalAxisGroup)
which carries all the elements on the stave. You can extract the
bounding box for this and print a solid coloured box as its stencil
(which is usually unset):
\version 2.12.3
highlight = {
\override Staff.VerticalAxisGroup #'layer = #-1
\override Staff.VerticalAxisGroup #'stencil =
#(lambda (grob)
(let ((x-ext (ly:grob-property grob 'X-extent))
(y-ext (ly:grob-property grob 'Y-extent)))
(grob-interpret-markup grob
(markup #:with-color yellow
#:filled-box x-ext y-ext 0
}
\new StaffGroup
\new Staff \relative c' {
c1
}
\new Staff \relative c' {
\highlight
c1
}
If you're running 2.13, defining \highlight as a context modification
makes it easier to add to other contexts such as Lyrics:
\version 2.13.53
highlight = \with {
\override VerticalAxisGroup #'layer = #-1
\override VerticalAxisGroup #'stencil =
#(lambda (grob)
(let ((x-ext (ly:grob-property grob 'X-extent))
(y-ext (ly:grob-property grob 'Y-extent)))
(grob-interpret-markup grob
(markup #:with-color yellow
#:filled-box x-ext y-ext 0
}
\new StaffGroup
\new Staff \new Voice = melody \relative c' {
c1
}
\new Lyrics \highlight \lyricsto melody {
foo
}
\new Staff \relative c' {
c1
}
\new Staff \highlight \relative c' {
c1
}
Cheers,
Neil
attachment: highlight.png___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Map voices to channels in MIDI output
Is there more to this change, started in commit e5380f2, on the way? In 2.13.53, I cannot find a way to make midiInstrument have effect. There is also the problem reported on -bugs http://lists.gnu.org/archive/html/bug-lilypond/2011-03/msg00152.html Maybe the previous workaround to have one channel per voice could be a model ? http://lilypond.org/doc/v2.13/Documentation/notation/creating-midi-files That workaround did allow changing midiInstrument and midiVolume as in http://lilypond.org/doc/v2.13/Documentation/notation/controlling-midi-dynamics if we set those properties in Voice instead of Staff. - Keith ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: adding \header {} affects line breaks
James Lowe James.Lowe at datacore.com writes:
What is the \header { } doing to the spacing and how can I prevent it - I
have tried using a fixed width with a \paper but this does nothing.
It seems that any markup on the page causes version 2.13.50+ to prefer
stretching the lines, if one line was forced to be stretched.
\version 2.13.51
\score {\relative c'' {
c1 c \break
d1 d d d d d d d
} }
\markup hello
If the first line has some more c1s added, or if the markup is removed,
then the Ds all go on one line. page-spacing-weight didn't seem to help.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: adding \header {} affects line breaks after 2.13.50
Keith,
-Original Message-
From: Keith OHara k-ohara5...@oco.net
Date: Wed, 9 Mar 2011 00:44:51 +
To: Lilypond Dev lilypond-devel@gnu.org
Subject: Re: adding \header {} affects line breaks
James Lowe James.Lowe at datacore.com writes:
What is the \header { } doing to the spacing and how can I prevent it -
I
have tried using a fixed width with a \paper but this does nothing.
It seems that any markup on the page causes version 2.13.50+ to prefer
stretching the lines, if one line was forced to be stretched.
\version 2.13.51
\score {\relative c'' {
c1 c \break
d1 d d d d d d d
} }
\markup hello
If the first line has some more c1s added, or if the markup is removed,
then the Ds all go on one line. page-spacing-weight didn't seem to help.
Thanks for verifying, I've restored 2.13.40 (as that was the last version
I had installd before .51) and you are correct, 2.13.40 doesn't show this
behaviour. I am guessing this is a 'regression' or at the very least a
'bug'?
I'll post this on bug with some PDF examples
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Using #(define fonts) gives me an ill-looking feta font
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))) -- Gives me 'ugly' instances of the feta font. See attached pngs (left side is without this construct) As you can see the 'church rests' don't touch the staff lines and the heads and stems are 'spindly'. I'd like to define the 3 font types instead of having to use overrides, but the 'myStaffSize' is something I just copied verbatim from the NR. I don't actually know what it does but I cannot just remove it as I get compile errors. My files use a #(set-global-staff-size 24) so I thought it might be related, but changing the value either in this global-staff-size or in the myStaffSize does nothing. I wonder if anyone can give me some advice so I can get the glyphs correctly formatted again without having to go through all 24 individual scores and set 'abs-font' commands everywhere? Thanks as always for your time. James attachment: notes.pngattachment: ChurchRests.png___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
