Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)

2011-11-23 Thread Keith OHara 

On Mon, 21 Nov 2011 00:16:12 -0800, Keith OHara  wrote:


On Sun, 20 Nov 2011 23:57:22 -0800,  wrote:


I think that you're right for most cases, but for a piece with lots of
accidentals that could potentially hang over barlines, this complexity
in estimation seems to help.


Have an example where pure-from-neighbor would do better than
axis-group-interface:height ?


Well I can't seem to get axis-group-interface:height to work for BarLines at 
all.
I must not understand how SpanBars used to work.



I expect that occasionally, this patch will let a collision with a span
bar leak through, but it would be something crazy like an \espressivo atop
a \downbow on a note connected to a cross-staff slur.  The \espressivo
isn't pure-relevant because of the cross-staff poisoning.


This doesn't look too bad.  At most it slightly increases the incidence of 
cross-staff collisions
  \new GrandStaff <<
\new Staff = "up" {
  g'1 \noBreak g'1 \noBreak g'1 }
\new Staff = "down" {
  g'1 g'1 e''2_\(\portato\espressivo
  \change Staff="up" f'2\) } >>
The espressivo is generally disrespected in spacing.  If we turn the g's in the 
upper staff into gs, the last of them hits the espressivo.


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

Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)

2011-11-23 Thread m...@apollinemike.com 
On Nov 23, 2011, at 9:21 AM, Keith OHara wrote:

> On Mon, 21 Nov 2011 00:16:12 -0800, Keith OHara  wrote:
> 
>> On Sun, 20 Nov 2011 23:57:22 -0800,  wrote:
>> 
>>> I think that you're right for most cases, but for a piece with lots of
>>> accidentals that could potentially hang over barlines, this complexity
>>> in estimation seems to help.
>> 
>> Have an example where pure-from-neighbor would do better than
>> axis-group-interface:height ?
>> 
> Well I can't seem to get axis-group-interface:height to work for BarLines at 
> all.
> I must not understand how SpanBars used to work.

axis-group-interface::height takes the height of the grobs in the 'elements 
grob-array for a given grob.  Span bars have bar lines in their 'elements grob 
array, which is why span bars worked.  Bar lines don't have an 'elements grob 
array (they just have a 'neighbors grob array with the current patch).

> 
>> 
>> I expect that occasionally, this patch will let a collision with a span
>> bar leak through, but it would be something crazy like an \espressivo atop
>> a \downbow on a note connected to a cross-staff slur.  The \espressivo
>> isn't pure-relevant because of the cross-staff poisoning.
> 
> This doesn't look too bad.  At most it slightly increases the incidence of 
> cross-staff collisions
>  \new GrandStaff <<
>\new Staff = "up" {
>  g'1 \noBreak g'1 \noBreak g'1 }
>\new Staff = "down" {
>  g'1 g'1 e''2_\(\portato\espressivo
>  \change Staff="up" f'2\) } >>
> The espressivo is generally disrespected in spacing.  If we turn the g's in 
> the upper staff into gs, the last of them hits the espressivo.
> 

Thanks for the example!  I'll address it after pushing this series of patches.  
If I forget, please remind me.

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

stupid question about patching push / countdowns

2011-11-23 Thread Adam Spiers 
Hi all,

Sorry - it only recently dawned on me that I'm probably responsible
for pushing my patches which I think have now already been reviewed
and approved.

I've read the CG and tried to understand the exact process, but as
previously noted on this list, the CG is not entirely complete and
up-to-date so I thought I should check here first.  Am I right in
guessing that the Patch-push label indicates that the review process
is complete and that the patch should be pushed by the developer /
patch helper / frog-meister as appropriate?  In which case I should
push to the dev/staging branch myself?

I'm also a bit unclear on how the countdown process works and what it
achieves.  I see that issues sometimes have the "Patch-countdown"
label replaced with the "Patch-push" label - what does that signify?

The following sections need to be updated:

http://lilypond.org/doc/v2.15/Documentation/contributor/commits-and-patches
http://lilypond.org/doc/v2.15/Documentation/contributor/issue-classification
http://lilypond.org/doc/v2.15/Documentation/contributor/patch-handling

I could perhaps find time for this if I knew answers to the above.

Thanks!
Adam

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

Re: stupid question about patching push / countdowns

2011-11-23 Thread Colin Campbell 

On 11-11-23 06:47 AM, Adam Spiers wrote:

Hi all,

Sorry - it only recently dawned on me that I'm probably responsible
for pushing my patches which I think have now already been reviewed
and approved.

I've read the CG and tried to understand the exact process, but as
previously noted on this list, the CG is not entirely complete and
up-to-date so I thought I should check here first.  Am I right in
guessing that the Patch-push label indicates that the review process
is complete and that the patch should be pushed by the developer /
patch helper / frog-meister as appropriate?  In which case I should
push to the dev/staging branch myself?


Exactly so, Adam.  I'm wondering if your ears were burning, as I noticed 
last night that there were some patches on patch-push for quite a 
while.  Yes, please push or arrange to have pushed, anything of yours 
which has that status.


I'm also a bit unclear on how the countdown process works and what it
achieves.  I see that issues sometimes have the "Patch-countdown"
label replaced with the "Patch-push" label - what does that signify?


As patches are posted on Rietveld, James (ATM) will test them by 
applying to current git.  If the build doesn't go up in flames, the 
patch status is changed from patch-new to patch-review, and developers 
are encouraged to examine the proposed patch, offering comments and 
suggestions.  Several times a week, at present Tuesday, Thursday and 
Sunday, I scan the list of patch-review items, checking the discussion 
on the tracker and also on the associated Rietveld item.  If there is 
either an apparent concensus or at least no negative comment, I add it 
to the countdown scheduled for 48 (72) hours later.  This is a sort of 
"last chance" request for review by developers.  When the countdown 
expires, the patch has first, been applied to current git, and second, 
has not been actively rejected by developers, so it is considered ready 
for pushing.  Note that this doesn't mean that the patch has any merit, 
nor that it won't say nasty things about your grandmother, only that no 
developer objected.  When I set the status to "patch-push", the owner 
should then push to staging, close the Reitveld issue (only the owner 
can do so),  post the committish on the tracker issue, and mark the 
tracker status as fixed and add a tag "fixed_2_15_20" as appropriate.




The following sections need to be updated:

http://lilypond.org/doc/v2.15/Documentation/contributor/commits-and-patches
http://lilypond.org/doc/v2.15/Documentation/contributor/issue-classification
http://lilypond.org/doc/v2.15/Documentation/contributor/patch-handling

I could perhaps find time for this if I knew answers to the above.

Thanks!
Adam



Patches accepted gratefully, Adam, and should probably go through the 
review process.



Cheers,
Colin


--
I've learned that you shouldn't go through life with a catcher's mitt on both 
hands.
You need to be able to throw something back.
-Maya Angelou, poet (1928- )


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

Re: stupid question about patching push / countdowns

2011-11-23 Thread Graham Percival 
On Wed, Nov 23, 2011 at 01:47:12PM +, Adam Spiers wrote:
> Am I right in
> guessing that the Patch-push label indicates that the review process
> is complete and that the patch should be pushed by the developer /
> patch helper / frog-meister as appropriate?  In which case I should
> push to the dev/staging branch myself?

Yes.  Quite undocumented is that we're renamed "dev/staging" to
"staging".  Please push any patch for any "Patch-push" issue to
"staging".


I have good news, though: the students in my 4th-year audio
programming class convinced the lecturer to cancel the last two
classes.  (WTF?!?)   As a result, I have nothing keeping me in
Glasgow, and after £160 in extra charges at british airways, I'm
flying back to Vancouver in about 14 hours.

You can expect a drastic turn-around in our development process by
next week.  Don't worry about updating the CG for this stuff.

- Graham

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

Re: stupid question about patching push / countdowns

2011-11-23 Thread David Kastrup 
Graham Percival  writes:

> As a result, I have nothing keeping me in Glasgow, and after £160 in
> extra charges at british airways, I'm flying back to Vancouver in
> about 14 hours.
>
> You can expect a drastic turn-around in our development process by
> next week.  Don't worry about updating the CG for this stuff.

Oh.  And I was just getting warm.

-- 
David Kastrup


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

do not tinker with the position of a pitched rest (issue 5434061)

2011-11-23 Thread benko . pal 

Reviewers: ,

Message:
hi all,

if I extend the staff by a line, pitched rests appear shifted by half a
line (thus half rests look like whole rests and vice versa).
this patch is a quick fix for that.

I feel the line-positions and line-count properties of Staff are badly
tangled; I intend to work on sorting those out, but expect it to be
slow.

Description:
do not tinker with the position of a pitched rest

Please review this at http://codereview.appspot.com/5434061/

Affected files:
  A input/regression/rest-on-nonstandard-staff.ly
  M lily/rest.cc


Index: input/regression/rest-on-nonstandard-staff.ly
diff --git a/input/regression/rest-on-nonstandard-staff.ly  
b/input/regression/rest-on-nonstandard-staff.ly

new file mode 100644
index  
..b68330a6872b0ca0525f3813995795e6d009ac5d

--- /dev/null
+++ b/input/regression/rest-on-nonstandard-staff.ly
@@ -0,0 +1,38 @@
+\version "2.15.18"
+
+\header {
+  texidoc = "half rests should lie on a staff line, whole rests should hang
+  from a staff line by default even for non-standard staves, except when
+  the position is set by pitch."
+}
+
+
+\layout {
+  ragged-right = ##t
+  indent = 0.0
+}
+
+\new StaffGroup <<
+  \new Staff {
+r2
+g'2\rest
+r1
+g'1\rest
+  }
+
+  \new Staff {
+\override Staff.StaffSymbol #'line-positions = #'(-4 -2 0 2)
+r2
+g'2\rest
+r1
+g'1\rest
+  }
+
+  \new Staff {
+\override Staff.StaffSymbol #'line-count = #4
+r2
+g'2\rest
+r1
+g'1\rest
+  }
+>>
Index: lily/rest.cc
diff --git a/lily/rest.cc b/lily/rest.cc
index  
d86296fada49e3c5bcbc8558f709f275f4efe51c..0a816fcd8a5296a05b6b65facbf1491e1de111d1  
100644

--- a/lily/rest.cc
+++ b/lily/rest.cc
@@ -40,20 +40,33 @@ Rest::y_offset_callback (SCM smob)
   Real ss = Staff_symbol_referencer::staff_space (me);

   bool position_override = scm_is_number (me->get_property  
("staff-position"));

-  Real amount = robust_scm2double (me->get_property ("staff-position"), 0)
-* 0.5 * ss;
+  Real amount;

-  if (line_count % 2)
+  if (position_override)
 {
-  if (duration_log == 0 && line_count > 1)
-amount += ss;
+  amount =
+robust_scm2double (me->get_property ("staff-position"), 0) * 0.5 *  
ss;

+  /*
+trust the client on good positioning;
+would be tempting to adjust position of rests longer than a quarter
+to be properly aligned to staff lines,
+but custom rest shapes may not need that sort of care.
+  */
 }
   else
-amount += ss / 2;
+{
+  amount = 2 * ss * get_grob_direction (me);

-  if (!position_override)
-amount += 2 * ss * get_grob_direction (me);
+  if (line_count % 2 == 0)
+amount += ss / 2;
+}

+  /*
+make a semibreve rest hang from the next line,
+except for a single line staff
+  */
+  if (duration_log == 0 && line_count > 1)
+amount += ss;

   return scm_from_double (amount);
 }



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

Fix compile on OSX by including std-vector.hh instead of (issue 5437052)

2011-11-23 Thread graham 

this is the kind of patch that can in theory be pushed directly to
staging, although in this case I'm glad there was a review first.


http://codereview.appspot.com/5437052/diff/1/lily/include/lily-guile.hh
File lily/include/lily-guile.hh (right):

http://codereview.appspot.com/5437052/diff/1/lily/include/lily-guile.hh#newcode30
lily/include/lily-guile.hh:30: #ifndef STD_VECTOR_HH
std-vector.hh already includes that ifndef, so omit it from here.

http://codereview.appspot.com/5437052/

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