as an overall comment; I would try to look at the buggy examples in more
detail to understand exactly what is going wrong. It is easy to add an
extra demerit, but (as you can see) hard to make it work with all the
other cases that we handle.
http://codereview.appspot.com/4817048/diff/15002/lily
On 2011/07/27 19:30:41, J_lowe wrote:
Passes Make and reg tests.
Sorry I updated the wrong Rietveld issue. This does pass make but there
are reg test differences - see
http://code.google.com/p/lilypond/issues/detail?id=163#c17
http://codereview.appspot.com/4817048/
__
Passes Make and reg tests.
http://codereview.appspot.com/4817048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Jul 27, 2011, at 3:37 PM, tdanielsmu...@googlemail.com wrote:
>
> http://codereview.appspot.com/4817048/diff/13001/lily/include/slur-score-parameters.hh
> File lily/include/slur-score-parameters.hh (right):
>
> http://codereview.appspot.com/4817048/diff/13001/lily/include/slur-score-paramete
http://codereview.appspot.com/4817048/diff/13001/lily/include/slur-score-parameters.hh
File lily/include/slur-score-parameters.hh (right):
http://codereview.appspot.com/4817048/diff/13001/lily/include/slur-score-parameters.hh#newcode32
lily/include/slur-score-parameters.hh:32: Real
max_distance_
On 2011/07/24 13:50:53, MikeSol wrote:
New patchset uploaded with minor tweaks.
I still need to think about a better way to implement the change in
score_edges.
The idea is that if there is a large jump right at the beginning or
end of the
stem, we should favor attachments points that are c
New patchset uploaded with minor tweaks.
I still need to think about a better way to implement the change in
score_edges. The idea is that if there is a large jump right at the
beginning or end of the stem, we should favor attachments points that
are closer to the Y-position of the second note-co
;
lemniskata.bernoulli...@gmail.com; w...@gnu.org; pkx1...@gmail.com;
lilypond-devel@gnu.org; re...@codereview.appspotmail.com
Subject: Re: First pass at avoiding very high slurs (fixes issue 163).
(issue4817048)
On Jul 24, 2011, at 11:49 AM, pkx1...@gmail.com wrote:
> Make passes and reg te
On Jul 24, 2011, at 11:49 AM, pkx1...@gmail.com wrote:
> Make passes and reg tests look pretty good too
>
> See http://code.google.com/p/lilypond/issues/detail?id=163#c12
>
> for output
>
> http://codereview.appspot.com/4817048/
Thanks James!
A lot of the changes are ugly (there are only a co
Make passes and reg tests look pretty good too
See http://code.google.com/p/lilypond/issues/detail?id=163#c12
for output
http://codereview.appspot.com/4817048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listi
> I'm currently preparing an extensive report on the matter of ties.
> I estimate that 30% of work is done.
This is great news!
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
2011/7/24 :
> I don't mind if we have another obscure entry in the detail list
> currently. If your patches fixes the problem reliably, this would be a
> great immediate help.
>
> IMHO, at some point in the hopefully not too distant future, the whole
> handling of slurs and ties must be re-examin
I don't mind if we have another obscure entry in the detail list
currently. If your patches fixes the problem reliably, this would be a
great immediate help.
IMHO, at some point in the hopefully not too distant future, the whole
handling of slurs and ties must be re-examined to make it more
user
gmail.com> writes:
>
> This fixes issue 163. The only downside is that it adds another entry
> to an already-crowded details list.
Mike, it seems that the existing properties 'height-limit and 'ratio *should*
control the situations in issue 163.
In fact, making 'height-limit larger (?!) a
Reviewers: ,
Message:
Hey all,
This fixes issue 163. The only downside is that it adds another entry
to an already-crowded details list. I also use a magic number of 2
(you'll see a comment about it) that should likely itself either be a
details entry or be taken from an existing details entry
15 matches
Mail list logo
