Hello,
firstly: thanks for getting involved in the tie stuff!
2014-02-18 20:42 GMT+01:00 <st...@linuxsuite.org>:
>
> Is it possible for LilyPond to identify these cases and fix them
> itself?
>
> So an simplified algorithm is
>
> If ( Bad_Tie_Case_A )
> apply_fix_a
> If ( Bad_Tie_Case_B)
> apply_fix_b
> If ( Bad_Tie_Case_C )
> apply_fix_c
>
> where each apply_fix is a simple \shape transformation
>
> Is it possible to algorithmically determine in advance a Bad Tie?
I may be mistaken, but as far as i know it is not possible to do
something like this without making the code very messy :-(
2014-02-21 16:44 GMT+01:00 <st...@linuxsuite.org>:
> [...] I can only conclude that historically there was much less
> attention to the minute
> details of tie consistency etc, and much of the detailing was left to the
> discretion of
> the engraver. Also since it was done manually, the minute variations that
> result actually
> work to "hide" the inconsistencies that otherwise would be more
> noticeable and produces
> a much more pleasing affect to the eye.. unlike the repetative algorithmic
> application
> of similar "errors" or "inconsistencies" that we might attribute to LilyPond.
>
> I don't think that attempting to emulate historical practice of
> manual engraving
> wrt. ties, is either possible or desireable. What we need is a modern
> standard that
> makes sense in the age of computer engraving.
I definitely agree.
> Here is my general sense of LilyPond ties and how they seem to be
> drawn and behave....
>
> i) ties drawn between notes on the outside most staff space
> terminate on
> the outside staff line
>
> ii) ties drawn between notes on ledger lines terminate
> over/under the middle of
> the notehead
>
> iii) ties drawn between notes on spaces above ledger lines
> terminate to the
> side of the notehead
>
> [.....] I think that i) above, should change so that the tie
> terminates
> outside the staff.
yes
> I am ok with ii) and iii); this seems to make sense to me now as it
> somehow allocates
> the space around the note / tie / ledger line in a good way.
I think ii) is not good because it makes ties easy to confuse with
slurs. And it's not consistent with iii).
> In conclusion, I think that perhaps 80% of ties in LilyPond are
> fine, fixing
> i) would make that substantially greater,
I don't think it would make the percentage substantially greater, but
it would be an improvement indeed. Attached is a patch that fixes the
logic in staff-edge tie formatting - unfortunately i don't have time
to put it for review (there are some side-effects that will probably
need discussing), but if you'd like to do it feel free to do so.
> I don't think that rewriting the entire Tie code is the solution, and that
> it is probably best to make some relatively minor (?) changes to "fix"
> what is a consensus
> of the problematic ties, perhaps i) iv) and v) ?
>
> Thoughts?
My study of the source code suggests that the current code is badly
designed and that fixing one thing will cause another to go wrong.
But maybe i'm wrong. Anyway, i think you may be interested to look at
my research - i didn't have time to organize it in any way, so right
now i'll just give you a link to Dropbox folder:
https://www.dropbox.com/sh/vsq32b11migflt3/oFHMEiCQx2
I'm afraid that i don't currently have time to discuss this in greater
detail :( However, if you have questions about my research, i'll try
to answer.
2014-02-21 18:30 GMT+01:00 Shane Brandes <sh...@grayskies.net>:
> I am currently working on a score that was originally engraved
> somewhere between 1839- 1869. The date is unfortunately omitted. So
> after doing all the proofreading I began looking at things that should
> be changed to modern practice or just looked for things that appeared
> out of sorts and as I went through looking at the ties and slurs, it
> was astonishing how closely for the most part Lilypond made near exact
> reproductions of the original shapes of the slurs it was sort of
> creepy in a way, in so far as there is no reason Lilypond code should
> have been exposed to a now obscure publishing house. While there are
> minor things here and there that could "improved," but it does not
> seem worth the effort.
> There really is something to be said for having slight amounts of
> imperfections. It is really more human in a way. I know we are
> conditioned in this age to have everything exactly perfect and it
> causes a sort of bland beauty which is also somehow unpleasantly
> sterile.
I see your point. However, i believe that there are so many factors
in correct tie placement (augmentation dots, flags, ledger lines,
chords, voicing, ...) that ties satisfying these constraints will have
some amount of variation and will appear "human-like".
Besides, many of currently wrong ties are really a legibility problem.
I mean, it's not just a matter of being perfect, but of ensuring
unambiguity.
best,
Janek
From 0278d6aa4cecdb490929704ffa3720b059089a21 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Janek=20Warcho=C5=82?= <lemniskata.bernoull...@gmail.com>
Date: Sun, 28 Jul 2013 00:10:42 +0200
Subject: [PATCH] Tie crusade: fix staff edge detection in tie formatting
Until now, ties didn't detect staffline edges properly:
{ f'~ f' } was formatted as if the bottom staffline wasn't
there.
This was caused by two lines in tie-formatting-problem.cc,
added in commit 387a298cdf6e9a987, but the problem was
present before that (i.e. commit 387a298cdf6e9a987 didn't
change lily behaviour): < was used instead of <=.
Code below could be turned into a regtest:
\markup {
In all 3 snippets, 2nd tie should be formatted in the same
way as the 1st one. 3rd tie should be different.
}
{ a'~a' f'~f' d'~d' }
\new Staff \with { \override StaffSymbol #'line-count = #6 }
{ g'~g' e'~e' c'~c' }
\new Staff \with { \override StaffSymbol #'line-count = #7 }
{ f'~f' d'~d' b~b }
---
lily/tie-formatting-problem.cc | 2 --
1 file changed, 2 deletions(-)
diff --git a/lily/tie-formatting-problem.cc b/lily/tie-formatting-problem.cc
index b15536a..23165a4 100644
--- a/lily/tie-formatting-problem.cc
+++ b/lily/tie-formatting-problem.cc
@@ -498,7 +498,6 @@ Tie_formatting_problem::generate_configuration (int pos, Direction dir,
*/
Interval staff_span
= Staff_symbol_referencer::staff_span (details_.staff_symbol_referencer_);
- staff_span.widen (-1);
bool const within_staff = staff_span.contains (pos);
if (head_positions_slice (columns[LEFT]).contains (pos)
|| head_positions_slice (columns[RIGHT]).contains (pos)
@@ -734,7 +733,6 @@ Tie_formatting_problem::score_configuration (Tie_configuration *conf) const
}
int rounded_tip_pos = int (rint (tip_pos));
- staff_span.widen (-1);
if (Staff_symbol_referencer::on_line (details_.staff_symbol_referencer_, rounded_tip_pos)
&& (head_positions_slice (conf->column_ranks_[LEFT]).contains (rounded_tip_pos)
|| head_positions_slice (conf->column_ranks_[RIGHT]).contains (rounded_tip_pos)
--
1.9.0
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
