Issue 3137: 2 Errors in german translation of lilypond.org (issue 7338047)
https://codereview.appspot.com/7338047/diff/1/Documentation/de/web/community.itexi File Documentation/de/web/community.itexi (right): https://codereview.appspot.com/7338047/diff/1/Documentation/de/web/community.itexi#newcode307 Documentation/de/web/community.itexi:307: Fehlermeldungen, die nicht mit dem Problem im Zusammenhang stehen, Ich würde die Satzstellung umbauen: Fehlermeldungen produziert werden, die nicht ... https://codereview.appspot.com/7338047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Issue 3194 in lilypond: crash when too many bars requested
2013/2/18 :
>
> Comment #2 on issue 3194 by d...@gnu.org: crash when too many bars requested
> http://code.google.com/p/lilypond/issues/detail?id=3194
>
> Issue 1475 was reported fixed in version 2.13.47. Can someone check whether
> a) version 2.13.47 will fail with the input
>
> \repeat unfold 651 { c'1 c \break }
> (the number may be different depending on available memory, but using 3
> times as much is likely a safe bet given the apparently exponential
> behavior)
I downloaded lilypond-2.13.47.tar.gz from
http://download.linuxaudio.org/lilypond/source/v2.13/
and self-compiled it within LilyDev.
I tested
{
\repeat unfold xy { c'1 c \break }
\bar "|."
}
with different values for xy.
For 2.13.47 I had at least one successful run with xy = 1263, but it
was _not_ reproducable. After testing several other values, it failed
testing the same value (xy = 1263).
??
xy = 2500
returns:
[...]
Preprocessing graphical objects...terminate called after throwing an
instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted
xy = 5000
[...]
returns:
Preprocessing graphical objects...terminate called after throwing an
instance of 'std::length_error'
what(): vector::_M_fill_insert
Aborted
xy = 1
returns:
[...]
Preprocessing graphical objects...Segmentation fault
With 2.12.3, 2.16.1, 2.17.10
I had one successful run with xy = 1263
But I didn't repeat the test and didn't test other values.
With 2.14.2 I aborted compilation.
Every compilation with every tested versions tooks a very long amount,
up to ~20 min. 2.14.2 maybe longer.
-Harm
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3174: Implement \accidental markup and \pitched command for transposable accidental markups (issue 7323060)
ArnoldTheresius writes: > Thomas Morley wrote >> On 2013/02/14 09:21:07, dak wrote: >> >>> So the message is "we can do", but we still need to figure out _what_ >>> we can do. Proposals? >> >> Well, currently I don't have a good idea. >> >> Though, some time ago Arnold posted his approach on -user: >> http://lists.gnu.org/archive/html/lilypond-user/2012-06/msg00278.html >> direct link to his code: >> http://old.nabble.com/file/p33991423/pitchedArticulations.ly >> >> Perhaps this might be useful, I hadn't a closer look, though. >> >> https://codereview.appspot.com/7323060/ > > I'll try to collect the information: > > The 'pitched articulation' is: > - add the accidental of a pitch above the articulation symbol > and or > - ... below the articulation symbol Not really. "Pitched" articulations don't just concern an accidental (see pitched trills in the manual), but the case we are concerned about right here are accidentals stacked with an articulation. > This (these) pitch(es) may be defined by: > - entering the pitch > - specifying the interval from the ornamented note (notehead) We don't specify intervals elsewhere in LilyPond. There is not even a useful entry form for that. > most common usage is: a minor or major second above or below a single > tone, not assigned to a chord. I don't really think anybody thinks about ornamentations with respect to their "intervals" but rather with respect to the current scale. That might be different with atonal music, but I don't think embellishments belong in there. > only "delayed turn / reverseturn" is usually placed on a skip, where > no pitch is available to apply the interval. Maybe. > Formatting: > - the accidental is usually some smaller in size than the articulation is. > - Mostly (prall, mordent, turn, reverseturn) the accidentals are > horizontally centered, vertically as close as the extent allows. > - for the trill two positions are suitable: > - horizontally right aligned, vertically the accidental close above the > 'r' of the 'tr', thus overlapping into the 'tr' symbol extent > - horizontally appended to the right of the 'tr' symbol, the accidental is > raised by some value > The best method for this combining of the glyphs seem to be done by a > stencil function. Probably. And arguably the default stencil function should be able to do that. > Additional: > - It may be required in some situation to put some parentheses (or > brackets to indicate an editorial note) around the added accidentals. Maybe. > Syntax for the user to enter: > - commands like \majorPrall, \minorPrall, \majorMordent, > \majorMinorTurn, \minorNeutralReverseturn (which define the offset > interval) seem (to me) to be the most simple way to specify those > pitched articulations, whenever they are aligned to exactly one note. I consider them quite inappropriate. For one thing, they are unnatural. If I typeset a c\major scale with trills, I don't want to remember which steps of the scale are whole and which are half notes. For another, intervals don't lead to enharmonic unambigous notes. > - In other situations (e.g. delayed turn, quarter tone trill) it may > be the best to enter the pitch(es) manually. One possible style might > be '\pitchedArticulation [pitch-up] [pitch-down] [articulation > symbol]', where pitch-up and pitch-down may also be the locial value > 'false' to indicate 'no articulation to put here'. That does not match LilyPond's typical input patterns. I'd use something like \pitched and \underpitched here (\submarinePitched being a bit too long). Just use what is needed. A double accidental is worth the double trouble entry. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Caches the interior skylines of vertical axis groups and systems. (issue 7185044)
On 2013/02/15 06:37:20, mike7 wrote: https://codereview.appspot.com/7185044/diff/32003/input/regression/tuplet-number-outside-staff-positioning.ly#newcode15 > input/regression/tuplet-number-outside-staff-positioning.ly:15: > \override TupletBracket.Y-offset = > #ly:side-position-interface::calc-outside-staff-y-offset > This is indicating a fundamental design problem: this override is not > related to the topic of the regtest. If it is necessary for getting the > desired result, it will be necessary in a whole _lot_ of user-created > situations. But it is not an easily user-accessibly override, and it is > not documented in normal user documentation. > > This suspiciously looks like tampering with unrelated regtests in order > to mask fundamental problems from review. Can you explain why this is > not the case? Your question gets to the core of the logic of the patch, so I'll explain it and then people can comment upon how that links up with this regtest. In LilyPond, about 85% of grob properties are set as the result of the evaluation of a callback or the use of a rote value. [...] Mike, that's a whole bunch of smoke screen. The fact is that your change, which purports to be just some "factoring" of stuff by its description, breaks existing and documented functionality. And you offer no reason for that. Now, LilyPond, for various callbacks, other properties must be set for those callbacks to make sense. For example, if I do: \override NoteHead #'stencil = #ly:text-interface::print Nothing will happen. But if I do: \override NoteHead #'text = #"foo" \override NoteHead #'stencil = #ly:text-interface::print The NoteHead will be printed as foo. This is exactly what we're seeing in the regtest tuplet-number-outside-staff-positioning.ly. No, it is not. A callback is set for Y-offset that allows the grob to be positioned outside the staff. But, just as the text interface needs to know what text to print, the side-position-interface needs to know what outside-staff-priority to use to place the grob. Thus the use of two overrides instead of one. You got your logic backwards. The _preexisting_ override in the regtest overrides outside-staff-priority. This is a documented way of changing the default order of outside-staff elements. There are 17 grobs with a preassigned outside-staff-priority. There are 369 occurences of outside-staff-priority in the LilyPond code base. You break that. You use callbacks that ignore outside-staff-priority and thus break existing functionality. And then you revert to the previous callbacks in the regtests in order to mask that you are breaking functionality. You can't just throw functionality overboard when you are "improving" things and tell people they have to revert to the old code if they care about that functionality. After all, it is totally unclear how elements with the old callbacks and elements with the new outside-staff-priority ignoring callbacks will even combine. A music function could be done in the form of: \addOutsideStaffPriorityToGrob #'TupletBracket #100 that rolls the two overrides into one. This is a UI issue about which I have not thought yet but that absolutely deserves attention. Then give it attention. Heed outside-staff-priority properly in your versions of the callbacks. Until this is done, this patch is not ready for maintime. This is a showstopper. And messing with the regtests in order to hide this is not a proper way of addressing this showstopper. https://codereview.appspot.com/7185044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Avoid excessive number of dots in chords (#3179). (issue 7319049)
... next patch set will follow soon.
https://codereview.appspot.com/7319049/diff/7001/lily/dot-column.cc
File lily/dot-column.cc (right):
https://codereview.appspot.com/7319049/diff/7001/lily/dot-column.cc#newcode206
lily/dot-column.cc:206: p += (int) robust_scm2double
(dp.dot_->get_property ("staff-position"), 0.0);
On 2013/02/18 08:06:45, Keith wrote:
That is why I suggested building allowed_positions using p:
allowed_positions.add_point(p)
You can extend this to have a separate allowed_positions for each
chord, finding the Stem of the Dots as you did above.
But the `desired position' is not what I need! Following Gould, I
really need the extrema of the chord's note head positions, slightly
extended at the top and the bottom in case those notes are sitting on a
line.
https://codereview.appspot.com/7319049/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Avoid excessive number of dots in chords (#3179). (issue 7319049)
https://codereview.appspot.com/7319049/diff/7001/lily/dot-column.cc
File lily/dot-column.cc (right):
https://codereview.appspot.com/7319049/diff/7001/lily/dot-column.cc#newcode206
lily/dot-column.cc:206: p += (int) robust_scm2double
(dp.dot_->get_property ("staff-position"), 0.0);
p is the position of the Dots, just before-collision resolution by this
function. This is what I was calling the "desired position" with any
setting of Dots.staff-position being included here.
That is why I suggested building allowed_positions using p:
allowed_positions.add_point(p)
You can extend this to have a separate allowed_positions for each chord,
finding the Stem of the Dots as you did above.
https://codereview.appspot.com/7319049/diff/7001/lily/dot-column.cc#newcode210
lily/dot-column.cc:210: cfg[p] = dp;
This enters a data structure dp representing a movable Dots into the
Dot_configuration cfg and associates it with the desired position 'p'.
(cfg is implemented as a map, cfg[p] = dp2 would enter a different Dots
at the same desired position.)
https://codereview.appspot.com/7319049/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3174: Implement \accidental markup and \pitched command for transposable accidental markups (issue 7323060)
Thomas Morley wrote > On 2013/02/14 09:21:07, dak wrote: > >> So the message is "we can do", but we still need to figure out _what_ >> we can do. Proposals? > > Well, currently I don't have a good idea. > > Though, some time ago Arnold posted his approach on -user: > http://lists.gnu.org/archive/html/lilypond-user/2012-06/msg00278.html > direct link to his code: > http://old.nabble.com/file/p33991423/pitchedArticulations.ly > > Perhaps this might be useful, I hadn't a closer look, though. > > https://codereview.appspot.com/7323060/ > > ___ > lilypond-devel mailing list > lilypond-devel@ > https://lists.gnu.org/mailman/listinfo/lilypond-devel I'll try to collect the information: The 'pitched articulation' is: - add the accidental of a pitch above the articulation symbol and or - ... below the articulation smybol This (these) pitch(es) may be defined by: - entering the pitch - specifying the interval from the ornamented note (notehead) most common usage is: a minor or major second above or below a single tone, not assigned to a chord. only "delayed turn / reverseturn" is usually placed on a skip, where no pitch is available to apply the interval. Formatting: - the accidental is usually some smaller in size than the articulation is. - Mostly (prall, mordent, turn, reverseturn) the accidentals are horizontally centered, vertically as close as the extent allows. - for the trill two positions are suitable: - horizontally right aligned, vertically the accidental close above the 'r' of the 'tr', thus overlapping into the 'tr' symbol extent - horizontally appended to the right of the 'tr' symbol, the accidental is raised by some value The best method for this combining of the glyphs seem to be done by a stencil function. Additional: - It may be required in some situation to put some parentheses (or brackets to indicate an editorial note) around the added accidentals. Syntax for the user to enter: - commands like \majorPrall, \minorPrall, \majorMordent, \majorMinorTurn, \minorNeutralReverseturn (which define the offset interval) seem (to me) to be the most simple way to specify those pitched articulations, whenever they are aligned to exactly one note. - In other situations (e.g. delayed turn, quarter tone trill) it may be the best to enter the pitch(es) manually. One possible style might be '\pitchedArticulation [pitch-up] [pitch-down] [articulation symbol]', where pitch-up and pitch-down may also be the locial value 'false' to indicate 'no articulation to put here'. I hope, this helps. ArnoldTheresius -- View this message in context: http://lilypond.1069038.n5.nabble.com/Issue-3174-Implement-accidental-markup-and-pitched-command-for-transposable-accidental-markups-issue-tp140921p141114.html Sent from the Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
