Discussion:
Lines and Ties and Slurs oh my!
(too old to reply)
s***@linuxsuite.org
2014-02-14 21:01:32 UTC
Permalink
Howdy!

It is well known that Ties and Slurs are problematic in LilyPond
2.18.0. As can be seen by
a simple example from my project "Goldberg Variations for Guitar Ensemble"
variation 22

http://www.gooeytar.com/projects/BWV-988/test/test.orig.pdf

Notice that Ties in bar 1 are different than Ties in bar 2 or bar
4 or bar 7. Termination
of the Tie is not consistent.

So first we need to ask the question: How should Ties be drawn?
Specifically
where should the Tie terminate relative to the notehead?

Ties in bar 1 and bar 3 terminates at the "inside upper corner"
of the notehead. Ties in
bar 4 and 7, terminate "above / below and in the middle" of the notehead.
Which is
correct?

My understanding is that the Ties in bar 1 and 3 are correct.
Slurs should
terminate in the middle of the note to distinguish between Ties. Is that the
consensus with Lilypond users / dev?

Is there a general fix for this across the broad section of
examples?

One solution is to use \shape to fix individual Ties. If I define
a couple of
macros

* to fix ties in bar 4, 13 (TieDown_stemsUpUp)
TDUUa = \shape #'((0.6 . 0.4)(0 . 0.6)(0 . 0.6)(-0.6 . 0.4)) Tie

* to fix ties in bar 7 (TieUp_stemsDownDown)
TUDDa = \shape #'((0.6 . -0.2)(0 . -0.3)(0 . -0.3)(-0.6 . -0.2)) Tie


The results of the above can be seen here

http://www.gooeytar.com/projects/BWV-988/test/test.pdf

Are they correct now? Is there another better way to deal with this?

It is certainly possible to go through the 100+ or so "bad" Ties
manually and I expect
that there are simple fixes like the above that will correct common
categories
of bad Ties; for example all Ties between notes that are on upper ledger
lines with
stems down are drawn incorrectly with termination in the middle of the
notehead (like a slur).
Some preliminary testing has led me to conclude that the same fix (like
above) may typically
fix the same situation regardless of the length of the Tie or the value of
the notes....

Is there a way to integrate this heuristic into the main code so
that most manual
tweaking is not needed?

Or is there another better approach that can be used for issue?

thanx - steve
Urs Liska
2014-02-14 21:37:18 UTC
Permalink
Post by s***@linuxsuite.org
Howdy!
It is well known that Ties and Slurs are problematic in LilyPond
2.18.0. As can be seen by
a simple example from my project "Goldberg Variations for Guitar Ensemble"
variation 22
http://www.gooeytar.com/projects/BWV-988/test/test.orig.pdf
Notice that Ties in bar 1 are different than Ties in bar 2 or bar
4 or bar 7. Termination
of the Tie is not consistent.
So first we need to ask the question: How should Ties be drawn?
Specifically
where should the Tie terminate relative to the notehead?
Ties in bar 1 and bar 3 terminates at the "inside upper corner"
of the notehead. Ties in
bar 4 and 7, terminate "above / below and in the middle" of the notehead.
Which is
correct?
My understanding is that the Ties in bar 1 and 3 are correct.
Slurs should
terminate in the middle of the note to distinguish between Ties. Is that the
consensus with Lilypond users / dev?
Is there a general fix for this across the broad section of
examples?
One solution is to use \shape to fix individual Ties. If I define
a couple of
macros
* to fix ties in bar 4, 13 (TieDown_stemsUpUp)
TDUUa = \shape #'((0.6 . 0.4)(0 . 0.6)(0 . 0.6)(-0.6 . 0.4)) Tie
* to fix ties in bar 7 (TieUp_stemsDownDown)
TUDDa = \shape #'((0.6 . -0.2)(0 . -0.3)(0 . -0.3)(-0.6 . -0.2)) Tie
The results of the above can be seen here
http://www.gooeytar.com/projects/BWV-988/test/test.pdf
Are they correct now? Is there another better way to deal with this?
It is certainly possible to go through the 100+ or so "bad" Ties
manually and I expect
that there are simple fixes like the above that will correct common
categories
of bad Ties; for example all Ties between notes that are on upper ledger
lines with
stems down are drawn incorrectly with termination in the middle of the
notehead (like a slur).
Some preliminary testing has led me to conclude that the same fix (like
above) may typically
fix the same situation regardless of the length of the Tie or the value of
the notes....
Is there a way to integrate this heuristic into the main code so
that most manual
tweaking is not needed?
Or is there another better approach that can be used for issue?
thanx - steve
This is at least something:

