lilypond-user
[Top][All Lists]
Advanced

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

Re: Consistent vertical alignment of annotations, disable time signiture


From: David Kastrup
Subject: Re: Consistent vertical alignment of annotations, disable time signiture
Date: Wed, 18 Apr 2018 14:24:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Robert Hickman <address@hidden> writes:

> The best example of the leaky abstraction problem I can think of right
> now are actually visual HTML editors.

That's more in line of complaining about Denemo than LilyPond.  Either
way the solution lies in not confusing the editor's domain with the the
result domain.

> As David notes, I am talking about input layer not internals. The
> lilypond syntax appears to be an abstraction over an object oriented
> design,

No, that definitely isn't it.  Absolutely not.

> 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.

LilyPond is designed as an input language.  Its internal data structures
are mostly mapped to Scheme data structures.  Scheme is a functional
language, not an object oriented language.  Large swaths of LilyPond are
coded in C++ for efficiency reasons, but the data models of C++ don't
really have exposure worth noting to LilyPond.

Understanding LilyPond's input is not related to understanding C++ and
not significantly related to Scheme either.  Its input language is
defined in a traditional lexer/parser manner implemented with a standard
LALR(1) parser generator.  For debugging and programming reasons, its
productions these days pass around Scheme data structures exclusively
but that's a comparatively recent development.

So no: you are completely wrong with your musings and they have
absolutely no relation to internals of LilyPond: this rather concerns
the completely independent syntax (and parser-internal semantics) of its
input files.

> 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.

If you don't insist into digging yourself into the complexity, you can
get away perfectly well without it.  But you refuse doing so because you
express your a priori confidence that its authors and maintainers are
incapable of properly layering its complexity.

> The learning manual spends most of it's time going into things that I
> have no use for, such as multiple staff arrangements.

If you want to pay for a personal tutor catering to your personal needs,
of course you can save the time skipping over unwanted material.
Manuals are a compromise between saving time for the teacher and saving
time for the learner.  As we have a vastly larger number of users over
teachers, they are freeing resources for the project.

> 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.

So?  What are you hoping to gain by lecturing everyone how bad LilyPond
must have been designed according to your experience with and/or without
it?

I mean, I am the last one to let a good opportunity for pontificating go
to waste, but so far I fail to see that you have availed yourself of
such an opportunity.  Perhaps try to figure out what you actually want
to get achieved and then think of plans, technical and/or social, to
actually get them done.

There is no point playing to your strengths without applying them in a
useful manner to problems you want to see solved.

-- 
David Kastrup



reply via email to

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