Re: ambitus: special handling of small ambits' lines (issue4609041)
Hi Janek, I'd be much happier with this change if you used a callback for 'gap instead of inserting new code into the print function. That way it's easy for users to override the default behaviour without adding more properties. Cheers, Neil http://codereview.appspot.com/4609041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
On Jun 21, 2011, at 3:31 PM, Janek Warchoł wrote: > 2011/6/21 m...@apollinemike.com : >> What I meant is that every time you use a magic number (i.e. 0.35), >> consider making it user-tweakable unless you are absolutely sure >> that there is no utility in changing that number. > > Ah, you meant this! :) > well, i think that 0.35 in (ly:grob-property grob 'gap 0.35) means "if > you have trouble reading gap property, use 0.35", so it's only kind of > default value. > As for other numbers, i'm sure that making them user-tweakable will be > overkill. They simply are coefficients in a function that does a very > nitpicky tweak; the function (as a whole) can be controlled by > gap-stretchability and i'm sure it's enough. > Personally i suppose that noone in the world - except me - will ever > care about gap-stretchability value, leave alone the coefficients in > the funciton :) Sorry sorry - I mis-mis-spoke (I should have read my previous post). What I meant is that these values could be wrapped up into a details property. The argument that user-tweakability is overkill isn't necessarily a bad thing - check out the `details' property for the Slur and Beam grobs. By creating a similar details list, it'd be more LilyPond-esque, which makes the code easier to read (and, on the off chance that someone actually wants to modify this (which is admittedly rare), they'll be able to w/o having to change the source). Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
2011/6/21 m...@apollinemike.com : > What I meant is that every time you use a magic number (i.e. 0.35), > consider making it user-tweakable unless you are absolutely sure > that there is no utility in changing that number. Ah, you meant this! :) well, i think that 0.35 in (ly:grob-property grob 'gap 0.35) means "if you have trouble reading gap property, use 0.35", so it's only kind of default value. As for other numbers, i'm sure that making them user-tweakable will be overkill. They simply are coefficients in a function that does a very nitpicky tweak; the function (as a whole) can be controlled by gap-stretchability and i'm sure it's enough. Personally i suppose that noone in the world - except me - will ever care about gap-stretchability value, leave alone the coefficients in the funciton :) thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
- Original Message - From: "Janek Warchoł" Have you zoomed the output to check it? I suppose its a rasterization problem; a lot of things seem to be wrong when output is watched unzoomed on a computer screen (for example one stem in the attachment looks two times thicker than the other, while in fact it's exactly the same). Don't forget that it's important to do this with the PDF output. The way PDF viewers and the PNG generator convert the PDF to images does often cause the apparent oddities you're talking about. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
On Jun 21, 2011, at 3:04 PM, lemniskata.bernoull...@gmail.com wrote: > > http://codereview.appspot.com/4609041/diff/12001/scm/define-grobs.scm > File scm/define-grobs.scm (right): > > http://codereview.appspot.com/4609041/diff/12001/scm/define-grobs.scm#newcode141 > scm/define-grobs.scm:141: (woot . 1) > On 2011/06/17 07:18:49, MikeSol wrote: >> This seems like 1337 $p34k - >> I have never heard woot in any other context. >> Perhaps change to something more descriptive? > > Of course! > I had no idea for the name and decided to use a placeholder and ask you > instead of wasting 15 minutes on something so simple (i was quite tired > when i wrote this code). > > http://codereview.appspot.com/4609041/diff/12001/scm/output-lib.scm > File scm/output-lib.scm (right): > > http://codereview.appspot.com/4609041/diff/12001/scm/output-lib.scm#newcode944 > scm/output-lib.scm:944: (linear-gap (+ (max gap-property 0.3) -0.45 > On 2011/06/17 07:18:49, MikeSol wrote: >> Indentation: the -0.45 should be on the next line & lined up with the >> left-parenthesis of (max. > > Done. > > http://codereview.appspot.com/4609041/diff/12001/scm/output-lib.scm#newcode950 > scm/output-lib.scm:950: (unwooted (max (min calculated-gap gap-property) > (/ gap-property 4.5))) > On 2011/06/17 07:18:49, MikeSol wrote: >> 80 column max > > Done. > > http://codereview.appspot.com/4609041/diff/12001/scm/output-lib.scm#newcode951 > scm/output-lib.scm:951: (gap (+ (* unwooted woot) (* gap-property (- 1 > woot > On 2011/06/17 07:18:49, MikeSol wrote: >> This codes a lot of properties. I'm fine with the code (though I'd > need to see >> a regtest). Can you try using a "details" property (like for the Beam > grob) >> that stores all of these values? > > Umm, I don't want to define properties like linear-gap, calculated-gap > etc. They are just temporary variables so that the code calculating > final gap is easier to read. Had i not used them, i would have to write > everything explicitely like this (with better indentation perhaps): > > (gap > (+ >(* > (max >(min > (if >(< > (+ >(max (ly:grob-property grob 'gap 0.35) 0.3) >-0.45 >(* > 0.2 > (- >(interval-start (ly:grob-extent head-up common Y)) >(interval-end (ly:grob-extent head-down common > Y) > 0.2) >(+ > (max (ly:grob-property grob 'gap 0.35) 0.3) > -0.45 > (* >0.2 >(- > (interval-start (ly:grob-extent head-up common Y)) > (interval-end (ly:grob-extent head-down common Y) >(+ > (* >(floor > (/ >(- > (+ >(max (ly:grob-property grob 'gap 0.35) 0.3) >-0.45 >(* > 0.2 > (- >(interval-start (ly:grob-extent head-up > common Y)) >(interval-end (ly:grob-extent head-down > common Y) > 0.2) >0.25)) >0.25) > 0.2)) > (ly:grob-property grob 'gap 0.35)) >(/ (ly:grob-property grob 'gap 0.35) 4.5)) > (ly:grob-property grob 'woot 1)) >(* (ly:grob-property grob 'gap 0.35) > (- 1 (ly:grob-property grob 'woot 1) > > looks suicidal... > When i noticed that point-max and point-min don't seem to be any > properties but only a sort of temporary variables, i used this idea for > my piece of code. Maybe i didn't understand how this works... What I meant is that every time you use a magic number (i.e. 0.35), consider making it user-tweakable unless you are absolutely sure that there is no utility in changing that number. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
Hi Karin,
i'm back from my short vacation.
2011/6/17 :
> the description explains clearly how to use the parameters gap and woot.
> So, it is a good starting point to understanding the scheme code that
> follows.
Good!
>> Yes, the quanting stays the same.
>
> I couldn't find the verb "to quant" in a dictionary. Is it short for
> "to quantize"?
Yes. It's used a lot in beaming code.
> If so, it might be clearer to change the description in output-lib.scm.
Good point, it's better to avoid abbreviations.
> Finally, I tested the gap adjustment for several intervals. For a fifth:
>
> \new Staff \with { \consists Ambitus_engraver } {
> c' g'
> }
>
> the bottom of the ambitus line is very close to the lower note in the
> default case. Is this on purpose? I would expect the ambitus line to be
> more or less centered between note heads.
Have you zoomed the output to check it? I suppose its a rasterization
problem; a lot of things seem to be wrong when output is watched
unzoomed on a computer screen (for example one stem in the attachment
looks two times thicker than the other, while in fact it's exactly the
same).
Thanks for review!
Janek
<>___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
2011/6/17 James Lowe : > Hello > > What about 'glyph-space-distance-within-staff-affinity-thing'? cheek> > Isn't that more in keeping with the new spacing terminology. Huh? I don't understand. The <> tags don't match! :P ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
http://codereview.appspot.com/4609041/diff/12001/scm/define-grobs.scm File scm/define-grobs.scm (right): http://codereview.appspot.com/4609041/diff/12001/scm/define-grobs.scm#newcode141 scm/define-grobs.scm:141: (woot . 1) On 2011/06/17 07:18:49, MikeSol wrote: This seems like 1337 $p34k - I have never heard woot in any other context. Perhaps change to something more descriptive? Of course! I had no idea for the name and decided to use a placeholder and ask you instead of wasting 15 minutes on something so simple (i was quite tired when i wrote this code). http://codereview.appspot.com/4609041/diff/12001/scm/output-lib.scm File scm/output-lib.scm (right): http://codereview.appspot.com/4609041/diff/12001/scm/output-lib.scm#newcode944 scm/output-lib.scm:944: (linear-gap (+ (max gap-property 0.3) -0.45 On 2011/06/17 07:18:49, MikeSol wrote: Indentation: the -0.45 should be on the next line & lined up with the left-parenthesis of (max. Done. http://codereview.appspot.com/4609041/diff/12001/scm/output-lib.scm#newcode950 scm/output-lib.scm:950: (unwooted (max (min calculated-gap gap-property) (/ gap-property 4.5))) On 2011/06/17 07:18:49, MikeSol wrote: 80 column max Done. http://codereview.appspot.com/4609041/diff/12001/scm/output-lib.scm#newcode951 scm/output-lib.scm:951: (gap (+ (* unwooted woot) (* gap-property (- 1 woot On 2011/06/17 07:18:49, MikeSol wrote: This codes a lot of properties. I'm fine with the code (though I'd need to see a regtest). Can you try using a "details" property (like for the Beam grob) that stores all of these values? Umm, I don't want to define properties like linear-gap, calculated-gap etc. They are just temporary variables so that the code calculating final gap is easier to read. Had i not used them, i would have to write everything explicitely like this (with better indentation perhaps): (gap (+ (* (max (min (if (< (+ (max (ly:grob-property grob 'gap 0.35) 0.3) -0.45 (* 0.2 (- (interval-start (ly:grob-extent head-up common Y)) (interval-end (ly:grob-extent head-down common Y) 0.2) (+ (max (ly:grob-property grob 'gap 0.35) 0.3) -0.45 (* 0.2 (- (interval-start (ly:grob-extent head-up common Y)) (interval-end (ly:grob-extent head-down common Y) (+ (* (floor (/ (- (+ (max (ly:grob-property grob 'gap 0.35) 0.3) -0.45 (* 0.2 (- (interval-start (ly:grob-extent head-up common Y)) (interval-end (ly:grob-extent head-down common Y) 0.2) 0.25)) 0.25) 0.2)) (ly:grob-property grob 'gap 0.35)) (/ (ly:grob-property grob 'gap 0.35) 4.5)) (ly:grob-property grob 'woot 1)) (* (ly:grob-property grob 'gap 0.35) (- 1 (ly:grob-property grob 'woot 1) looks suicidal... When i noticed that point-max and point-min don't seem to be any properties but only a sort of temporary variables, i used this idea for my piece of code. Maybe i didn't understand how this works... http://codereview.appspot.com/4609041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: ambitus: special handling of small ambits' lines (issue4609041)
Hello From: lilypond-devel-bounces+james.lowe=datacore@gnu.org [lilypond-devel-bounces+james.lowe=datacore@gnu.org] on behalf of Carl Sorensen [c_soren...@byu.edu] Sent: 17 June 2011 00:25 To: lemniskata.bernoull...@gmail.com; tdanielsmu...@googlemail.com; mts...@gmail.com; t.dani...@treda.co.uk; mikesubel...@otherinbox.com Cc: re...@codereview.appspotmail.com; lilypond-devel@gnu.org Subject: Re: ambitus: special handling of small ambits' lines (issue4609041) Thanks for the ideas, Karin. They triggered another one for me. Can we use similar concepts to vertical spacing variables and call it "gap-stretchability"? -- Yuk! What about 'glyph-space-distance-within-staff-affinity-thing'? Isn't that more in keeping with the new spacing terminology. ;) James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
Good work! A few comments below. http://codereview.appspot.com/4609041/diff/12001/scm/define-grobs.scm File scm/define-grobs.scm (right): http://codereview.appspot.com/4609041/diff/12001/scm/define-grobs.scm#newcode141 scm/define-grobs.scm:141: (woot . 1) This seems like 1337 $p34k - I have never heard woot in any other context. Perhaps change to something more descriptive? http://codereview.appspot.com/4609041/diff/12001/scm/output-lib.scm File scm/output-lib.scm (right): http://codereview.appspot.com/4609041/diff/12001/scm/output-lib.scm#newcode944 scm/output-lib.scm:944: (linear-gap (+ (max gap-property 0.3) -0.45 Indentation: the -0.45 should be on the next line & lined up with the left-parenthesis of (max. http://codereview.appspot.com/4609041/diff/12001/scm/output-lib.scm#newcode950 scm/output-lib.scm:950: (unwooted (max (min calculated-gap gap-property) (/ gap-property 4.5))) 80 column max http://codereview.appspot.com/4609041/diff/12001/scm/output-lib.scm#newcode951 scm/output-lib.scm:951: (gap (+ (* unwooted woot) (* gap-property (- 1 woot This codes a lot of properties. I'm fine with the code (though I'd need to see a regtest). Can you try using a "details" property (like for the Beam grob) that stores all of these values? http://codereview.appspot.com/4609041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
On 6/16/11 4:53 PM, "karin.hoeth...@googlemail.com" wrote: > Hi Janek, > > the description explains clearly how to use the parameters gap and woot. > So, it is a good starting point to understanding the scheme code that > follows. > >> I added a parameter which controlls this, but no reasonable name for > it >> (and for some intermediate stages in the code) comes to my mind. >> Any suggestions to what should i change "woot" and "unwooted"? > > What about "gap-adjustment-strength" or "gap-optimization-strength"? > - "gap" should be contained in the name, since that is the quantity > changed by woot > - "adjustment" because the gap is optimized > - "strength", because the value ranges between 0 and 1 (as opposed to > boolean) Thanks for the ideas, Karin. They triggered another one for me. Can we use similar concepts to vertical spacing variables and call it "gap-stretchability"? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
Hi Janek,
the description explains clearly how to use the parameters gap and woot.
So, it is a good starting point to understanding the scheme code that
follows.
I added a parameter which controlls this, but no reasonable name for
it
(and for some intermediate stages in the code) comes to my mind.
Any suggestions to what should i change "woot" and "unwooted"?
What about "gap-adjustment-strength" or "gap-optimization-strength"?
- "gap" should be contained in the name, since that is the quantity
changed by woot
- "adjustment" because the gap is optimized
- "strength", because the value ranges between 0 and 1 (as opposed to
boolean)
Yes, the quanting stays the same.
I couldn't find the verb "to quant" in a dictionary. Is it short for
"to quantize"? If so, it might be clearer to change the description in
output-lib.scm.
Finally, I tested the gap adjustment for several intervals. For a fifth:
\new Staff \with { \consists Ambitus_engraver } {
c' g'
}
the bottom of the ambitus line is very close to the lower note in the
default case. Is this on purpose? I would expect the ambitus line to be
more or less centered between note heads.
hope this helps,
Karin
http://codereview.appspot.com/4609041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
2011/6/13 Trevor Daniels : Janek Warchoł wrote Monday, June 13, 2011 2:51 PM 2011/6/13 : a) It would be better to honour the value of 'gap if this is set by the user, rather than change a specifically requested gap value. My rationale is that it wouldn't make sense to set a big gap and really want to have it applied to all ambituses. Your algorithm is fine as the default behaviour, but it does remove the ability for a user to precisely set the gap he wants by setting 'gap, for whatever reason. This seems counter to Lily's flexible user control, but I don't feel too strongly about it. Ok, let's give the user precise control. I added a parameter which controlls this, but no reasonable name for it (and for some intermediate stages in the code) comes to my mind. Any suggestions to what should i change "woot" and "unwooted"? Also, adding a new property means it has to be written somewhere - i only found define-grobs.scm, but this is not enough: i get the following warning when i compile warning: cannot find property type-check for `woot' (backend-type?). perhaps a typing error? warning: doing assignment anyway Where else should i include it? I tried searching for "AmbitusLine", but the only files i got (besides docs) were the two that i have. Ofc i'm aware that this [quanting] is perhaps as nitpicky as it can go :D OK. It is! :) Does it scale correctly with large and small values of global staff-size? Yes, the quanting stays the same. cheers, Janek http://codereview.appspot.com/4609041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
Janek Warchoł wrote Monday, June 13, 2011 2:51 PM
2011/6/13 :
a) It would be better to honour the value of 'gap if this
is set by the user, rather than change a specifically
requested gap value.
My rationale is that it wouldn't make sense to set a big gap and
really want to have it applied to all ambituses. Consider the
following:
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.7
c' g'
}
...
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.7
a a''
}
While gap=0.7 works fine for big ambituses (one can easily imagine
that a user may wish such a value), the ambitus of sixth looks
ridiculous without any line inside. I suppose that if someone
would
like that "look", he would probably switch the line off entirely.
And for small gap the effect is almost unnoticeable.
Your algorithm is fine as the default behaviour, but it does remove
the
ability for a user to precisely set the gap he wants by setting
'gap,
for whatever reason. This seems counter to Lily's flexible user
control,
but I don't feel too strongly about it. If this is implemented the
description
of 'gap will have to be changed to explain this.
b) I don't understand why quanting is desired. An ambitus
doesn't align with anything. What is your reason?
I thought that it's best if ambitus line eihter ends precisely
inside
staff line, or protrudes from it distinctly. In other words, i
judged
that
\new Staff \with { \consists "Ambitus_engraver" }
{ \override Staff.AmbitusLine #'gap = #0.3 c' b' }
doesn't look nice.
Ofc i'm aware that this is perhaps as nitpicky as it can go :D
OK. It is! :) Does it scale correctly with large and small values
of
global staff-size?
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
2011/6/13 :
> Thanks - much clearer!
>
> Two points:
>
> a) It would be better to honour the value of 'gap if this
> is set by the user, rather than change a specifically
> requested gap value.
My rationale is that it wouldn't make sense to set a big gap and
really want to have it applied to all ambituses. Consider the
following:
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.7
c' g'
}
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.7
c' a'
}
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.7
c' b'
}
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.7
c' c''
}
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.7
c' e''
}
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.7
a a''
}
While gap=0.7 works fine for big ambituses (one can easily imagine
that a user may wish such a value), the ambitus of sixth looks
ridiculous without any line inside. I suppose that if someone would
like that "look", he would probably switch the line off entirely.
And for small gap the effect is almost unnoticeable.
> b) I don't understand why quanting is desired. An ambitus
> doesn't align with anything. What is your reason?
I thought that it's best if ambitus line eihter ends precisely inside
staff line, or protrudes from it distinctly. In other words, i judged
that
\new Staff \with { \consists "Ambitus_engraver" }
{ \override Staff.AmbitusLine #'gap = #0.3 c' b' }
doesn't look nice.
Ofc i'm aware that this is perhaps as nitpicky as it can go :D
Thanks,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
Thanks - much clearer! Two points: a) It would be better to honour the value of 'gap if this is set by the user, rather than change a specifically requested gap value. b) I don't understand why quanting is desired. An ambitus doesn't align with anything. What is your reason? http://codereview.appspot.com/4609041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
On 2011/06/13 08:01:22, Trevor Daniels wrote: The interpersed comments make it very difficult to read the code. Could you place an abridged summary at the top instead? Done. I write a lot of comments so that rookies like me would be able to understand the code in finite time, if they happen to work on this in the future ;) http://codereview.appspot.com/4609041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
The interpersed comments make it very difficult to read the code. Could you place an abridged summary at the top instead? http://codereview.appspot.com/4609041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ambitus: special handling of small ambits' lines (issue4609041)
Oops, i added wrong Mike...
Here is the code i used for testing; i attach a pdf compiled with my fix:
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.45
c' f'
}
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.45
c' g'
}
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.45
c' a'
}
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.45
c' b'
}
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.45
c' c''
}
\new Staff \with { \consists Ambitus_engraver } {
\override Staff.AmbitusLine #'gap = #0.45
a a''
}
cheers,
Janek
ambit.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
ambitus: special handling of small ambits' lines (issue4609041)
Reviewers: Mike, Description: ambitus: special handling of small ambits' lines Until now, it was not possible to have all ambits look good: either the gaps between ambit line and heads were too big for ambits of 4th and 5th, or they were too small for other ambits. This patch introduces automatic scaling of the gap between heads and line: bigger ambits are left unchanged, but smaller have their gap diminished so that the line is long enough. Please review this at http://codereview.appspot.com/4609041/ Affected files: M scm/output-lib.scm Index: scm/output-lib.scm diff --git a/scm/output-lib.scm b/scm/output-lib.scm index c25edf31f68a93de749a87e69e26cd4dde6dfc3d..dc2ff7a159313545f08fbfcb135a4a11b9f323fa 100644 --- a/scm/output-lib.scm +++ b/scm/output-lib.scm @@ -915,13 +915,44 @@ between the two text elements." (let* ((common (ly:grob-common-refpoint-of-array grob heads Y)) (head-down (ly:grob-array-ref heads 0)) (head-up (ly:grob-array-ref heads 1)) - (gap (ly:grob-property grob 'gap 0.35)) + ;; top of lower ambitus head: + (ground (interval-end (ly:grob-extent head-down common Y))) + ;; bottom of upper ambitus head: + (roof (interval-start (ly:grob-extent head-up common Y))) + ;; total amount of space between ambitus heads - + ;; our task is to decide how much of this space will be occupied + ;; by the ambitus line. We do this by calculating how big the gaps + ;; between ambitus line and ambitus heads will be. + (space-between-heads (- roof ground)) + ;; read the property - this is our starting point; + ;; we are going to adjust it to fit small ambituses better: + (gap-property (ly:grob-property grob 'gap 0.35)) + ;; We calculate a theoretical gap size using a linear function. + ;; the function was determined by trial-and-error; it's main + ;; premises are: gap is proportional to space between heads, + ;; big value in gap property means that small ambituses won't + ;; have any line at all, for values around 0.45 (default) + ;; gap approaches 0 when distance betweeen heads approaches 0, + ;; and it shouldn't reach 0 too soon with very small values. + (proportional (+ (max gap-property 0.3) -0.45 + (* 0.2 space-between-heads))) + ;; ambitus line looks best if the gap value is quanted. + ;; optimal quants are: 0.2 0.45 0.7 0.95 1.2 etc. + (quanted-gap (+ (* (floor (/ (- proportional 0.2) 0.25)) 0.25) 0.2)) + ;; we don't want to quant gap values smaller than 0.2 + ;; (because quanting them would mean making them 0). + (theoretical (if (< proportional 0.2) proportional quanted-gap)) + ;; The above calculations are mainly for small ambituses; + ;; in case of bigger ones they would lead to very big gaps + ;; so we restrict them by the value written in the gap property. + ;; we also don't want gap values too close to 0, hence the max. + (gap (max (min theoretical gap-property) (/ gap-property 4.5))) (point-min (+ (interval-end (ly:grob-extent head-down common Y)) gap)) (point-max (- (interval-start (ly:grob-extent head-up common Y)) gap))) - (if (< point-min point-max) + (if (< (+ point-min 0.1) point-max) ;; don't print lines shorter than 0.1 (let* ((layout (ly:grob-layout grob)) (line-thick (ly:output-def-lookup layout 'line-thickness)) (blot (ly:output-def-lookup layout 'blot-diameter)) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