http://lilypondblog.org/2014/01/engraving-statistics-slurs-and-ties/
http://lilypondblog.org/2013/11/engraving-challenges-slurs-and-ties/
http://lilypondblog.org/2013/08/tie-crusade-round-2/
http://lilypondblog.org/2013/07/lilypond-tie-crusade/

HTH
Urs
Post by s***@linuxsuite.org
_______________________________________________
lilypond-user mailing list
https://lists.gnu.org/mailman/listinfo/lilypond-user
--
Urs Liska
www.openlilylib.org
Eluze
2014-02-14 23:42:42 UTC
Permalink
Post by s***@linuxsuite.org
Howdy!
It is well known that Ties and Slurs are problematic in LilyPond
2.18.0. As can be seen by
a simple example from my project "Goldberg Variations for Guitar Ensemble"
variation 22
hi steve!

can you please point to the problematic tie or slur directly in the sense of
a tiny example!?

thanks!
Eluze



--
View this message in context: http://lilypond.1069038.n5.nabble.com/Lines-and-Ties-and-Slurs-oh-my-tp159306p159315.html
Sent from the User mailing list archive at Nabble.com.
Phil Holmes
2014-02-15 11:07:25 UTC
Permalink
----- Original Message -----
From: <***@linuxsuite.org>
To: <lilypond-***@gnu.org>
Sent: Friday, February 14, 2014 9:01 PM
Subject: Lines and Ties and Slurs oh my!
Post by s***@linuxsuite.org
Howdy!
It is well known that Ties and Slurs are problematic in LilyPond
2.18.0. As can be seen by
a simple example from my project "Goldberg Variations for Guitar Ensemble"
variation 22
http://www.gooeytar.com/projects/BWV-988/test/test.orig.pdf
Notice that Ties in bar 1 are different than Ties in bar 2 or bar
4 or bar 7. Termination
of the Tie is not consistent.
If we follow the recommendation of the widely quoted Gould: Behind bars,
then there's no reason why ties should be consistent. She explicitly states
that they can vary, depending on whether the notehead is on a stave line or
between them, whether space is tight, whether there is other notation, etc.,
etc. The ones you quote as inconsistent are in different positions on the
stave, and I would therefore not expect them to be the same.

--
Phil Holmes
Janek Warchoł
2014-02-15 16:43:46 UTC
Permalink
hello,
Post by s***@linuxsuite.org
Notice that Ties in bar 1 are different than Ties in bar 2 or bar
4 or bar 7. Termination
of the Tie is not consistent.
some of this inconsistency is due to issues that Phil pointed out, but
I agree that this output is not optimal.
Post by s***@linuxsuite.org
So first we need to ask the question: How should Ties be drawn?
Specifically
where should the Tie terminate relative to the notehead?
As Phil wrote this depends on many factors, including whether there
are notes in other voices or chords. There is no single answer that
would apply to all ties.

