Re: biweekly Critical issues plea

[Carl Sorensen]

On 1/19/11 6:06 PM, "Mike Solomon"  wrote:

> Also works, also passes make check, also attached, also on Rietveld:
> http://codereview.appspot.com/4006044
> From Neil's e-mail, it seems that he advocates this solution because "Clefs
> are taken into account (shown by the yellow-blue skyline pair) when
> calculating horizontal skylines for NonMusicalPaperColumn, whereas key
> signatures are completely ignored.  We can ensure KeySignature is accounted
> for by adding it to `pure-print-callbacks'."

As part of the shepherding, we ought to make sure that the summaries you
have sent to -devel get posted as comments on the issue.  The issue ought to
contain all the knowledge we have on on a particular bug.

Thanks,

Carl


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: biweekly Critical issues plea

[Carl Sorensen]

On 1/19/11 6:06 PM, "Mike Solomon"  wrote:

> Also works, also passes make check, also attached, also on Rietveld:
> http://codereview.appspot.com/4006044
> From Neil's e-mail, it seems that he advocates this solution because "Clefs
> are taken into account (shown by the yellow-blue skyline pair) when
> calculating horizontal skylines for NonMusicalPaperColumn, whereas key
> signatures are completely ignored.  We can ensure KeySignature is accounted
> for by adding it to `pure-print-callbacks'."
> 

It seems to me that this is the better patch, because we are looking at the
inherent properties of the KeySignature, rather than adding the arbitrary
extra-spacing-distance.

Reading between the lines, I think this is what Neil was advocating as well
(although I know that Neil can clearly speak for himself).  His comment on
the issue indicates that he was starting to thing that the
extra-spacing-height fix was not the way to go.

Thanks, Mike!

Neil, any thoughts?

Carl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: biweekly Critical issues plea

[Mike Solomon]

