LGTM :)
https://codereview.appspot.com/13223043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
https://codereview.appspot.com/6489086/diff/11/lily/accidental.cc
File lily/accidental.cc (right):
https://codereview.appspot.com/6489086/diff/11/lily/accidental.cc#newcode89
lily/accidental.cc:89: (my_stencil->smobbed_copy (), 0.0, Y_AXIS));
We need to check that my_stencil exists here, in case
Am 13.01.2013 19:31, schrieb m...@mikesolomon.org:
> … It is possible to do accidental configuration
> "scoring" with a priority queue, very much how we do slurs. But I have
> no clue how much this would slow the program down.
It is only an issue for chords with more than 2 accidentals, which
sho
> For complicated chords, I'm guessing that it is often the case that
> LilyPond's current algorithm will miss the optimum result in some
> subtle way. Given n accidentals (where accidental is the whole
> group of things next to a note, including cautionaries, parentheses
> etc.), there are n! or
On 13 janv. 2013, at 18:32, Noeck wrote:
> Hi,
>
> I found an article about music engraving* (in German):
> http://pian-e-forte.de/texte/pdf/notenschreiben01.pdf
>
> It claims a rule for accidental placement and shows some examples of how
> chord accidentals are order
On Fri, Sep 28, 2012 at 8:56 AM, wrote:
> http://codereview.appspot.com/6489086/diff/11/lily/accidental-placement.cc#newcode377
> lily/accidental-placement.cc:377: Real offset =
> -ape->horizontal_skylines_[RIGHT].distance (left_skyline);
> Both Mike and Janek thought the accidentals needed a bit
accidental spacing comparison posted as comment 4 in issue 2141
http://code.google.com/p/lilypond/issues/detail?id=2141#c4
On Fri, Sep 28, 2012 at 8:56 AM, wrote:
> Both Mike and Janek thought the accidentals needed a bit more padding
> for close intervals, so I think Janek should try horizon_pa
http://codereview.appspot.com/6489086/diff/11/lily/accidental-placement.cc
File lily/accidental-placement.cc (right):
http://codereview.appspot.com/6489086/diff/11/lily/accidental-placement.cc#newcode377
lily/accidental-placement.cc:377: Real offset =
-ape->horizontal_skylines_[RIGHT].distance (
Janek Warchoł writes:
> There were three patchsets (maybe more). If it looks catastrophic,
> I trust you - just revert it in staging and send me a short
> example w/ the regression and I'll work on it.
>
> It looks to me that this patch is way past staging, so i'm not sure if
> it mak
On Thursday, September 27, 2012, m...@mikesolomon.org wrote:
> On 27 sept. 2012, at 13:56, Janek Warchoł
> wrote:
> > Um, Mike, i've just checked and current master has many cases of bad
> > accidental placement - many accidentals are too close to each other.
> > For
>> Whoah, this was pushed and i didn't notice anything... and regtests
>> that James posted are no longer available to download. Pity.
>> I suppose that the final version of the patch changes some accidental
>> spacing, so i'll check it now.
>
> Um, Mike, i&#
that James posted are no longer available to download. Pity.
> I suppose that the final version of the patch changes some accidental
> spacing, so i'll check it now.
Um, Mike, i've just checked and current master has many cases of bad
accidental placement - many accidentals are too
On 8 sept. 2012, at 08:46, k-ohara5...@oco.net wrote:
> On 2012/09/08 05:28:02, Keith wrote:
>> now I measure it 2% /faster/ than master.
>
> Of course that makes no sense. I got confused of which executable I had
> when switching between patches. This patch is still about 6% slower
> than mas
On 2012/09/08 05:28:02, Keith wrote:
now I measure it 2% /faster/ than master.
Of course that makes no sense. I got confused of which executable I had
when switching between patches. This patch is still about 6% slower
than master, buy maybe worth it.
Also, 'accidental-single-double.ly' is b
Still looks great (except when Phil's computer cancels double-flats,
etc.) and now I measure it 2% /faster/ than master.
http://codereview.appspot.com/6489086/diff/8003/lily/accidental.cc
File lily/accidental.cc (right):
http://codereview.appspot.com/6489086/diff/8003/lily/accidental.cc#newcode
On 7 sept. 2012, at 10:11, k-ohara5...@oco.net wrote:
> The output looks very nice, even with half-sharps, reverse flats, etc.
> The patch makes compilation take 6% longer (depending on accidental
> density).
>
> The reverse flats don't get any extra space around their stems, but I
> haven't fin
The output looks very nice, even with half-sharps, reverse flats, etc.
The patch makes compilation take 6% longer (depending on accidental
density).
The reverse flats don't get any extra space around their stems, but I
haven't find a case where they need it, because they are placed in the
same o
Bah, Rietveld ate my message.
On Thu, Sep 6, 2012 at 11:55 AM, m...@mikesolomon.org
wrote:
>
>> I think adding horizontal padding may solve them fine.
>
> It may be more subtle than that.
Quite possible.
> Compile stuff with the most recent patch set and then send me a diagram of
> how far stu
On 6 sept. 2012, at 10:06, janek.lilyp...@gmail.com wrote:
> Patchset 2 screws everything up, LOL!
It was one of my more colossal breakings of LilyPond - I'll add it to the top
10.
> http://lilypond-stuff.1065243.n5.nabble.com/file/n5705606/accidental-spacing-pairs_patchset2.pdf
>
> In previo
Patchset 2 screws everything up, LOL!
http://lilypond-stuff.1065243.n5.nabble.com/file/n5705606/accidental-spacing-pairs_patchset2.pdf
In previous output (see tracker issue
http://code.google.com/p/lilypond/issues/detail?id=2811#c4) there were
several cases of too close accidentals. I think addi
I like it, but we need to figure out what went wrong with
'accidental-tie.ly'. There was some trickery involving holding space
open for the accidental that might be needed on the second note of a
tied pair, iff the tie is broken across lines.
Ted Ross' textbook puts the upper flat about 0.5 staf
Shouldn't this d-sharp be shifted more to the right?
- Mark
(Franz Schubert: Waltz op.127 no.4, m.21)
\version "2.11.60-1"
\relative << { \key a \major \time 3/4 b'4. } \\ { 2 } >>
<>___
lilypond-devel mailing list
lilypond-devel@gnu.org
http:/
Bruce McIntyre schreef:
You will find that in most usual cases, Lilypond matches this Score utility.
Where Lilypond falls behind is in the treatment of crazy-big clusters and in off
the staff chords where the accidentals fall halfway on the leger-lines.
Werner once posted a better solution to
which is
very good. Brodhead, Thomas M., Beams in Music Engraving, 1993, 1996.
I was curious to see how Lilypond's accidental placement compared with this
program and, as there is a torture test for ACCS online I replicated it in
lilypond (see below)
Compare the output from the below snippet
Han-Wen Nienhuys wrote:
Patches:
Index: lilypond/ChangeLog
diff -u lilypond/ChangeLog:1.4127 lilypond/ChangeLog:1.4128
--- lilypond/ChangeLog:1.4127 Mon Sep 12 13:17:19 2005
+++ lilypond/ChangeLog Mon Sep 12 23:33:22 2005
@@ -1,3 +1,7 @@
+2005-09-13 Han-Wen Nienhuys <[EMAIL PROTECTED]>
+
+
25 matches
Mail list logo