After a lot of thinking (i mean, 100-150 hours of thinking? something
like that) i have a pretty good idea how correct ties should look
like. Unfortunately, it is not easy to express it in a way that a
computer understands (but it is possible).
Post by s***@linuxsuite.org
Ties in bar 1 and bar 3 terminates at the "inside upper corner"
of the notehead. Ties in
bar 4 and 7, terminate "above / below and in the middle" of the notehead.
Which is
correct?
m. 2 and 3 is correct, 4 is wrong, 1 and 7 are slightly wrong.
Post by s***@linuxsuite.org
Slurs should
terminate in the middle of the note to distinguish between Ties.
Generally, yes.
Post by s***@linuxsuite.org
Is there a general fix for this across the broad section of
examples?
Not quite. we have to rewrite lily's tie formatting code to fix this completely.
Post by s***@linuxsuite.org
One solution is to use \shape to fix individual Ties. If I define
a couple of
macros
* to fix ties in bar 4, 13 (TieDown_stemsUpUp)
TDUUa = \shape #'((0.6 . 0.4)(0 . 0.6)(0 . 0.6)(-0.6 . 0.4)) Tie
* to fix ties in bar 7 (TieUp_stemsDownDown)
TUDDa = \shape #'((0.6 . -0.2)(0 . -0.3)(0 . -0.3)(-0.6 . -0.2)) Tie
The results of the above can be seen here
http://www.gooeytar.com/projects/BWV-988/test/test.pdf
Are they correct now?
They are definitely better.
Post by s***@linuxsuite.org
Is there another better way to deal with this?
Rewrite tie fomatting code :(
Post by s***@linuxsuite.org
It is certainly possible to go through the 100+ or so "bad" Ties
manually and I expect
that there are simple fixes like the above that will correct common
categories
of bad Ties; for example all Ties between notes that are on upper ledger
lines with
stems down are drawn incorrectly with termination in the middle of the
notehead (like a slur).
Some preliminary testing has led me to conclude that the same fix (like
above) may typically
fix the same situation regardless of the length of the Tie or the value of
the notes....
Yes, I have done this with the Fried edition
(http://lilypondblog.org/2014/01/engraving-statistics-slurs-and-ties/)
- 500 fixed ties...
And i have collected more than 500 tie examples over the last two
years, analyzing of which gave me some conclusions but i didn't have
enough time to fix the darn thing. If you'd like, i can share my
research with you.

Unfortunately, i have very little time for lilypond now, so i cannot
do much more. If you'd like to start seriously working on this issue,
i'd be happy to provide some guidance, feedback and testing. I
estimate that anyone who wants to really fix this would have to spend
20-30 hours on researching tie shapes (i.e. reading my research),
10-20 hours to get an idea how lilypond thinks about ties now, 40-80
hours on writing new algorithms and then 20-60 hours on testing and
fixing corner cases. With that amount of effort, it should be
possible to create an almost-perfect tie formatting algorithms (i
mean, an algorithm that formats 99.9% ties correctly, as opposed to
50% success rate now).

I'm sorry if this sounds discouraging, but that's how it is.

best,
Janek
s***@linuxsuite.org
2014-02-15 17:32:08 UTC
Permalink
Post by Janek Warchoł
hello,
< snip>
Post by Janek Warchoł
Unfortunately, i have very little time for lilypond now, so i cannot
do much more. If you'd like to start seriously working on this issue,
i'd be happy to provide some guidance, feedback and testing. I
estimate that anyone who wants to really fix this would have to spend
20-30 hours on researching tie shapes (i.e. reading my research),
10-20 hours to get an idea how lilypond thinks about ties now, 40-80
hours on writing new algorithms and then 20-60 hours on testing and
fixing corner cases. With that amount of effort, it should be
possible to create an almost-perfect tie formatting algorithms (i
mean, an algorithm that formats 99.9% ties correctly, as opposed to
50% success rate now).
I'm sorry if this sounds discouraging, but that's how it is.
I will select examples of ties and slurs from Goldberg on 2.18.0 and put
together a minimalist
exposition for discussion.

So, I guess the final solution is to do some programming work.
Hmm... what
if we paid someone to do the work? Can we raise money through kickstarter
for this kind of project? The opengoldberg project did this


http://www.opengoldbergvariations.org/

https://www.kickstarter.com/projects/293573191/open-goldberg-variations-setting-bach-free

they raised money to engrave BWV-988 on Musescore.

What if we set a similar goal for lilypond ties / slurs.. and made an
example
of the Goldberg Variations for Guitar Ensemble?

We may even get a recording out of it?

-steve
Post by Janek Warchoł
best,
Janek
Urs Liska
2014-02-15 17:47:03 UTC
Permalink
Post by s***@linuxsuite.org
Post by Janek Warchoł
hello,
< snip>
Post by Janek Warchoł
Unfortunately, i have very little time for lilypond now, so i cannot
do much more. If you'd like to start seriously working on this issue,
i'd be happy to provide some guidance, feedback and testing. I
estimate that anyone who wants to really fix this would have to spend
20-30 hours on researching tie shapes (i.e. reading my research),
10-20 hours to get an idea how lilypond thinks about ties now, 40-80
hours on writing new algorithms and then 20-60 hours on testing and
fixing corner cases. With that amount of effort, it should be
possible to create an almost-perfect tie formatting algorithms (i
mean, an algorithm that formats 99.9% ties correctly, as opposed to
50% success rate now).
I'm sorry if this sounds discouraging, but that's how it is.
I will select examples of ties and slurs from Goldberg on 2.18.0 and put
together a minimalist
exposition for discussion.
So, I guess the final solution is to do some programming work.
Hmm... what
if we paid someone to do the work? Can we raise money through kickstarter
for this kind of project?
Principally this is perfectly possible. The question is always to get
someone to do it. If you're interested in the subject you could well go
for it:
- determine how much funds would be needed and
- be sure that you could actually find someone who does it.
- then raise the Kickstarter project.

I think this would be a very welcome effort.

Best
Urs
Kieren MacMillan
2014-02-15 17:54:35 UTC
Permalink
Hello all,
The question is always to get someone to do it.
I’ve know someone at Carnegie-Mellon University who is well-connected in the computer and music departments (he is both a composer and a programmer). I approached him recently with the idea of getting involved with Lilypond.
One possibility is that sometimes there are software engineering projects looking for tasks, so I might be able to point a class project at Lilypond in the future.
I'm curious if there's a short summary of the direction for large-scale work on Lilypond.
Is there something we can forward to him, so that he can take it to his department and/or colleagues for consideration? If we could convince a major university to take on [some or all of the] programming — for single projects or the whole enchilada — I think it would be a big boost to the ‘Pond.

Cheers,
Kieren.
David Kastrup
2014-02-15 17:46:20 UTC
Permalink
Post by s***@linuxsuite.org
I will select examples of ties and slurs from Goldberg on 2.18.0 and put
together a minimalist
exposition for discussion.
So, I guess the final solution is to do some programming work.
Hmm... what if we paid someone to do the work? Can we raise money
through kickstarter for this kind of project?
It definitely depends on who "we" is. It also depends on who "someone"
is.

At the current point of time, a significant ratio of regular list users
is supporting me financially for working on LilyPond. The ties are in
the backend, and I am not currently doing significant work there.

So for a separate tie project, it would be nice to raise money from
people not already investing in LilyPond. A particular and popular show
project like Goldberg would probably help.

However, LilyPond does not produce MusicXML, so you won't get, say,
Finale users to contribute based on the (likely overoptimistic)
expectation that they will be able to use the MusicXML in their own
software.

So extending reach much beyond the LilyPond community itself might be
tricky.

On the other side of the equation, you need someone to do the work, and
the LilyPond code base is humongous and complex. If you don't want to
spend 3/4 of the money (if you are lucky) for getting someone acquainted
with the code, you'll probably need to look for people with previous
experience. _And_ available time.

That might also be tricky.
Post by s***@linuxsuite.org
What if we set a similar goal for lilypond ties / slurs.. and
made an example of the Goldberg Variations for Guitar Ensemble?
So the goal would be to have it nicely typeset without tweaking ties
manually?
--
David Kastrup
Janek Warchoł
2014-02-15 20:16:55 UTC
Permalink
Hi,
Post by Kieren MacMillan
I’ve know someone at Carnegie-Mellon University who is well-connected in the computer and music departments (he is both a composer and a programmer). I approached him recently with the idea of getting involved with Lilypond.
One possibility is that sometimes there are software engineering projects looking for tasks, so I might be able to point a class project at Lilypond in the future.
I'm curious if there's a short summary of the direction for large-scale work on Lilypond.
Is there something we can forward to him, so that he can take it to his department and/or colleagues for consideration? If we could convince a major university to take on [some or all of the] programming — for single projects or the whole enchilada — I think it would be a big boost to the ‘Pond.
That would be extremely cool!
As for the list of long-term projects, i don't think we have any
(which is very bad for the project imo). I would be happy to write
something down if there is at least one other developer interested in
reviewing and expanding it.
Post by Kieren MacMillan
I will select examples of ties and slurs from Goldberg on 2.18.0 and put
together a minimalist
exposition for discussion.
So, I guess the final solution is to do some programming work.
Hmm... what if we paid someone to do the work? Can we raise money
through kickstarter for this kind of project?
It definitely depends on who "we" is. It also depends on who "someone"
is.
[...]
On the other side of the equation, you need someone to do the work, and
the LilyPond code base is humongous and complex. If you don't want to
spend 3/4 of the money (if you are lucky) for getting someone acquainted
with the code, you'll probably need to look for people with previous
experience. _And_ available time.
Exactly.
Hiring a "regular developer" (someone not particularly interested in
Free Software and LilyPond) would probably cost us something like
$10000 (although my knowledge of the market prices shouldn't be
trusted). That's way too much.
However, someone already interested in LilyPond/music engraving/Free
Software (or a talented CS student wanting to get experience in a
real-world project) could probably do this for a fraction of a cost.

Two people come to my mind: Mike (Solomon), and my cousin Franek who
recently told me that he might be interested in working on ties after
he finishes another project (which should happen in April). I don't
think Franek or Mike would want $10000 for this job ;-) (Franek is
already a bit familiar with ties, as we researched them together
during this summer).

If all goes well (i.e. i earn as much money as i hope), i'll be
willing to put $100-$200 into this.

best,
Janek
s***@linuxsuite.org
2014-02-15 21:18:32 UTC
Permalink
Post by David Kastrup
Post by s***@linuxsuite.org
I will select examples of ties and slurs from Goldberg on 2.18.0 and put
together a minimalist
exposition for discussion.
So for a separate tie project, it would be nice to raise money from
people not already investing in LilyPond. A particular and popular show
project like Goldberg would probably help.
Exactly, there are lots of Goldberg fans, and for this particular
project, the transcription for guitar ensemble, which has never been done
before, could be
a significant motivator for support, amongst the guitar community.
For example, a kickstarter program could solicit investors that would recieve
a high quality print of the finished project.

Also as an extension of my work on the guitar transcription, I can
imagine a "generic" transcription, unlike the guitar version which has
lots of octave transposition, and other changes to make it playable
on a standard guitar. This version would be a note for note rendering
of the original, but with the voices separated out. It could then become
a basis for any number of instrument combinations
Post by David Kastrup
Post by s***@linuxsuite.org
What if we set a similar goal for lilypond ties / slurs.. and
made an example of the Goldberg Variations for Guitar Ensemble?
So the goal would be to have it nicely typeset without tweaking ties
manually?
If the issue of ties / slurs is a big outstanding issue ( and
I think it is)
to taking LilyPond to the next level, then we could fix that and use
Goldberg
both the guitar and "generic" transcriptions as a focal point for organizing
and fund raising...??

-steve
Post by David Kastrup
--
David Kastrup
Janek Warchoł
2014-02-15 19:56:20 UTC
Permalink
Post by s***@linuxsuite.org
Post by Janek Warchoł
Unfortunately, i have very little time for lilypond now, so i cannot
do much more. If you'd like to start seriously working on this issue,
i'd be happy to provide some guidance, feedback and testing. I
estimate that anyone who wants to really fix this would have to spend
20-30 hours on researching tie shapes (i.e. reading my research),
10-20 hours to get an idea how lilypond thinks about ties now, 40-80
hours on writing new algorithms and then 20-60 hours on testing and
fixing corner cases. With that amount of effort, it should be
possible to create an almost-perfect tie formatting algorithms (i
mean, an algorithm that formats 99.9% ties correctly, as opposed to
50% success rate now).
I'm sorry if this sounds discouraging, but that's how it is.
I will select examples of ties and slurs from Goldberg on 2.18.0 and put
together a minimalist
exposition for discussion.
Good - we can then merge our research results.
s***@linuxsuite.org
2014-02-18 19:42:55 UTC
Permalink
Howdy!

I put together a sample of ties and a couple of apogg/slurs...

This issue is hugely dependent on context, particularly spacing
requirements,
so some stuff was not reproducible as it ocurred in the origina, and
other times new stuff came up that was not evident before... so I 'm not
sure how useful this will be...

www.gooeytar.com/projects/BWV-988/samples/

There a lots of obvious problems with some ties. Most of are
consistent enough
that a standard kind of \shape fix should work good enough...

Summary of some issues

bar 4 -8 : tie terminates on inner staff line, but not in
bar 9 and 10. But
it is the identical notes and rythym

bar 12 : tie terminates on upper staff line

bar 13 : tie terminates high on middle of note, unlike in
bar 17 and 33 even
though note pitch is identical and values are
similar.


I understand that the correct fix is a significant amount of
work, but was
wondering a simple "quick fix" for 2.18.1 is possible...

There are certain obvious tie problems that are pathological, in
sense that
they are consistent and there is a common solution. For example

i) ties terminating on an upper staff lilne
ii) ties terminating on an inner staff line
iii) ties terminating above in the middle of a note for
notes on an upper ledger line