Also works, also passes make check, also attached, also on Rietveld: 
http://codereview.appspot.com/4006044
From Neil's e-mail, it seems that he advocates this solution because "Clefs are 
taken into account (shown by the yellow-blue skyline pair) when calculating 
horizontal skylines for NonMusicalPaperColumn, whereas key signatures are 
completely ignored.  We can ensure KeySignature is accounted for by adding it 
to `pure-print-callbacks'."



0001-Alternative-1472-fix.patch
Description: Binary data


Cheers,
MS

On Jan 19, 2011, at 7:22 PM, Carl Sorensen wrote:

> 
> On 1/19/11 4:33 PM, "Mike Solomon"  wrote:
> 
>> Got it.
>> 
>> Then, here is the state of things:
>> 
>> 1/6
>> Bug is first reported on the bug list.
>> 
>> 1/7
>> Neil reports adding a default 'extra-spacing-height to key signature.
>> 
>> 1/10
>> Keith confirms that this works and that he gets a clean make check.
>> 
>> 1/13
>> Phil holmes reports the regression on the bugtracker (2.13.46).
>> Graham identifies that the output was correct on the bugtracker (2.12.3).
>> 
>> 1/19
>> Mike confirms that the regression is indeed due to 1190 and realizes that he
>> is not subscribed to the bug list.
>> Mike proposes a patch based on the discussion between Neil and Keith, which 
>> is
>> attached to this e-mail and on Rietveld @
>> http://codereview.appspot.com/4031042.
> 
> I think you missed Neil's email of 1/14, which suggested that the proper fix
> for this issue was not to add 'extra-spacing-height to the KeySignature, but
> to add KeySignature to the pure-print-callback list.
> 
> Or maybe the patch should have both the 'extra-spacing-height and the
> pure-print-callback.
> 
> Thanks,
> 
> Carl
> 
> 

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

issue 1475

[Benkő Pál]

an example added.

http://code.google.com/p/lilypond/issues/detail?id=1475

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: biweekly Critical issues plea

[Carl Sorensen]

On 1/19/11 4:33 PM, "Mike Solomon"  wrote:

> Got it.
> 
> Then, here is the state of things:
> 
> 1/6
> Bug is first reported on the bug list.
> 
> 1/7
> Neil reports adding a default 'extra-spacing-height to key signature.
> 
> 1/10
> Keith confirms that this works and that he gets a clean make check.
> 
> 1/13
> Phil holmes reports the regression on the bugtracker (2.13.46).
> Graham identifies that the output was correct on the bugtracker (2.12.3).
> 
> 1/19
> Mike confirms that the regression is indeed due to 1190 and realizes that he
> is not subscribed to the bug list.
> Mike proposes a patch based on the discussion between Neil and Keith, which is
> attached to this e-mail and on Rietveld @
> http://codereview.appspot.com/4031042.

I think you missed Neil's email of 1/14, which suggested that the proper fix
for this issue was not to add 'extra-spacing-height to the KeySignature, but
to add KeySignature to the pure-print-callback list.

Or maybe the patch should have both the 'extra-spacing-height and the
pure-print-callback.

Thanks,

Carl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: biweekly Critical issues plea

[Mike Solomon]

Got it.

Then, here is the state of things:

1/6
Bug is first reported on the bug list.

1/7
Neil reports adding a default 'extra-spacing-height to key signature.

1/10
Keith confirms that this works and that he gets a clean make check.

1/13
Phil holmes reports the regression on the bugtracker (2.13.46).
Graham identifies that the output was correct on the bugtracker (2.12.3).

1/19
Mike confirms that the regression is indeed due to 1190 and realizes that he is 
not subscribed to the bug list.
Mike proposes a patch based on the discussion between Neil and Keith, which is 
attached to this e-mail and on Rietveld @ http://codereview.appspot.com/4031042.

0001-Fix-for-issue-1472.patch
Description: Binary data

Make check passes.

Cheers,
MS

On Jan 19, 2011, at 5:23 PM, Carl Sorensen wrote:

> On 1/19/11 2:51 PM, "m...@apollinemike.com"  wrote:
> 
>> Graham et all,
>> 
>> I have read all of the postings and am up to date - I meant "what next" as a
>> general question to the community in the sense of "would anyone who was
>> actually involved in the pushing of this commit (Joe - I see your name
>> associated with it - how much work did you do on it?) like to give me some
>> guidance as to where to go so that I can find that which ultimately causes
>> this regression?"  In terms of man hours, I think that a little time invested
>> by the people who were involved in producing the commit would be more
>> efficient than my learning how lilypond functioned back when this was pushed.
>> That said, if the response is "I have no clue," then I will get to figuring 
>> it
>> out.
> 
> I think the best "what next" response is for you to summarize the discussion
> you have found on -bug, -devel, -user, and the issues comments to see what
> you think the current proposed resolution is, if anything.
> 
> There's been enough different discussion going on about this that I'm not
> clear what has been said or proposed (that's why I asked about 1474).  We
> may have a solution already at hand, but I'm not up on it.
> 
> The "shepherd" job is not to solve the bug, it's to make sure the developer
> community is on the same page about the bug.
> 
> Thanks,
> 
> Carl
> 
> 

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Odd vertical spacing of lyrics

[Graham Percival]

On Wed, Jan 19, 2011 at 11:58:46PM +0100, Jan Warchoł wrote:
> Graham,
> 
> 2011/1/19 Graham Percival :
> > If necessary, we can pretend that it's deliberate (after noting it
> > in the Changes document), call it a non-regression, make it
> > non-critical, and have a release.  That's no reason to not submit
> > a good bug report about it now.
> 
> Indeed i thought that vertical spacing is simply intended to work this
> way and that it's not a bug. I thought that this would just be an
> enhancement suggestion, with slight chances to have a high priority.
> Clearly i'm wrong.

I wouldn't say "clearly" -- I have no clue what we're talking
about.  I ignore almost all discussion about lyrics, so I don't
know what kind of "odd vertical spacing" you're talking about.  My
goal is just to clear up misunderstandings about reporting bugs
and/or our release policy.

I saw Mike write "... get this fixed in one of the first 2.14 bug
fixes..." and you responded with "this issue is important and
potentially widespread... I suppose that's what we should do:
release 2.14 and fix this issue thoroughly soon after that".

Regardless of the actual issue -- again, I don't know what the
code looks like or what the image looks like -- if two people are
wondering if it's a bug, then I want a proper bug report, and I
want the bug squad to add it to the tracker.  Do not think about
releases, do not think about scheduling programmers, do not pass
go, do not collect $200 [1].  Just send in the report.

[1] that's a common joke in English.

Maybe a developer will say "not a bug; this is an enhancement".
That's fine!  Changing the tags on issues is not a problem; this
is part of our normal workflow.  You shouldn't worry about that,
and the bug squad shouldn't worry about that.  You send in the
report.  The bug squad looks for any obvious omissions, then
either asks you for more info, or adds it to the tracker.  If the
issue is added as defect-critical-regression, and ends up being
enhancement-low-frog, that's ok!

Cheers,
- Graham


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Odd vertical spacing of lyrics

[Graham Percival]

On Wed, Jan 19, 2011 at 11:49:01PM +0100, James Bailey wrote:
> 
> On Jan 19, 2011, at 10:53 PM, Graham Percival wrote:
> 
> > On Wed, Jan 19, 2011 at 10:28:38PM +0100, Jan Warchoł wrote:
> > Please submit a bug report and let's get it in the tracker.
> > Doubly so if it's a regression.
> 
> Exactly this reasoning was the reason for my question, "what
> advantages does the new lyric spacing offer?" I think if we
> understand this, we can understand how to explain it, and make
> it easy for people to understand what needs to change and how.

Yes, but I think the first step to understanding it is to have a
Tiny example in the tracker.  If you have a Tiny example (ideally
without tweaks) that looks good in 2.12 and looks...
"different"... in 2.13, then we can discuss whether that
"different" is better or worse.

Maybe the solution will be code.  Maybe the solution will be
better documentation.  Maybe the solution will merely be adding
one sentence to the Changes document saying "yeah, it's changed;
deal with it".


I'm not pre-judging which option is the best, nor which one we'll
take -- but any of those cases should begin from a Tiny example in
the bug tracker.

(and if you cannot produce a lyric example which is "different"
without using tweaks, then that itself is an interesting data
point, and which could serve to narrow the focus of the
discussion)

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Odd vertical spacing of lyrics

[Jan Warchoł]

Graham,

2011/1/19 Graham Percival :
> On Wed, Jan 19, 2011 at 10:28:38PM +0100, Jan Warchoł wrote:
>> 2011/1/19 Mike Solomon :
>> > It may be worth it to add this to the issue tracker and get this fixed in 
>> > one of the first 2.14 bug fixes (if not 2.14 itself) - thoughts?
>>
>> In my opinion this issue is important and potentially widespread, and
>> as such it should be considered a high priority one.
>
> In my opinion, I don't care about your opinion, but I *do* care
> about evidence of bugs.  Please submit a bug report and let's get
> it in the tracker.  Doubly so if it's a regression.
>
>> I suppose that's what we should do: release 2.14 and fix this issue
>> thoroughly soon after that.
>
> If there's an actual regression, make a bug report.  If you don't
> do it now, then somebody else will do it 12 days after we release
> the final release candidate, and we'll have to scrap the release
> plans and it'll be much more disheartening to have it happen then.
>
> If necessary, we can pretend that it's deliberate (after noting it
> in the Changes document), call it a non-regression, make it
> non-critical, and have a release.  That's no reason to not submit
> a good bug report about it now.

Sorry for that.
Indeed i thought that vertical spacing is simply intended to work this
way and that it's not a bug. I thought that this would just be an
enhancement suggestion, with slight chances to have a high priority.
Clearly i'm wrong.
I'll investigate and report it tomorrow.

2011/1/19 Keith OHara :
> I started a lyrics template and shortcuts, but do not use lyrics myself, so I
> am wandering a bit aimlessly when I work on it.

It sits on my to-do list for some time now... Sorry about that. I'll
try to find more time and investigate.

Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Odd vertical spacing of lyrics

[James Bailey]

On Jan 19, 2011, at 10:53 PM, Graham Percival wrote:

> On Wed, Jan 19, 2011 at 10:28:38PM +0100, Jan Warchoł wrote:
>> 2011/1/19 Mike Solomon :
>>> It may be worth it to add this to the issue tracker and get this fixed in 
>>> one of the first 2.14 bug fixes (if not 2.14 itself) - thoughts?
>> 
>> In my opinion this issue is important and potentially widespread, and
>> as such it should be considered a high priority one.
> 
> In my opinion, I don't care about your opinion, but I *do* care
> about evidence of bugs.  Please submit a bug report and let's get
> it in the tracker.  Doubly so if it's a regression.

That's part of the problem. Is it a bug if something changed? Technically, no, 
as far as I understand the term "bug". Is it convoluted and difficult to use? 
Would graham's mother have difficulty understanding the documentation on 
getting a simple arrangement for her church choir to work the same way in 2.13 
as it did in 2.12? Probably. If I opened a bug report that was essentially, 
"Lyrics are now more difficult to use. Type - Regression, Priority - Critical", 
someone would probably close is as invalid very quickly.

Exactly this reasoning was the reason for my question, "what advantages does 
the new lyric spacing offer?" I think if we understand this, we can understand 
how to explain it, and make it easy for people to understand what needs to 
change and how.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: biweekly Critical issues plea

[Carl Sorensen]

On 1/19/11 2:51 PM, "m...@apollinemike.com"  wrote:

> Graham et all,
> 
> I have read all of the postings and am up to date - I meant "what next" as a
> general question to the community in the sense of "would anyone who was
> actually involved in the pushing of this commit (Joe - I see your name
> associated with it - how much work did you do on it?) like to give me some
> guidance as to where to go so that I can find that which ultimately causes
> this regression?"  In terms of man hours, I think that a little time invested
> by the people who were involved in producing the commit would be more
> efficient than my learning how lilypond functioned back when this was pushed.
> That said, if the response is "I have no clue," then I will get to figuring it
> out.
> 

IIUC, Neil's proposed patch to this issue was to add KeySignature to
pure-print-callbacks.

See http://lists.gnu.org/archive/html/bug-lilypond/2011-01/msg00169.html

But I haven't dug in to try to figure out exactly what that means. Given
what I know about Neil's suggestions, if you're trying to actually fix this
bug, I'd recommend you figure out what that means and do it.

Thanks,

Carl


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: biweekly Critical issues plea

[Carl Sorensen]

On 1/19/11 2:51 PM, "m...@apollinemike.com"  wrote:

> Graham et all,
> 
> I have read all of the postings and am up to date - I meant "what next" as a
> general question to the community in the sense of "would anyone who was
> actually involved in the pushing of this commit (Joe - I see your name
> associated with it - how much work did you do on it?) like to give me some
> guidance as to where to go so that I can find that which ultimately causes
> this regression?"  In terms of man hours, I think that a little time invested
> by the people who were involved in producing the commit would be more
> efficient than my learning how lilypond functioned back when this was pushed.
> That said, if the response is "I have no clue," then I will get to figuring it
> out.

I think the best "what next" response is for you to summarize the discussion
you have found on -bug, -devel, -user, and the issues comments to see what
you think the current proposed resolution is, if anything.

There's been enough different discussion going on about this that I'm not
clear what has been said or proposed (that's why I asked about 1474).  We
may have a solution already at hand, but I'm not up on it.

The "shepherd" job is not to solve the bug, it's to make sure the developer
community is on the same page about the bug.

Thanks,

Carl
 


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Odd vertical spacing of lyrics

[Graham Percival]

On Wed, Jan 19, 2011 at 10:28:38PM +0100, Jan Warchoł wrote:
> 2011/1/19 Mike Solomon :
> > It may be worth it to add this to the issue tracker and get this fixed in 
> > one of the first 2.14 bug fixes (if not 2.14 itself) - thoughts?
> 
> In my opinion this issue is important and potentially widespread, and
> as such it should be considered a high priority one.

In my opinion, I don't care about your opinion, but I *do* care
about evidence of bugs.  Please submit a bug report and let's get
it in the tracker.  Doubly so if it's a regression.

> I suppose that's what we should do: release 2.14 and fix this issue
> thoroughly soon after that.

If there's an actual regression, make a bug report.  If you don't
do it now, then somebody else will do it 12 days after we release
the final release candidate, and we'll have to scrap the release
plans and it'll be much more disheartening to have it happen then.


If necessary, we can pretend that it's deliberate (after noting it
in the Changes document), call it a non-regression, make it
non-critical, and have a release.  That's no reason to not submit
a good bug report about it now.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: biweekly Critical issues plea

[m...@apollinemike.com]

Graham et all,

I have read all of the postings and am up to date - I meant "what next" as a 
general question to the community in the sense of "would anyone who was 
actually involved in the pushing of this commit (Joe - I see your name 
associated with it - how much work did you do on it?) like to give me some 
guidance as to where to go so that I can find that which ultimately causes this 
regression?"  In terms of man hours, I think that a little time invested by the 
people who were involved in producing the commit would be more efficient than 
my learning how lilypond functioned back when this was pushed.  That said, if 
the response is "I have no clue," then I will get to figuring it out.

Cheers,
MS

On Jan 19, 2011, at 4:45 PM, Graham Percival wrote:

> On Wed, Jan 19, 2011 at 04:31:47PM -0500, m...@apollinemike.com wrote:
>> result of git bisect for issue 1472
>> 
>> ee0488f3aa19e0060b6e17c46a4d88cb9d57c489 is the first bad commit
>>Fix 1120.
>> 
>> What next?
> 
> Umm.  Next you read the emails on lilypond-devel which have been
> discussing this for the past few days.  I know that I've seen
> somebody talking about reverting the 1120 fix, either earlier
> today, or yesterday.
> 
> Remember, I told you that getting up-to-date was your job.  I
> honestly didn't know that the revert-1120-fix discussion was about
> issue 1472, but I'm not surprised.  The whole point of the
> "shepherd" idea was to avoid duplicating work like this!
> (yes, it was useful for you to learn about git bisect, but that's
> it)
> 
> Cheers,
> - Graham


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: biweekly Critical issues plea

[Graham Percival]

On Wed, Jan 19, 2011 at 04:31:47PM -0500, m...@apollinemike.com wrote:
> result of git bisect for issue 1472
> 
> ee0488f3aa19e0060b6e17c46a4d88cb9d57c489 is the first bad commit
> Fix 1120.
> 
> What next?

Umm.  Next you read the emails on lilypond-devel which have been
discussing this for the past few days.  I know that I've seen
somebody talking about reverting the 1120 fix, either earlier
today, or yesterday.

Remember, I told you that getting up-to-date was your job.  I
honestly didn't know that the revert-1120-fix discussion was about
issue 1472, but I'm not surprised.  The whole point of the
"shepherd" idea was to avoid duplicating work like this!
(yes, it was useful for you to learn about git bisect, but that's
it)

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: biweekly Critical issues plea

[m...@apollinemike.com]

result of git bisect for issue 1472

ee0488f3aa19e0060b6e17c46a4d88cb9d57c489 is the first bad commit
commit ee0488f3aa19e0060b6e17c46a4d88cb9d57c489
Author: Joe Neeman 
Date:   Fri Jun 18 16:53:17 2010 +0300

Fix 1120.

Don't add vertical padding to the skylines that are used for
horizontal spacing, since it can lead to unwanted horizontal space.

:04 04 5ceaa73a77481f6c2cab8e3d3077f63000914642 
70b6b1e231023394c4f5960d7db78e4037c8070d M  lily
:04 04 9a0c9c2272038782295539863535c9d0b5c87a88 
46574db4dc3bfe967df4451dabe6875f8e43d79c M  ly
:04 04 6847b1d07bfd3fea2dfc35ae0a0856693da14a37 
a256b66bcccb7f1f001c7e0de281a697d69e824f M  scm

What next?
MS

On Jan 19, 2011, at 11:33 AM, Graham Percival wrote:

> Have you read this page recently?
> http://lilypond.org/doc/v2.13/Documentation/contributor/finding-the-cause-of-a-regression
> 
> I think that the instructions are fairly clear, but if they're
> not, please let me know so that I can improve them.  (if you're
> familiar with American programming jargon, then think
> "dogfooding")
> 
> Also, don't forget to look for previous discussion, especially
> anything that Neil has written.  I wouldn't be surprised if he
> already identified the exact commit that's the problem, and/or
> posted an experimental patch.  Maybe all we need to do is to
> "unearth" that patch (from all of 4 days ago!), test it a bit,
> discuss why it works and doesn't hurt anything, then push it.
> I don't know.
> 
> [NB: this talk of a patch is purely hypothetical.  I haven't
> followed the discussion about this; that's your job.  I'm just
> pointing out that you'll feel awfully silly if you spend 2 hours
> working on this, and then discover that somebody already posted a
> patch that works.]
> 
> Cheers,
> - Graham
> 
> On Wed, Jan 19, 2011 at 11:10:12AM -0500, m...@apollinemike.com wrote:
>> Graham,
>> 
>> In this I'm a bit over my head - I am terrible with git stuff, and will need 
>> instructions & coaxing to get through this rewinding and bisecting thing.  
>> Alternatively, I could just try to code something that fixes the problem.
>> 
> 


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Odd vertical spacing of lyrics

[Jan Warchoł]

2011/1/19 Mike Solomon :
> I'll chime in and say that, although there is a workaround, the fact that 
> there is not good out-of-the-box spacing may effect a lot of real world 
> examples of choral music that is being engraved using lilypond.
>
> It may be worth it to add this to the issue tracker and get this fixed in one 
> of the first 2.14 bug fixes (if not 2.14 itself) - thoughts?

In my opinion this issue is important and potentially widespread, and
as such it should be considered a high priority one.
I also think that a good solution would mean changing the lyrics
spacing mechanisms considerably (especially because it's connected
with some vertical and horizontal lyrics spacing issues that should be
addressed).
I have some thoughts on these topics, but from what i see the
discussion about them may become monstrous in size, so i'm waiting
until 2.14 is out.
I suppose that's what we should do: release 2.14 and fix this issue
thoroughly soon after that.

cheers,
Janek

> Is there a way to add this to the issue tracker.
>
> On Jan 19, 2011, at 3:42 PM, Jan Warchoł wrote:
>
>> 2011/1/18 Carl Sorensen 
>>>
>>> On 1/18/11 8:26 AM, "Mike Solomon"  wrote:
>>>
 Hey all,

 The following snippet is giving me the attached output w/ the soprano line
 shifted way up after the line break.  Is there any way to get the soprano
 correctly aligned (w/o changing the distance between systems - this minimal
 example approximates a larger one w/ many systems over several pages).

 \version "2.13.47"
>>>
>>>
>>> Mike,
>>>
>>> I got it to work successfully with the following change:
>>>
>>>    \new Lyrics = sopranos \with {
>>>      \override VerticalAxisGroup #'staff-affinity = #DOWN
>>>      } { s1 }
>>>
>>>
>>> The lyrics were still a little bit high, however.  It's almost like there's
>>> a blank context hiding in the middle.  But I haven't been able to get rid of
>>> that small amount of extra space.
>>
>> The reference point of lyrics is the baseline and this is the cause of
>> the problem - #'nonstaff-relatedstaff-spacing #'basic-distance
>> appropriate for lyrics below staff is not appropriate for lyrics above
>> staff. Consider the following (and look at the attachment):
>>
>> \version "2.13.45"
>>
>> \paper { system-system-spacing #'basic-distance = #20 ragged-right = ##t }
>>
>> \score {
>> \new ChoirStaff <<
>>   \new Lyrics = abovelyrics \with { \override VerticalAxisGroup
>> #'staff-affinity = #DOWN }
>>     { s1 }
>>   \new Staff {
>>        \new Voice = "empty" { r4 r r r \break } \new Voice =
>> "firstPart" { f' f' f' f' } \new Voice = "secondPart" { e'' e'' e''
>> e'' }
>>     }
>>   \new Lyrics = "belowlyrics" { s1 }
>>
>>   \context Lyrics = abovelyrics \lyricsto firstPart \lyricmode { ma
>> -- ma ma -- ma }
>>   \context Lyrics = belowlyrics \lyricsto secondPart \lyricmode { mo
>> mo -- mo mo }

>>  \layout {
>>    \context {
>>      %  \Lyrics \override VerticalAxisGroup
>> #'nonstaff-relatedstaff-spacing #'basic-distance = #4
>>        }
>>    }
>> }
>>
>> You can see how this changes by uncommenting the
>> nonstaff-relatedstaff-spacing override.
>>
>> The strange thing is that all this somehow doesn't affect first system.
>>
>> cheers,
>> Janek
>
>

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Status on 1474

[Keith OHara]

Carl Sorensen  byu.edu> writes:

> So what is the current status on 1474?
> 
> I think that the latest proposal from Keith O'Hara was to revert ee0488.
> 
Issue 1474 looks like intentional behavior to me, and non-regressive to 
Janek.   We'll see what Bernard says after he gives this a fresh look with a 
clear mind.

Reverting ee0488 (fixed 1120) looked fine at first, but with the example at the 
bottom, reverting ee0488 results in lyrics stretching the note spacing, the 
essence of 1120.   

Lyrics 'padding needs to be greater than the sum of effective extra-spacing-
heights of the LyricsText plus the relevant Notehead, or Stem, or etc.,  so 
that the NoteColumns can slide ('tuck') over the Lyrics.

ee0488 made this happen by removing a default extra-spacing-height and giving 
extra-spacing-height explicitly to the items who need it.  This had side-
effects.  KeySignatures used extra-spacing-height (in a perverse way) to keep 
multimeasure rests from colliding (1472).  Accidentals more often got space, to 
which I became accustomed (1474).

We can finish the job of re-distributing extra-spacing-height to complete 
ee0488, or find a better solution for issue 1120 (maybe LyricText extra-spacing 
height '(+1 . -1) ? ).  

My current frustration with redistribution: anything that should slide over 
Lyrics needs zero extra-height, but then those things tuck very closely with 
each other.  

What I most want to determine is whether there is a wiser fix to issue 1120, so 
that spacing rules involving Lyrics do not compete with other spacing desires. 
I am still absorbing the depth of Neil's last comment on the issue


==
\score { % essence of issue 1120
  << \context Voice = "v" {
\stemDown g'~ g' g' 
  }
  \new Lyrics \lyricsto "v" { 
\lyricmode { Amm A }
  } >>  
  \layout { \context {
\Score
  \override PaperColumn #'stencil = #ly:separation-item::print
  }}} #(ly:set-option 'debug-skylines


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: biweekly Critical issues plea

[Francisco Vila]

2011/1/19 Graham Percival :
> On Wed, Jan 19, 2011 at 04:32:21PM +0100, Francisco Vila wrote:
>> 2011/1/19 Graham Percival :
>> >it's no problem for me to recompile lilypond
>> > 30 or 40 times.
>>
>> Finding a commit out of 40 by git-bisect shouldn't need to recompile
>> more than log2(40)=5.32  , this gives 6 times in the worst case.
>
> We've had more than 40 commits between 2.12.3 and 2.13.46.
> Granted, it's probably less than a billion.  I guess that "12 to
> 14 times" would have been a better estimate.

Oops, you're right.  Namely, 13 as a worst case is the figure.

There is no 2.12.3 tag in master; there are
2.12.2-1 01ceb9ac (4469 commits until 2.13.46), and
2.13.0-0 f1f15cd97 (4348 commits until 2.13.46).

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: biweekly Critical issues plea

[m...@apollinemike.com]

My bad!
I'll take on 1472...gulp...

Cheers,
Mike
 
On Jan 19, 2011, at 7:29 AM, Graham Percival wrote:

> On Wed, Jan 19, 2011 at 06:57:27AM -0500, m...@apollinemike.com wrote:
>> I'll take care of 1472, but I need a copy of Valentin's opera.
> 
> Valentin's opera is available as a git checkout:
> http://repo.or.cz/w/opera_libre.git
> but did you mean 1475 instead?  Benk has claimed it.
> 
> 
> I tried briefly looking at the opera a few days ago, but it didn't
> compile in 2.12.3 or 2.13.46, so I gave up after a few minutes.
> Finding a minimal example that works in both 2.12.3 and 2.13.46
> might be tricky, but such an example is necessary if we're going
> to run git bisect and the like.  Maybe it you disable all tweaks,
> you can still reproduce the crash with recent lilypond, but still
> run it in the old version?
> 
> (this is a prime example of why I want to  1. have stable releases
> closer together, and 2. pin down at least a subset of our input
> syntax with GLISS)
> 
> Cheers,
> - Graham


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: biweekly Critical issues plea

[Graham Percival]

On Wed, Jan 19, 2011 at 04:32:21PM +0100, Francisco Vila wrote:
> 2011/1/19 Graham Percival :
> >it's no problem for me to recompile lilypond
> > 30 or 40 times.
> 
> Finding a commit out of 40 by git-bisect shouldn't need to recompile
> more than log2(40)=5.32  , this gives 6 times in the worst case.

We've had more than 40 commits between 2.12.3 and 2.13.46.
Granted, it's probably less than a billion.  I guess that "12 to
14 times" would have been a better estimate.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: biweekly Critical issues plea

[Francisco Vila]

2011/1/19 Graham Percival :
>it's no problem for me to recompile lilypond
> 30 or 40 times.

Finding a commit out of 40 by git-bisect shouldn't need to recompile
more than log2(40)=5.32  , this gives 6 times in the worst case.

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Docs: automatic accidentals (was: Odd output)

[Trevor Daniels]

Thanks Keith

Pushed

Trevor

- Original Message - 
From: "Keith OHara" 

To: "James Lowe" ; 
Cc: "Trevor Daniels" 
Sent: Wednesday, January 19, 2011 7:25 AM
Subject: Re: Docs: automatic accidentals (was: Odd output)


On Sat, 18 Dec 2010 15:56:25 -0800, Keith OHara 
 wrote:


On Fri, 10 Dec 2010 01:46:24 -0500 James Lowe 
 wrote:>



PS To anyone else who knows, if this known issue does apply in 
this case, then it might be a good idea to not use the word 
'chord' as that can mean different things to different types of 
musicians - if you see what I mean. We could therefore edit the 
documentation?


Good point.  The issue regarding accidentals is not limited to 
chords.
Also, LilyPond *does* support such chords, most of the time. (The 
relevant

reg-test is ‘accidental-placement-samepitch.ly’)



Docs patch attached.

The accidental missing in <> is not limited to chords, so 
its explanation goes under "Pitches, accidentals".


The collision in  is related to chords, meaning note 
heads on a shared stem, so it goes under "Chords".
-Keith 




___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: biweekly Critical issues plea

[Benkő Pál]

2011/1/19 Graham Percival :
> On 1/19/11, Benkő Pál  wrote:
>>> I tried briefly looking at the opera a few days ago, but it didn't
>>> compile in 2.12.3 or 2.13.46, so I gave up after a few minutes.
>>> Finding a minimal example that works in both 2.12.3 and 2.13.46
>>> might be tricky,
>>
>> tonight I'll prepare a smaller example, the one mentioned in
>> http://lists.gnu.org/archive/html/lilypond-devel/2011-01/msg00387.html
>
> That would be great; once there's an example, I can find the exact
> commit which produces the crash.  I have a powerful desktop doing
> nothing most of the time; it's no problem for me to recompile lilypond
> 30 or 40 times.

the commit was identified and a patch is proposed, see
http://lists.gnu.org/archive/html/lilypond-devel/2011-01/msg00227.html

but we can't understand why does it work; we know, however, that
it changes behaviour as well, see
http://lists.gnu.org/archive/html/lilypond-devel/2011-01/msg00387.html

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: biweekly Critical issues plea

[Graham Percival]

On 1/19/11, Benkő Pál  wrote:
>> I tried briefly looking at the opera a few days ago, but it didn't
>> compile in 2.12.3 or 2.13.46, so I gave up after a few minutes.
>> Finding a minimal example that works in both 2.12.3 and 2.13.46
>> might be tricky,
>
> tonight I'll prepare a smaller example, the one mentioned in
> http://lists.gnu.org/archive/html/lilypond-devel/2011-01/msg00387.html

That would be great; once there's an example, I can find the exact
commit which produces the crash.  I have a powerful desktop doing
nothing most of the time; it's no problem for me to recompile lilypond
30 or 40 times.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: biweekly Critical issues plea

[Benkő Pál]

>> I'll take care of 1472, but I need a copy of Valentin's opera.
>
> Valentin's opera is available as a git checkout:
> http://repo.or.cz/w/opera_libre.git
> but did you mean 1475 instead?  Benk has claimed it.
>
>
> I tried briefly looking at the opera a few days ago, but it didn't
> compile in 2.12.3 or 2.13.46, so I gave up after a few minutes.
> Finding a minimal example that works in both 2.12.3 and 2.13.46
> might be tricky,

tonight I'll prepare a smaller example, the one mentioned in
http://lists.gnu.org/archive/html/lilypond-devel/2011-01/msg00387.html

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: global staff-staff spacing fails in 2.13.46

[Trevor Daniels]

Keith OHara wrote Wednesday, January 19, 2011 7:25 AM



 Follow-up patch attached.
 The misleading bit was the implication that the properties always 
contain alists, when one of them is by default a function 
returning whichever alist is appropriate depending on whether the 
staff is in a group.


  This patch tells the truth about staff-staff-spacing, and amends 
an example to use the simpler default-staff-staff-spacing so that 
readers can use the grouped/ungrouped examples in the same file.


This looks fine to me.  I'll push it in a day or two if there are no 
adverse comments.


Thanks Keith.

Trevor



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: biweekly Critical issues plea

[Graham Percival]

On Wed, Jan 19, 2011 at 06:57:27AM -0500, m...@apollinemike.com wrote:
> I'll take care of 1472, but I need a copy of Valentin's opera.

Valentin's opera is available as a git checkout:
http://repo.or.cz/w/opera_libre.git
but did you mean 1475 instead?  Benk has claimed it.


I tried briefly looking at the opera a few days ago, but it didn't
compile in 2.12.3 or 2.13.46, so I gave up after a few minutes.
Finding a minimal example that works in both 2.12.3 and 2.13.46
might be tricky, but such an example is necessary if we're going
to run git bisect and the like.  Maybe it you disable all tweaks,
you can still reproduce the crash with recent lilypond, but still
run it in the old version?

(this is a prime example of why I want to  1. have stable releases
closer together, and 2. pin down at least a subset of our input
syntax with GLISS)

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: biweekly Critical issues plea

[Bernard Hurley]

I'll take on 1474

Bernard

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: biweekly Critical issues plea

[David Kastrup]

Graham Percival  writes:

> Did you know that English is an absolutely stupid language?  The
> word "biweekly" can mean either "4 times each 14 days", or "1 time
> each 14 days"!

What's wrong with "fortnightly"?

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: biweekly Critical issues plea

[Benkő Pál]

> Work on Critical issues has pretty much wound down.  Carl asked
> about the status of 1474 recently; I'd like to take that a step
> further and ask for a dedicated volunteer to act as "shepherd" for
> each issue.
> - you *don't* need to program, or even understand programming
>  (but that would be a plus)
> - you *do* need to read all emails on the subject
> - you *do* need to keep the issue up-to-date.  If there's a large
>  discussion happening, just follow it, but when the discussion
>  dies down, make sure that you post a summary and/or links to
>  the main emails in the issue.
> - you should be ready to give a status update if somebody asks for
>  one, but that shouldn't be necessary because you should have
>  already updated the issue with that info.
>
> There's three Critical issues: 1472, 1474, and 1475.  Any takers?
> (again, to be the "shepherd" or "secretary", not to handle all
> programming tasks yourself)

I'll take 1475.

p

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: biweekly Critical issues plea

[m...@apollinemike.com]

I'll take care of 1472, but I need a copy of Valentin's opera.

Cheers,
MS

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

biweekly Critical issues plea

[Graham Percival]

Did you know that English is an absolutely stupid language?  The
word "biweekly" can mean either "4 times each 14 days", or "1 time
each 14 days"!

Anyway, here's my less-than-twice-a-week plea to new contributors:

We are, yet again, about 10-20 hours of work away from having 0
critical issues.  This is a familiar position; we've been like
this since mid-August.  There is no change of releasing 2.14 in
Jan, and only a small chance of having it in Feb.  As we slowly
fix Critical issues, people discover more.  

We simply have an imbalance between the energy/interest of
developers and the amount of Critical issues.  That's where the
new contributors come in.  Any effort you put towards fixing
Critical issues will help fix them sooner, which in turn will make
2.14 happen sooner.

Work on Critical issues has pretty much wound down.  Carl asked
about the status of 1474 recently; I'd like to take that a step
further and ask for a dedicated volunteer to act as "shepherd" for
each issue.
- you *don't* need to program, or even understand programming
  (but that would be a plus)
- you *do* need to read all emails on the subject
- you *do* need to keep the issue up-to-date.  If there's a large
  discussion happening, just follow it, but when the discussion
  dies down, make sure that you post a summary and/or links to
  the main emails in the issue.
- you should be ready to give a status update if somebody asks for
  one, but that shouldn't be necessary because you should have
  already updated the issue with that info.

There's three Critical issues: 1472, 1474, and 1475.  Any takers?
(again, to be the "shepherd" or "secretary", not to handle all
programming tasks yourself)


The release is never going to happen if nobody works on it.  New
contributors, please consider working on it.  All it takes is time
and energy.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel