hideNotes does not work if you override color
Hello.
I noticed that if you use \override color then \hideNotes does not work.
Cheers, Matti Aaltonen, Finland
\header {
title = If you color notes
subtitle = then hideNotes doesn't work
source =
composer = Lily Pond
enteredby =
copyright = ...
}
\include english.ly
\version 2.8.5
vocala = \context Staff \relative c'' \new Voice = melodya
{
\stemUp d8 d d d d d d d
}
vocalb = \context Staff \relative c'' \new Voice = melodyb
{
\override NoteHead #'color = #(x11-color 'LimeGreen)
\override Rest #'color = #(x11-color 'LimeGreen)
\override Beam #'color = #(x11-color LimeGreen)
\override Stem #'color = #(x11-color 'LimeGreen)
\stemDown a8 a a a \hideNotes a a a a \unHideNotes
}
\score
{
\new Staff = treble
\vocala
\vocalb
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Chord changes over repeat alternatives
Paul Scott wrote: Yitz Gale wrote: The Chord Name engraver with chordChanges = #t does not print the chord at the beginning of a repeat alternative if the chord at the end of the previous repeat alternative was the same. The way I read the 2.6 documentation This bug is not specific to 2.6. It affects 2.8 and 2.9 also (I think). ...you want to set chordChanges = ##f if you want the chord printing to change when you want it to instead of when the chord changes. Is that what you meant? No. I want the chords to print when they change. For this, I need to set chordChanges = ##t. However, there is a bug that causes lilypond to skip a chord in a certain case even though it is a change, as described above, and as shown in my example. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Chord changes over repeat alternatives
Yitz Gale wrote:
Paul Scott wrote:
Yitz Gale wrote:
The Chord Name engraver with chordChanges = #t
does not print the chord at the beginning
of a repeat alternative if the chord at the
end of the previous repeat alternative was
the same.
The way I read the 2.6 documentation
This bug is not specific to 2.6.
It affects 2.8 and 2.9 also (I think).
I just looked it up in the 2.6 documentation because you mentioned
2.6.3. I think the behavior hasn't changed and I don't think it's a bug
in my understanding of how Lilypond works. See below.
...you want to set chordChanges = ##f if you
want the chord printing to change when you want
it to instead of when the chord changes.
Is that what you meant?
No. I want the chords to print when they change.
For this, I need to set chordChanges = ##t.
However, there is a bug that causes lilypond to skip
a chord in a certain case even though it is a change,
as described above, and as shown in my example.
Your example doesn't use the chordChanges = #t feature since you are
changing the chords yourself. You have two f chords in the 1st ending.
If you wanted the chordChanges = #t feature you would write f1.
Lilypond doesn't do anything special with notes or chords at endings so
I don't believe this is a bug in Lilyponds way of doing things. Did you
try chordChanges = #f ? I believe it will make your example do exactly
what you want.
Indeed I just tried it and it does exactly what you said you wanted it
to. To be exact the following works:
{
\new ChordNames \with{ voltaOnThisStaff = ##t } {
\set chordChanges = ##f
\chordmode {
\repeat volta 2 {
c2 c
} \alternative { {
f f
} {
f g
} }
c1
}
}
}
HTH,
Paul
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Chord changes over repeat alternatives
Paul Scott wrote: I don't think it's a bug in my understanding of how Lilypond works. It is definitely a bug. See below. Also, see the the thread in July 2004 on this list in which the developers confirmed that this is a bug. They even seem to have fixed the bug, but somehow the fix never made it into CVS. Your example doesn't use the chordChanges = #t feature It does use the feature. I wrote chords for all of the notes, and Lilypond decides which ones to print. Only chords changes are to be printed. That works fine throughout, except at the beginning of the second ending. There Lilypond skips the chord even though it is a change. That is the bug. My example is very short and contrived, of course. In real music there could be hundreds of places where chords are correctly skipped. Did you try chordChanges = #f ? I believe it will make your example do exactly what you want. No, it is wrong. It prints chords all over the place that I do not want it to print. With chordChanges = ##t everything is correct, except in the case where the bug occurs. Indeed I just tried it and it does exactly what you said you wanted it to. To be exact the following works: No, your example does not do what I want. I want Lilypond only to print chord changes. Your example prints chords even when they are not changes. Lilypond's chordChanges feature works great for that. Except that I am reminding the Lilypond team that there is still a bug in the case I pointed out. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: fraction-tuplet-formatter
On 8/5/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello since the version 2.9.12 i am having this error : Unbound variable : fraction-tuplet-formatter since i use it in conetxt as tupletNumberFormatFunction = #fraction-tuplet-formatter i am using the latest dev release 2.9.14-1 om Macosx ppc I beleive it is related to Trevor's changes. Hey Karim, Yeah, I worked with Han-Wen on 2.9.12 to make it possible to format nested tuplets independently -- you can, for example, now use fraction formatting on an outer tuplet and use single-digit formatting on the inner tuplets. Han-Wen's implementation works great and tupletNumberFormatFunction is now deprecated. Try running convert-ly on your input file, making sure that \version 2.9.12 appears at the top of your file. Then examine the output of convert-ly to see the new structures that are available. *(By the way i have visited your site Trevor, great stuff! tell me when u finish your piece.) Yeah, thanks! That piece actually finished a week ago before I left for Darmstadt. And it was a big hit with its dedicatee, the mind-blowingly good flutist Carin Levine. I'll share with the whole list sometime later this week because lily was a *huge* factor in my getting that piece done ... (Oh, and if anyone's flying to the UK or US in the next couple of days, for the love of god don't try to carry any shampoo through security.) -- Trevor Bača [EMAIL PROTECTED] ... like the dew, or like lightning ... ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Chord changes over repeat alternatives
Yitz Gale wrote: Paul Scott wrote: I don't think it's a bug in my understanding of how Lilypond works. It is definitely a bug. See below. I still don't think so. I have been using LilyPond for at least 4 years and have produced many lead sheets and music with chord names. The behavior described in the documentation gets the job done even if you disagree with how it should work. I believe you are expecting more than the developers had in mind. The goal of this program is to engrave music not interpret it. Also, see the the thread in July 2004 on this list in which the developers confirmed that this is a bug. Eric Sandberg agreed to list it as a bug. He said he won't be available for a while. I'll bet he admits it's not a bug when this is all over. The behavior described by the original poster is exactly the behavior I expect from LilyPond for both chords and notes. LilyPond is not Finale or anything else. It pays no attention to endings or repeat as far as notes or chordnames. The only thing LilyPond knows is bar after bar. They even seem to have fixed the bug, but somehow the fix never made it into CVS. Han-Wen only says it didn't get committed to the bug list. There is no mention of a fix in that thread. Your example doesn't use the chordChanges = #t feature It does use the feature. I wrote chords for all of the notes, and Lilypond decides which ones to print. Only chords changes are to be printed. That works fine throughout, except at the beginning of the second ending. There Lilypond skips the chord even though it is a change. That is the bug. My example is very short and contrived, of course. In real music there could be hundreds of places where chords are correctly skipped. Your example works correctly. If chordChanges is false (default) the F's occur 3 times just as you say. If chordChanges is true the 2nd and 3rd F's are omitted because they are the same chord. Again as much as you might like the endings have nothing to do with it. Did you try chordChanges = #f ? I believe it will make your example do exactly what you want. No, it is wrong. It prints chords all over the place that I do not want it to print. With chordChanges = ##t everything is correct, except in the case where the bug occurs. If you can carefully describe what you want different than the current behavior I can help you get it. Indeed I just tried it and it does exactly what you said you wanted it to. To be exact the following works: No, your example does not do what I want. I want Lilypond only to print chord changes. Then why did you put 3 F's in a row. F to F is not a change. Your example prints chords even when they are not changes. Only when I set chordChanges to false. Lilypond's chordChanges feature works great for that. I agree. Except that I am reminding the Lilypond team that there is still a bug in the case I pointed out. As pointed out above Eric agreed to put it on the bug list but he's not even the bugmeister any more. We'll see what Graham or someone else has to say here. HTH, Paul ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