These all have individual \shape fixes that will work well
enough for a large
number of cases.. the process of going through identifying a problem case and
applying a \shift solution is a simple mechanical one.

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?

Going through it manually can be easily done and would only require
a few days, but I would be willing to sponsor a solution for 2.18.1 if
it is simple enough, not expensive, and will not make a mess..

-steve
s***@linuxsuite.org
2014-02-21 15:44:16 UTC
Permalink
Howdy!

I spent the last 2 afternoons in the Toronto Reference Library
going
through Henle and Bärenreiter scores from the 1970's and 80's. Mostly
Goldberg, other Bach
stuff and some Beethoven. I specifically looked at ties and came to the
following conclusions...


i) There is huge variability and general lack of consistency not
only in between
the Henle and Bärenreiter, but even within the same editions.
All of the "errors"
and "inconsistencies" noted in this thread that appear in
LilyPond also appear in
both the Henle and Bärenreiter

ii) The shape of the ties is noticeably thinner at the ends and
broader in the middle,
more so than the LilyPond tie.

iii) ties are generally terminated over/under the middle of the
notehead

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.

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

iv) as space becomes more constrained, ties on the inner staff
are diminished
(shortened and less arch) in order to not cross over a
staff line, at
the expense of a more appropriate orientation to the notehead.

