[Top][All Lists]

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

Re: Consistent vertical alignment of annotations, disable time signiture

From: Robert Hickman
Subject: Re: Consistent vertical alignment of annotations, disable time signiture
Date: Wed, 18 Apr 2018 13:01:22 +0100

The best example of the leaky abstraction problem I can think of right
now are actually visual HTML editors. HTML is very complicated and
follows a 'WYSIWYM' model similar to LaTeX, however the visual editors
try to force this into a 'WYSIWYG' model which simply does not work,
especially when responsive layouts are a factor, as what you see is
inherently going to change. This tends to result in things breaking in
unexpected ways, because the user is not aware of the mismatch. Plus
these tools are usually only aware of a small subset of HTML, so if
they are used in combination with hand written code things get broken
as a result.

As David notes, I am talking about input layer not internals. The
lilypond syntax appears to be an abstraction over an object oriented
design, with a lot of implicit 'magic', and for me as a new user it is
very difficult to see why it does some things, like randomly creating
an empty staff. What I'm wandering is weather it would be clearer to
just use an object oriented syntax directly and make the implicit
stuff explicit.

ABC notation does most of what I need, but lacks a few minor
formatting controls and the ability to define symbols which I need to
finish the work that I'm doing. Lillypond seems vastly more
complicated than I need. The learning manual spends most of it's time
going into things that I have no use for, such as multiple staff
arrangements. Sheet music could either be complex or simple depending
on what you are trying to do, for what I'm doing a fixed-spacing 'dumb
stacking algorithm' that abcm2ps appears to use is perfectly adequate.

Irish trad music is different from classical tradition in that the
scores denote a simple 'outline' of a tune. How they are actually
played tends to differ a great deal, including implicit 'lilt' or
'swung' rhythms and ornamentation and melodic variations that are
added by the player, generally differently every single time they play
a tune. Outside of teaching materials it is rare to notate
articulations, slurs, or ornaments at all. Standard playing style
often attempts to emulate numerous historical bagpipes by slurring
everything by default, and using fingered articulations extensively.

I suspect that ABCn hasn't defined the Larson symbols both because of
the above, and because folk musicians often notate fingered
articulations using grace notes. However this notation requires
different interpretation from the usage of grace notes in classical
theory, and as a result only works within the scope of a given
tradition. It's also very open to misinterpretation if encountered by
classically trained musicians. Calling these 'grace notes' is also
misleading as they are used as articulations, basically
interchangeably with tonguing. They exploit the limits of human
perception by being extremely brief. When played well they are so
brief that their absolute pitch is not perceived. In order to do this
dependably special fingerings or techniques are used.  Grey Larson's
book recognises the mostly my last point, which lead to his notation

On 18 April 2018 at 09:37, David Kastrup <address@hidden> wrote:
> Andrew Bernard <address@hidden> writes:
>> Hello Robert,
>> Speaking as a programmer myself with over forty years of experience,
>> and an advanced lilypond users, I can categorically assert that
>> lilypond is not trying to be 'clever'. This is an utter
>> misunderstanding. Lilypond is however trying to engrave music to the
>> highest possible standard, and this is an immensely difficult
>> programming proposition, hence the complexity under the hood, and the
>> slight difficulties in the syntax. It's not meant to be simplistic or
>> easy like ABC.
> I hate to waste a good defense, but you are talking about its internals
> here and Robert was arguing about the input layer with me.  Different
> beasts.  It's akin to discussing plain TeX vs LaTeX based on the quality
> of the output.  The point of LaTeX is to provide an input and
> abstraction layer, the typesetting remains the job of TeX, the program.
> Now LaTeX is indeed bleeding complexity when you poke it too hard.
> LilyPond's input language is intended to be expressive and convenient
> but a whole lot of pain goes into assuring that it bleeds in concordance
> with both reasonable and unreasonable expectations even when you poke it
> too hard.
> As an example, compare the 2.19 version and interaction of of #{ ... #},
> $, and # with the 2.12 one.  The current version is quite "cleverer",
> going to large pains to make sure that closures, error messages and
> whatnot reliably point to where you'd expect them to be.  This is a much
> more thorough layer than LaTeX provides around TeX, and yet people feel
> much more comfortable using LaTeX than plain TeX.  The LaTeX layers fall
> apart when problems occur and you have to debug.  LilyPond layers tend
> to hold up even under debugging.
> Robert may be speaking from experience, but experience without actual
> knowledge can win over knowledge only when that knowledge in return is
> lacking significant amounts of experience.
> And I'd argue that dismissing my experience in designing, managing,
> maintaining, and explaining complex systems as insignificant does not
> likely make for the best fitting working hypothesis.
> --
> David Kastrup

reply via email to

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