Re: Feature request: Tuplet bracket style settings
"bruys ." wrote in message news:banlktinz8-p51gg01wpxsn3a2zt8vn+...@mail.gmail.com... *The current situation* http://code.google.com/p/lilypond/issues/detail?id=1631 -- Phil Holmes Bug Squad ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1631 in lilypond: Feature request: Tuplet bracket style settings
Status: Accepted
Owner:
Labels: Type-Enhancement Priority-Medium
New issue 1631 by philehol...@googlemail.com: Feature request: Tuplet
bracket style settings
http://code.google.com/p/lilypond/issues/detail?id=1631
Requested by Bruys:
*The current situation*
a) Lilypond's default placement of tuplet brackets is from the stem of the
first note to the stem of the last note, if the bracket is on the stem side
(see second and fourth examples in the accompanying png file). If the
tuplet bracket is on the notehead side, the bracket extends from the
left-hand edge of the first notehead to the right-hand edge of the last
notehead (see the fourth example in the png file). It is possible to make
the bracket extend for the duration of the notes, so that it extends past
the last notehead (see the third example).
b) The numeral (here '3') is placed in the visual centre of the bracket
(all examples).
*The proposed features*
a) It is desired to be able to change the style of the bracket, without
reverting to ad hoc manual settings. In particular, a common style is for
the bracket to extend from the left-hand edge of the first notehead to the
right-hand edge of the last notehead, even when the bracket is on the stem
side (as in the fifth example). Although this is not a universally adopted
style, Elaine Gould in "Behind Bars" says:
"A bracket should extend from the left-hand edge of the first notehead or
rest, to the right-hand edge of the final notehead or rest. It does not
encompass accidentals, grace notes or an arpeggio line that precede the
first note. When a final note is up-stemmed and has a tail (end of bar 2
*[in her figure, not reproduced here]*), the bracket still finishes with
the stem (i.e. the right-hand edge of the note), not with the tail *[figure
omitted]* In some editions brackets finish just after the tail: this saves
vertical space, as the end notch can be lowered after the stem.*
In Gardner Read, *Music Notation*, this also seems to be the general
practice (although in my copy the bracket lengths are not consistent). The
figures in the current Wikipedia article on tuplets also uses this style,
http://en.wikipedia.org/wiki/Tuplet.
b) Although placement of the numeral in the visual centre of the bracket is
a good default, it is sometimes desirable to have the numeral placed at the
rhythmic centre of the tuplet. It is desired that changing a setting could
achieve this. Elaine Gould again:
When one part of a beat is disproportionately long visually, traditionally
the numeral remains at the visual centre of the group. However, where there
are complex groups of tuplets, it is more helpful if the numeral moves to
the rhythmic centre of the group, even if this is visually
off-centre*[figure omitted, consisting of a triplet containing two
quaver rests and four demisemiquavers, and another quintuplet containing
four semiquavers, a dotted minim, and a crotchet rest]
The examples are generated from the following:
%% triplet examples
\version "2.12.3"
notes = {
%% Default behaviour
\times 2/3 { b'8[
\times 2/3 { b'16 b' b' }
b'8]
}
%% With both tuplet brackets
\override TupletBracket #'bracket-visibility = ##t
\times 2/3 { b'8[
\times 2/3 { b'16 b' b' }
b'8]
}
%% With tuplet bracket extending to duration of notes
\set tupletFullLength = ##t
\times 2/3 { b'8[
\times 2/3 { b'16 b' b' }
b'8]
}
\set tupletFullLength = ##f
%% With inner tuplet bracket on the upper, notehead, side
\times 2/3 { b'8[
\once \override TupletBracket #'direction = #UP
\times 2/3 { b'16 b' b' }
b'8]
}
%% With manual change to the lower bracket length
\times 2/3 { \once \override Voice.TupletBracket #'shorten-pair = #'(-0.2
. -1.5)
b'8[
\once \override TupletBracket #'direction = #UP
\times 2/3 { b'16 b' b' }
b'8]
}
}
\score {
\notes
}
Attachments:
Tuplets.png 5.1 KB
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1631 in lilypond: Feature request: Tuplet bracket style settings
Comment #1 on issue 1631 by v.villen...@gmail.com: Feature request: Tuplet bracket style settings http://code.google.com/p/lilypond/issues/detail?id=1631 Another feature that could be added to LilyPond wrt tuplet printing, is that in many printed scores, tuplets are not indicated with a bracket but rather some kind of a slur-like Bezier curve. If memory serves me right, this feature is already supported in musicXML, and I remember having seen a comment about that, probably from Reinhold in musicxml2ly (or maybe it was in Frescobaldi's source code? Either way, I can't find it right now). ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1612 in lilypond: Change staff produces long stems
Updates: Labels: -Patch-review Patch-new Comment #15 on issue 1612 by percival.music.ca: Change staff produces long stems http://code.google.com/p/lilypond/issues/detail?id=1612 New patches from Mike here: http://codereview.appspot.com/4423062/ http://codereview.appspot.com/4431058/ I'm doing a regtest comparison right now. These patches obsolete James' earlier doc patch. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1612 in lilypond: Change staff produces long stems
Updates: Labels: -Patch-new Patch-review Comment #16 on issue 1612 by percival.music.ca: Change staff produces long stems http://code.google.com/p/lilypond/issues/detail?id=1612 Clean regtests, ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1618 in lilypond: unpredictable placement of rests
Comment #1 on issue 1618 by percival.music.ca: unpredictable placement of rests http://code.google.com/p/lilypond/issues/detail?id=1618 I think it happened earlier than 2.13.48 -- maybe even before 2.12 or 2.10, meaning that it's not Critical. I tried to do a bisect, but I ended up looking at a doc translation merge that had nothing to do with code at all! It's really unfortunate that we can't run valgrind on lilypond; it's great for finding the use of uninitalized variables. Does anybody have any other favorite static code analysis tool which can identify uninitalized variables? (the alternative is to spend half an hour seriously looking at variables in the relevant part of the source code; I may give that a shot if nobody has any other suggestions before tomorrow) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1618 in lilypond: unpredictable placement of rests
You can run valgrind on lilypond. You just need to disable the
warnings regarding garbage collection.
On Sun, Apr 17, 2011 at 5:24 AM, wrote:
> Status: Accepted
> Owner:
> Labels: Type-Defect Priority-Critical
>
> New issue 1618 by percival.music.ca: unpredictable placement of rests
> http://code.google.com/p/lilypond/issues/detail?id=1618
>
> This is split from issue 1609 (that issue was specifically about the problem
> we saw in partcombine-midi.ly)
>
>
> As the examples below illustrate, placement of such rests still changes
> unpredictably. The score in example 2 produces different output with the
> two command lines
> lilypond test.ly
> lilypond test.ly test.ly
> while version 2.12.3 produces the same output in either case. Both versions
> produce a warning "too many colliding rests". See also issue 1547 and issue
> 384.
>
> The variation in position of the rests appeared somewhere between 2.13.48
> and .54
>
>
> The completion- engravers are not essential, it is simply the fact that
> LilyPond does not have a rule to place simultaneous rests with a note of
> different durations (see issue 1547). Smaller example, which produces
> different output depending on whether the file is alone on the command line
> or second in a list of .ly files:
>
> \version "2.12.3"
> \new Staff <<
> \new Voice {
> \voiceOne
> r1 r1
> }
> \new Voice {
> \voiceThree
> c'2 e' g' b'
> }
> \new Voice {
> \voiceTwo
> r1 r1
> }
>
>
>
>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> http://lists.gnu.org/mailman/listinfo/bug-lilypond
>
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: http://lilypond.org/doc/v2.13/Documentation/essay-big-page.html
On Thu, Apr 21, 2011 at 3:49 PM, Trevor Daniels wrote: > > > One or two quibbles with the language on this page: >> > > I'll fix the typos. > > Thanks, Trevor! Someone must have clumsy typing ... oops! ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1618 in lilypond: unpredictable placement of rests
Updates: Labels: -Priority-Critical Priority-High Comment #2 on issue 1618 by k-ohara5...@oco.net: unpredictable placement of rests http://code.google.com/p/lilypond/issues/detail?id=1618 Quite possibly the problem existed in 2.13.48, and my testing missed it. Testing for inconsistent output is difficult, because the inconsistent output is sometimes by chance consistent. Other reasons to make this non-critical are: 1) it occurs only in complicated cases where LilyPond needs the user's help, probably substitution skips or pitched rests, to produce easily-readable output, as logged in issue 1547 and issue 384. 2) LilyPond issues a collision warning referring to rests that have the inconsistent output. So even if output consistent with 2.12, it was only consistently /good/ by accident. I don't know any approach better than debug printf()s in rest-collision-engraver.cc. This issue looks very much like issue 1031. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1547 in lilypond: Too many colliding resrts
Comment #1 on issue 1547 by k-ohara5...@oco.net: Too many colliding resrts
http://code.google.com/p/lilypond/issues/detail?id=1547
Pitched rests {\voiceFour a'8 b'\rest} can produce good output but still
issue the warning.
Better behavior would be to suppress the warning if the "too many
colliding" rests are explicitly pitched.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1613 in lilypond: Beamed stems too long when avoiding low note in other voice
Updates: Labels: Patch-review Comment #6 on issue 1613 by hanw...@gmail.com: Beamed stems too long when avoiding low note in other voice http://code.google.com/p/lilypond/issues/detail?id=1613 http://codereview.appspot.com/4450052 regtest looks clean. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1612 in lilypond: Change staff produces long stems
Comment #17 on issue 1612 by n.putt...@gmail.com: Change staff produces
long stems
http://code.google.com/p/lilypond/issues/detail?id=1612
Unfortunately, Mike's patch doesn't fix these cases (they're probably a
related, but separate bug):
<<
\new Staff = up \relative c' {
c8 c c c
}
\new Staff = down \relative c' {
s8 c c c
\change Staff = up
}
<<
\new Staff = up \relative c' {
c8 c c c
}
\new Staff = down \relative c' {
s8 c c
\change Staff = up
c8
}
Attachments:
beam-staff-change-1.png 2.2 KB
beam-staff-change-2.png 3.1 KB
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Doc build segfault
Since yesterday, make doc is erroring on a segfault from Documentation/web/ly-examples/bach-schenker.ly although the .ly compiles fine if I load it into Frescobaldi. If anyone else is having the problem, I'll raise an issue. I deleted ~/lilypond-git then git init and git clone, then autogen.sh -- noconfigure, cd build (already present from the clone), ../configure , make && make doc. Came back after my show to find: GNU LilyPond 2.13.61 Changing working directory to: `./out-www' Processing `/home/colin/lilypond-git/Documentation/web/ly-examples/bach-schenker.ly' Parsing... Interpreting music... Preprocessing graphical objects... Finding the ideal number of pages... Fitting music on 1 page... Drawing systems... Layout output to `bach-schenker.ps'...make[3]: *** [out-www/bach-schenker.png] Segmentation fault make[3]: Leaving directory `/home/colin/lilypond-git/build/Documentation/web/ly-examples' make[2]: *** [out-www/ly-examples] Error 2 Colin -- The test of our progress is not whether we add more to the abundance of those who have much, it is whether we provide enough for those who have too little. -Franklin D. Roosevelt, 32nd US President (1882-1945) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
