Re: \pp \ppp \ff \fff still look bad
On Friday 20 May 2005 12.06, Graham Percival wrote:
> old bug from the manual (dynamics 6.5.3)
>
> BTW, I don't consider any of these bugs from the manual to be
> release-critical. Most of them are quite old; I just happened to
> be reminded of them when I was editing basic-notation.
>
> % 2.5.24+ (cvs) dynamic marks overlap
> \layout{ raggedright=##t}
> {
> c''4\pp c''4\ppp c''4\ff c''4\fff
> }
>
It's in the bug database also, c-pp-ppp.ly.
Erik
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
double-note with percent repeat
(from the manual, 6.7.3)
% 2.5.24+ (cvs), weird double-note with percent repeat.
{
\unfoldrepeats {
\repeat tremolo 8 {c'32 e' }
\repeat percent 4 { c''8 d'' }
}
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
\pp \ppp \ff \fff still look bad
old bug from the manual (dynamics 6.5.3)
BTW, I don't consider any of these bugs from the manual to be
release-critical. Most of them are quite old; I just happened to
be reminded of them when I was editing basic-notation.
% 2.5.24+ (cvs) dynamic marks overlap
\layout{ raggedright=##t}
{
c''4\pp c''4\ppp c''4\ff c''4\fff
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
another boundary-box manual problem
The top of the bracket gets cut off:
http://lilypond.org/doc/v2.5/Documentation/user/out-www/lilypond/
Arpeggio.html
{
\arpeggioBracket
\arpeggio
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Why do chords print below staff?
Erik Sandberg wrote:
On Wednesday 18 May 2005 17.45, Mats Bengtsson wrote:
Tricky one! I send a copy to bug-lilypond, both since the
difference between \chords and \chordmode is completely undocumented
(except for the NEWS file for 2.4) and since I don't realize why
the chords end up below the stave.
I stripped down your example to the following, where the chords
still are printed below the staff.
\version "2.4.0"
melody = \relative c'' {
a4 a8 a g4 g |
f2 f |
}
guitar = \new ChordNames \chordmode {
f2 c |
f1 |
}
\score {
<<
\new ChordNames {
\set chordChanges = ##t
\guitar
}
\new Staff \context Voice = mel {
\melody
}
}
Note that I replaced '\chords' with '\new ChordNames \chordmode'
(which is equivalent) in an attempt to understand what's going on.
The chords will move up above the stave if you do at least one of
the following:
- Replace 'guitar = \new ChordNames \chordmode' with
'guitar = \chordmode'
- Move the property setting of chordChanges into
guitar = \new ChordNames \chordmode {...}
/Mats
If you expand the guitar variable, you might see what's going on:
\score {
<<
\new ChordNames {
\set chordChanges = ##t
\new ChordNames \chordmode {
f2 c |
f1 |
}
}
\new Staff \context Voice = mel {
\melody
}
>>
}
The second '\new ChordNames' will create a _new_ ChordNames context. The \set
chordChanges=##t command will only be effective in the context from the
_first_ \new ChordNames (which will contain no notes).
Of course, but your explanation does not say why the second ChordNames
context appears below the Staff context. However, Han-Wen provided the
missing piece of information, namely that the inner ChordNames context
is treated as if it was created "after" the Staff context.
So, the intuitive notion that contexts are ordered in the order they
appear in the score is actually very tricky. The rules I have seen
so far are:
A) If two contexts are created at different (time) locations in the
piece, then the one created first is processed first.
B) If two contexts are created at the same time location, then the
one that is created first within \score{...} (when reading from
top to bottom) is processed first.
C) When interpreting rule A), Property settings within a context are
considered to happen after the creation of the score but before the
first note of the piece.
In mathematical terms, these rules clearly define a partial order.
However, it's not clear to me if they also define a complete order
or if there's some more tricky special case to be considered.
Thanks to Han-Wen who hinted to rule C), which I learnt today.
/Mats
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: input/regression/tuplet-nest.ly broken with 2.5.24+ (cvs)
On 19-May-05, at 3:21 PM, Han-Wen Nienhuys wrote: Graham Percival wrote: The outer tuplet doesn't get displayed. can't reproduce. Ah, I see. It's a boundary box issue -- in the web docs http://lilypond.org/doc/v2.5/input/regression/out-www/collated- files.html it's cut off exactly below the outer tuplet, so there's no hint that the outer tuplet exists at all. Cheers, - Graham ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: input/regression/tuplet-nest.ly broken with 2.5.24+ (cvs)
On Friday 20 May 2005 00.21, Han-Wen Nienhuys wrote: > Graham Percival wrote: > > The outer tuplet doesn't get displayed. > > can't reproduce. Neither can I, however it does occur here: http://lilypond.org/doc/v2.5/input/regression/out-www/lily-899502903.png Han-Wen, does it disappear if you remake the web docs? Erik ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
