transpose fails to transpose the pitchedTrill notehead
I'm not top posting.
Hello, the trill note head (resp. pitch) of a pitchedTrill is no longer
transposed (as in 2.14.2).
Tested on a Win7/64 Computer.
\version 2.15.36
{ \transpose c as' { \pitchedTrill e'4\startTrillSpan fis' r\stopTrillSpan } }
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: transpose fails to transpose the pitchedTrill notehead
Arnold arnold.we...@siemens.com writes:
I'm not top posting.
Hello, the trill note head (resp. pitch) of a pitchedTrill is no longer
transposed (as in 2.14.2).
Tested on a Win7/64 Computer.
\version 2.15.36
{ \transpose c as' { \pitchedTrill e'4\startTrillSpan fis' r\stopTrillSpan } }
New issue 2484
Patch: Let pitched trills in articulations be transposed as well
http://code.google.com/p/lilypond/issues/detail?id=2484
It turns out that the example file
\version 2.15.34
\new Voice
{ \transpose c as' { \pitchedTrill e'4\startTrillSpan fis' r\stopTrillSpan }
{ \pitchedTrill e'4\startTrillSpan fis' r\stopTrillSpan }
}
still gives a strange result with the fix applied: the first trill pitch
gets an explicit natural accidental even though this would be part of
the surrounding key signature. Removing \pitchedTrill, \startTrillSpan,
and \stopTrillSpan does not result in similar spurious accidentals, so
it would appear to be an artifact of the pitched trill code.
This is a separate issue, however, and in contrast to your issue not
likely a regression.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: transpose fails to transpose the pitchedTrill notehead
David Kastrup d...@gnu.org writes:
Arnold arnold.we...@siemens.com writes:
I'm not top posting.
Hello, the trill note head (resp. pitch) of a pitchedTrill is no longer
transposed (as in 2.14.2).
Tested on a Win7/64 Computer.
\version 2.15.36
{ \transpose c as' { \pitchedTrill e'4\startTrillSpan fis'
r\stopTrillSpan } }
New issue 2484
Patch: Let pitched trills in articulations be transposed as well
http://code.google.com/p/lilypond/issues/detail?id=2484
It turns out that the example file
\version 2.15.34
\new Voice
{ \transpose c as' { \pitchedTrill e'4\startTrillSpan fis' r\stopTrillSpan }
{ \pitchedTrill e'4\startTrillSpan fis' r\stopTrillSpan }
}
still gives a strange result with the fix applied: the first trill pitch
gets an explicit natural accidental even though this would be part of
the surrounding key signature. Removing \pitchedTrill, \startTrillSpan,
and \stopTrillSpan does not result in similar spurious accidentals, so
it would appear to be an artifact of the pitched trill code.
This is a separate issue, however, and in contrast to your issue not
likely a regression.
And not related to transposition:
\version 2.15.34
\new Voice
{ \pitchedTrill c''4\startTrillSpan d'' r\stopTrillSpan }
is sufficient for getting an unneeded natural here. Huh.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: transpose fails to transpose the pitchedTrill notehead
David Kastrup d...@gnu.org writes:
David Kastrup d...@gnu.org writes:
Arnold arnold.we...@siemens.com writes:
I'm not top posting.
Hello, the trill note head (resp. pitch) of a pitchedTrill is no longer
transposed (as in 2.14.2).
Tested on a Win7/64 Computer.
\version 2.15.36
{ \transpose c as' { \pitchedTrill e'4\startTrillSpan fis'
r\stopTrillSpan } }
New issue 2484
Patch: Let pitched trills in articulations be transposed as well
http://code.google.com/p/lilypond/issues/detail?id=2484
It turns out that the example file
\version 2.15.34
\new Voice
{ \transpose c as' { \pitchedTrill e'4\startTrillSpan fis' r\stopTrillSpan }
{ \pitchedTrill e'4\startTrillSpan fis' r\stopTrillSpan }
}
still gives a strange result with the fix applied: the first trill pitch
gets an explicit natural accidental even though this would be part of
the surrounding key signature. Removing \pitchedTrill, \startTrillSpan,
and \stopTrillSpan does not result in similar spurious accidentals, so
it would appear to be an artifact of the pitched trill code.
This is a separate issue, however, and in contrast to your issue not
likely a regression.
And not related to transposition:
\version 2.15.34
\new Voice
{ \pitchedTrill c''4\startTrillSpan d'' r\stopTrillSpan }
is sufficient for getting an unneeded natural here. Huh.
URL:http://code.google.com/p/lilypond/issues/detail?id=524#c6
The question
What does Gardner Read have to say about pitched trills for natural
notes, if anything?
has not been addressed as far as I can see.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: issues 2266 and 1721
Le 15/04/2012 14:56, Phil Holmes disait :
- Original Message - From: Jean-Charles Malahieude
lily...@orange.fr
To: Phil Holmes m...@philholmes.net
Cc: Lily Bugs bug-lilypond@gnu.org; lilypond-devel
lilypond-de...@gnu.org
Sent: Saturday, April 14, 2012 5:46 PM
Subject: Re: issues 2266 and 1721
It might have something to do with the way both glossary and snippet
are built: I just noticed, on fresh make doc on staging (as of
312f7ebc83ec9fb8cbbddfcf78b65a8502c16ab2 ), that
music-glossary.splittexi.log weight is 0 byte, but
snippets.splittexi.log is 190.9 Kio (1618 lines).
I reckon I now know why this is happening. We get the same error if the
text of pitches.itely is cut down to:
@node Hauteurs
@section Hauteurs
@translationof Pitches
Morceaux choisis :
@rlsrnamed{Pitches,Hauteurs}.
The error goes away if @translationof Pitches is changed to
@translationof Pitcher. So I think @rlsrnamed{Pitches,Hauteurs} is
translated automatically to @rlsrnamed{Hauteurs,Hauteurs} and the system
can't then find the node Hauteurs.
What do you think?
This might make one point.
But what is still strange is:
in fr/learning/common-notation.itely I read
@node Altérations et armure
@subsection Altérations et armure
@translationof Accidentals and key signatures
and, in fr/notation/pitches.itely,
@rlearning{Altérations et armure}
which points to
learning/accidentals-and-key-signatures.fr.html
never to learning/Altérations-et-armure.fr.html which by the way doesn't
exist.
So, why is it tempted to translate the base file name only when dealing
with snippets?
Don't forget I've no skill in programming; I'm just trying to understand
what is going on. Would it be possible that the origin being the macros
at the head of snippets.tely? or something weird in conjunction with
extract_texi_filenames.py?
I think that if everything goes well,
Documentation/snippets.splittexi.log should not weight that much with
all those lines like
** `Pitches' is up for `Pitches: Separating key cancellations from key
signature changes', but has no menu entry for this node
** No node following `Pitches: Separating key cancellations from key
signature changes' in menu, but `Pitches: Transposing pitches with
minimum accidentals (Smart transpose)' follows in sectionning
Cheers,
Jean-Charles
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