v) ties drawn between notes on internal staff spaces, sometimes
have more gap / space
between the notehead making them inconsistent with other similar

I think that i) above, should change so that the tie terminates
outside the staff.
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. Also I think
that
ties in the inner staff should cross over staff lines in order to maintain
a more
consistent orientation to the notehead.

In conclusion, I think that perhaps 80% of ties in LilyPond are
fine, fixing
i) would make that substantially greater, as would a fix for iv)

What makes a tie "good" or "bad" is often the result of personal
preference.
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?

-steve
Shane Brandes
2014-02-21 17:30:02 UTC
Permalink
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. This shows in so many aspects of our civilization, our music
is dreadfully dry in performance and machine like, our buildings now
that they are Cad drawn are increasingly divorced from the human form
and the natural dimensions we inspired in earlier architecture, and
most of automobiles in current production look like used bars of soap.
So while I find the pursuit of perfection somehow attractive there
is definitely a downside to this endeavor and maybe the time would be
more worthwhile spent working on other areas of the program that
could, in fact, use more attention for improvement.

Shane
Post by s***@linuxsuite.org
Howdy!
I spent the last 2 afternoons in the Toronto Reference Library
going
through Henle and Bärenreiter scores from the 1970's and 80's. Mostly
Goldberg, other Bach
stuff and some Beethoven. I specifically looked at ties and came to the
following conclusions...
i) There is huge variability and general lack of consistency not
only in between
the Henle and Bärenreiter, but even within the same editions.
All of the "errors"
and "inconsistencies" noted in this thread that appear in
LilyPond also appear in
both the Henle and Bärenreiter
ii) The shape of the ties is noticeably thinner at the ends and
broader in the middle,
more so than the LilyPond tie.
iii) ties are generally terminated over/under the middle of the
notehead
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.
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
iv) as space becomes more constrained, ties on the inner staff
are diminished
(shortened and less arch) in order to not cross over a
staff line, at
the expense of a more appropriate orientation to the notehead.
v) ties drawn between notes on internal staff spaces, sometimes
have more gap / space
between the notehead making them inconsistent with other similar
I think that i) above, should change so that the tie terminates
outside the staff.
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. Also I think
that
ties in the inner staff should cross over staff lines in order to maintain
a more
consistent orientation to the notehead.
In conclusion, I think that perhaps 80% of ties in LilyPond are
fine, fixing
i) would make that substantially greater, as would a fix for iv)
What makes a tie "good" or "bad" is often the result of personal
preference.
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?
-steve
_______________________________________________
lilypond-user mailing list
https://lists.gnu.org/mailman/listinfo/lilypond-user
David Kastrup
2014-02-21 17:41:30 UTC
Permalink
Post by Shane Brandes
So while I find the pursuit of perfection somehow attractive there
is definitely a downside to this endeavor and maybe the time would be
more worthwhile spent working on other areas of the program that
could, in fact, use more attention for improvement.
Janek Warchoł
2014-02-22 17:44:19 UTC
Permalink
Hello,

