Re: Consistent vertical alignment of annotations, disable time signiture

[Robert Hickman]

You are largely missing the point I was trying to make, however I have
a lot of work to do and cannot be bothered to argue.

On 18 April 2018 at 13:24, David Kastrup <address@hidden> wrote:
> 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