lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: discrete slurs and ties


From: David Kastrup
Subject: Re: discrete slurs and ties
Date: Wed, 23 May 2012 12:43:02 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

Werner LEMBERG <address@hidden> writes:

>>> Frankly, I don't see the point in simulating well-craftedness by
>>> artificially introducing minor deficiencies associated with some of
>>> the better work.
>>
>> @Werner: i could live with an *option* doing this, but i doubt that
>> people are interested in writing it.  And i think we have much,
>> much, much more important stuff to work on.
>
> I think I was still unclear, since you both missed my point.  The
> engraver's main deficiencies IMHO were imprecise positioning of the
> stamped beams.  But using stamps instead of hand-cutting such small
> slurs and ties was an *intentional* decision.

Sure.  As is using printing letters instead of hand-made calligraphy.
It makes for a consistent stencil quality.  But we don't have stencil
quality problems.  Your argument may be that it somehow helps if
identical meaning is conveyed by identical shapes.  But if that were
actually the case, we would not need optical correction.  In fact, the
most common _deficiency_ of computer music typesetting is that the
computer overuses mathematically "correct" identical shapes and
placements.

> Lilypond already does a good job, as the attached image shows, but
> there might be cases where this isn't so, and adding some discreteness
> might improve the visual results.  I fully agree that this isn't
> important at all currently.
>
> BTW, restricting lilypond to discrete tie and slur shapes below a
> given threshold should actually simplify the layout process since the
> number of positioning choices gets reduced.

Calculating a shape does not even involve a run-time _choice_ (choices
are, in my opinion, discrete), so no, this does not simplify things.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]