firstly: thanks for getting involved in the tie stuff!
Post by s***@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 :-(
Post by s***@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.
Post by s***@linuxsuite.org
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
Post by s***@linuxsuite.org
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).
Post by s***@linuxsuite.org
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.
Post by s***@linuxsuite.org
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.
Post by s***@linuxsuite.org
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

MING TSANG
2014-02-21 19:21:50 UTC
Permalink
________________________________

Shane Brandes <***@hidden> writes: >So while I find the pursuit of perfection somehow attractive there >is definitely a downside to this endeavor and maybe the time would be >more worthwhile spent working on other areas of the program that >could, in fact, use more attention for improvement.
\version "2.17.7"
\header { tagline = ##f title = "Conny rates Jazz" }
\score
{ { $@(map! (lambda (p d) #{ \footnote #'(1 . 2)
% This is the simplest way to make a chord name markup? Ugh. \markup \score { \new ChordNames { < ***@hidden > } \layout { } } Stem < ***@hidden >***@hidden #})
; this $@ produces elements for a sequential music list via map!. Each
; element is constructed from p, a list of pitches making up a chord,
; and from d, which is a list first containing a duration followed by
; _optional_ articulations, so ***@hidden actually can return several
tokens of
; _different_ type.
;
; The following form constructs the list of pitch lists for use in p (map! (lambda (i) (map! (lambda (i) (ly:make-pitch 2 (+ 1 (* 9 (quotient i 5)) (* i -2)) 0)) (iota 5 i))) (append! (iota 34) (list 32)))
; The following form constructs an (end-less) list of lists containing
; a duration and maybe articulations. (apply circular-list (map! (lambda (m) (cons (ly:music-property m 'duration) (ly:music-property m 'articulations))) (extract-typed-music #{ s4.~ s~ s4~ s2~ s2 #} 'skip-event)))) <c' e' g' a' c''>1 \bar "|." } \midi { \tempo 4 = 220 \set Staff.midiInstrument = "acoustic grand" } \layout { }
}
--
David Kastrup
<><><><><><
I run the above code and I got the following error. (I copy & paste to frescobaldi and run convert.ly).
Starting lilypond-windows.exe 2.19.2 [Untitled]...
Processing `c:/users/tsang/appdata/local/temp/frescobaldi-6z8gjw/tmpfknwyr/document.ly'
Parsing...
c:/users/tsang/appdata/local/temp/frescobaldi-6z8gjw/tmpfknwyr/document.ly:5:7: error: GUILE signaled an error for the expression beginning here
{ $
@(map!
Interpreting music...
Interpreting music...
Preprocessing graphical objects...
MIDI output to `document.mid'...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `document.ps'...
Converting to `./document.pdf'...
Unbound variable: tokens
fatal error: failed files: "c:\\users\\tsang\\appdata\\local\\temp\\frescobaldi-6z8gjw\\tmpfknwyr\\document.ly"
Exited with return code 1.
David Kastrup
2014-02-21 20:50:16 UTC
Permalink
----------------------------------------------------------------------
Post by Shane Brandes
So while I find the pursuit of perfection somehow attractive there
is definitely a downside to this endeavor and maybe the time would be
more worthwhile spent working on other areas of the program that
could, in fact, use more attention for improvement.
[...]
\layout { } } Stem
Try getting the file somewhere where "email addresses" don't get
converted into ***@hidden.

Probably
<URL:http://cache.gmane.org//gmane/comp/gnu/lilypond/general/91138-001.bin>
is worth a try after renaming.
--
David Kastrup
Continue reading on narkive:
Loading...