bug-lilypond
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue 1566 in lilypond: Beam properties won't be changed after the s


From: lilypond
Subject: Re: Issue 1566 in lilypond: Beam properties won't be changed after the start of the beam
Date: Tue, 03 Jan 2012 10:45:35 +0000

Updates:
        Status: Started
        Owner: address@hidden

Comment #6 on issue 1566 by address@hidden: Beam properties won't be changed after the start of the beam
http://code.google.com/p/lilypond/issues/detail?id=1566

On 1 January 2012 23:38, Keith OHara <address@hidden> wrote:
On Sun, 01 Jan 2012 14:33:33 -0800, <address@hidden> wrote:

I disagree.

The example in the tracker is overly complicated for what (I still
maintain) is easily explained. However *if* we really do need an example
then the \hideNotes one is not ideal. I struggled myself with that one
in the tracker, it isn't a 'tiny example' by any stretch of the
imagination and I knew perfectly well what was meant by the problem only
*after* I read the text explanation, the picture on the tracker added
nothing for me.


Okay, then.  You are addressing the fact that the beam was not un-hidden
mid-stroke, because no properties are changed mid-stroke.  So this makes
sense as a knownissue

The other way looking at the bug report is that \hideNotes seems to have
removed the automatic beam.  ( What is your man going on about with the
"beam properties"?  I don't see any beam.  Do you see a beam? )

For that aspect, I'll add a few words and beamed notes to the second example
of NR 1.7.1 \hideNotes :
+ Note heads, stems, flags, and beams are invisible, but other
= objects that are attached to invisible notes are still visible.


Let the documentation patches close issue 1566.

Valentin in his original report <http://lists.gnu.org/archive/html/bug-lilypond/2011-03/msg00331.html> thought the beam was hidden by \hideNotes, knew how to get what he wanted, and suggested it might be simply documentation. He tentatively asked for the c8. d16 to be auto-beamed (but in fact it already is). Nobody asked for beams to change properties mid-stroke. So nothing to do 'codewise' in response to 1566.

We missed the underlying issue, though.
{ r8
 \once\override NoteHead #'color = #blue
 \once\override Beam #'color = #blue
 c''
 override Beam #'color = #red
 c''8. d''16 % These two get auto-beamed in blue
}
It seems the auto-beamer is thinking about drawing a blue beam starting at the first eight note, changes his mind when he sees the dotted rhythm, but still holds on to the request for blue. If that's a bug, it should be tracked free of the confusion of 1566.


Attachments:
        autobeam.png  3.1 KB


reply via email to

[Prev in Thread] Current Thread [Next in Thread]