Not Nice Review of the LilyPond

[Reggie]

Has anyone else seen this do you know who the author is? Some complaints
about gibberish and documentation and God knows what else. Is this a joke
one or seriously critical of the program? Or in cheek.
http://www.alethis.net/reference/lily/lily.html



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

[Andrew Bernard]

Hi Reggie,

It's not a review, it's a guide. There's one paragraph mentioning the
documentation is difficult and it's well known that like UNIX manuals the
NR is reference not tutorial. Besides he says this:

"In spite of these difficulties, LilyPond is astoundingly powerful, and
produces very beautiful output "

It's well know that lilypond is hard for beginners and has a steep learning
curve. This is fair comment. The same applies to most powerful software
applications. I don't see this short paragraph in the negative light that
you appear to, and besides, he goes on to give a quick guide to lilypond,
which is useful for people.

Andrew

Post by Reggie
Has anyone else seen this do you know who the author is? Some complaints
about gibberish and documentation and God knows what else. Is this a joke
one or seriously critical of the program? Or in cheek.
http://www.alethis.net/reference/lily/lily.html
--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html
_______________________________________________
lilypond-user mailing list
https://lists.gnu.org/mailman/listinfo/lilypond-user

[David Kastrup]

Post by Reggie
Has anyone else seen this do you know who the author is? Some complaints
about gibberish and documentation and God knows what else. Is this a joke
one or seriously critical of the program? Or in cheek.
http://www.alethis.net/reference/lily/lily.html

Seems to me like an honest impression (though judging the notation
reference for not being an introduction) and it's not like the author
did not actually invest a lot of work both getting to work with LilyPond
and creating instructions for others to do so.

I probably don't consider this outrageous at all because I am cursing
and yelling at LilyPond on a daily basis and would be able to aim my
insults more precisely than that.

[J Martin Rushton]

I'm not sure the single critical paragraph is that unfair. I've turned
the tables on the reviewer and added my own comments as an amateur who
came to Lily only a few years ago.

I did try to send a copy of this email to the company as a courtesy, but
all company information on their website is "Under Construction" and all
personnel pages seem to be family pictures or missing. Make of that
what you will!

A review of the review.
-----------------------

"The documentation is voluminous, but difficult to penetrate."
- Accurate, but slightly unfair. The 'Learning Manual' is straight
forward even if pedestrian at times. 'Usage' is good. 'Music Glossary'
is excellent both with Lily and stand alone. The 'Notation Reference'
is a comprehensive reference guide and is emphatically not newbie friendly.

"I found it difficult to find out about such simple features as the
overall structure of a LilyPond source file."
- I found the same.

"Many commands and features are described without any context
whatsoever, and it becomes a matter of trial and error to determine
exactly how they should be integrated into a source file."
- A consequence of comprehensiveness. The feature is described and a
snippet shown, but fitting it into the complete structure can be
confusing at first.

"And some features that one would expect to be quite simple, seem to be
achievable only by complex and obscure "commands" or "variables".
- I'm not sure I quite follow his argument here.

"One is frequently tempted to attach multiple features to a single note
(e.g. sharp/flat, duration, pitch, slur start or end, phrase start or
end, dynamic mark, crescendo/decrescendo start or end and text are a few
examples!), and it typically requires trial and error to determine which
of the particular orders is the only one that LilyPond accepts."
- Fair comment. As a programmer I'm used to critical ordering so just
accept it. Someone unused to working with source code might get into
difficulties.

"LilyPond source files appear to be written in a custom programming
language whose grammar is never discussed."
- I'm afraid this one is bang on target. However compare the situation
to other systems and at least you can programme rather than just
accepting a proprietary black box.

Post by Reggie
Has anyone else seen this do you know who the author is? Some complaints
about gibberish and documentation and God knows what else. Is this a joke
one or seriously critical of the program? Or in cheek.
http://www.alethis.net/reference/lily/lily.html
--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html
_______________________________________________
lilypond-user mailing list
https://lists.gnu.org/mailman/listinfo/lilypond-user

[David Kastrup]

Post by J Martin Rushton
I'm not sure the single critical paragraph is that unfair. I've turned
the tables on the reviewer and added my own comments as an amateur who
came to Lily only a few years ago.

[...]

Post by J Martin Rushton
"LilyPond source files appear to be written in a custom programming
language whose grammar is never discussed."
- I'm afraid this one is bang on target. However compare the situation
to other systems and at least you can programme rather than just
accepting a proprietary black box.

Well, this author went the mile and actually learnt how to work with
LilyPond before giving it a critical eye (and apparently sticking with
it). I think we lose the majority of potential users even before
getting anywhere as far. It's easy to laugh about those when they write
up their impression, but of course the problem _is_ real.

Frescobaldi is an impressive way to lower the threshold of getting
acquainted with LilyPond's way of working. And Denemo is nice for not
getting all that much acquainted with LilyPond's way of working.

[J Martin Rushton]

Post by David Kastrup

Post by J Martin Rushton
I'm not sure the single critical paragraph is that unfair. I've turned
the tables on the reviewer and added my own comments as an amateur who
came to Lily only a few years ago.

[...]

Post by J Martin Rushton
"LilyPond source files appear to be written in a custom programming
language whose grammar is never discussed."
- I'm afraid this one is bang on target. However compare the situation
to other systems and at least you can programme rather than just
accepting a proprietary black box.

Well, this author went the mile and actually learnt how to work with
LilyPond before giving it a critical eye (and apparently sticking with
it). I think we lose the majority of potential users even before
getting anywhere as far. It's easy to laugh about those when they write
up their impression, but of course the problem _is_ real.
Frescobaldi is an impressive way to lower the threshold of getting
acquainted with LilyPond's way of working. And Denemo is nice for not
getting all that much acquainted with LilyPond's way of working.

Hi David. I'm not quite sure whether you're telling me off for
criticising the original author, or praising me for as "this author"!
In either case may I concur with your comments about Frescobaldi - It is
a nice compromise between GUI/IDE/text and does make life a lot easier
for occasional users. I was going to include Frescobaldi in my email to
Alethis but as I mentioned they don't seem to want to be contacted which
is odd for a "professional software consulting services".

Regards,

Martin

[David Kastrup]

Post by J Martin Rushton

Post by David Kastrup

Post by J Martin Rushton
I'm not sure the single critical paragraph is that unfair. I've turned
the tables on the reviewer and added my own comments as an amateur who
came to Lily only a few years ago.

[...]

Post by J Martin Rushton
"LilyPond source files appear to be written in a custom programming
language whose grammar is never discussed."
- I'm afraid this one is bang on target. However compare the situation
to other systems and at least you can programme rather than just
accepting a proprietary black box.

Well, this author went the mile and actually learnt how to work with
LilyPond before giving it a critical eye (and apparently sticking with
it). I think we lose the majority of potential users even before
getting anywhere as far. It's easy to laugh about those when they write
up their impression, but of course the problem _is_ real.
Frescobaldi is an impressive way to lower the threshold of getting
acquainted with LilyPond's way of working. And Denemo is nice for not
getting all that much acquainted with LilyPond's way of working.

Hi David. I'm not quite sure whether you're telling me off for
criticising the original author, or praising me for as "this author"!

Neither. Sometimes I write stuff without specifically targeting a
victim.

[Sandro Santilli]

Post by J Martin Rushton
"LilyPond source files appear to be written in a custom programming
language whose grammar is never discussed."
- I'm afraid this one is bang on target.

Hey, I have the exact same feeling. Very obscure way to put chords
in parenthesis (I asked yesterday). On the bright side, asking on
this list gets you an answer pretty quickly :)

--strk;

[Thomas Morley]

Post by Sandro Santilli

Post by J Martin Rushton
"LilyPond source files appear to be written in a custom programming
language whose grammar is never discussed."
- I'm afraid this one is bang on target.

Hey, I have the exact same feeling. Very obscure way to put chords
in parenthesis (I asked yesterday).

I beg to differ.
It's the consequence of entering ChordNames as music and the
possibility to have them in midi, let them display as notes in Staff
etc
To keep those features you may try:

parenthesize =
#(define-music-function (dir arg) ((symbol? #f) ly:music?)

#{
$(if dir
#{
\once \override ParenthesesItem.stencils =
#(lambda (grob)
(let ((lp (ly:font-get-glyph
(ly:grob-default-font grob)
"accidentals.leftparen"))
(rp (ly:font-get-glyph
(ly:grob-default-font grob)
"accidentals.rightparen")))
(cond ((eq? dir 'left)
(list lp empty-stencil))
((eq? dir 'right)
(list empty-stencil rp))
(else
(ly:warning "unknown direction: \"~a\", ignoring" dir)
(list lp rp)))))
#})
%% the defaulr parenthesize
$(if (memq 'event-chord (ly:music-property arg 'types))
;; arg is an EventChord -> set the parenthesize property
;; on all child notes and rests
(for-each
(lambda (ev)
(if (or (memq 'note-event (ly:music-property ev 'types))
(memq 'rest-event (ly:music-property ev 'types)))
(set! (ly:music-property ev 'parenthesize) #t)))
(ly:music-property arg 'elements))
;; No chord, simply set property for this expression:
(set! (ly:music-property arg 'parenthesize) #t))
$arg
#})


\new ChordNames
\chordmode {
\override ChordName.stencil =
#(lambda (grob)
(box-stencil
(ly:text-interface::print grob)
0 0))

%% default
\parenthesize c1
%% left paren
\parenthesize #'left c:7
%% right paren
\parenthesize #'right d:5+
%% issues a warning and both parentheses are done
\parenthesize #'whatever ees
}

@ David:
Would this be a useful extension/replacement of our current default
\parenthesize?

Otoh,
it's often requested to enter ChordNames as markup without any nice features.
For this pupose I made
http://lsr.di.unimi.it/LSR/Item?u=1&id=1057
Currently unapproved (as you see it has a pretty verbose description lol)...
It's usable, though.
You could enter:

\new ChordMarkup
\lyricmode {
"C:13" C:alt "C:7.alt" "Gm:7.(b5)/F"
(C D) [Cm Dm]
}

Getting the attached output

Cheers,
Harm

[David Kastrup]

Post by Thomas Morley

Post by Sandro Santilli

Post by J Martin Rushton
"LilyPond source files appear to be written in a custom programming
language whose grammar is never discussed."
- I'm afraid this one is bang on target.

Hey, I have the exact same feeling. Very obscure way to put chords
in parenthesis (I asked yesterday).

I beg to differ.
It's the consequence of ...

"obscure" and "there is a technical reason for it" are not opposites. A
number of decisions of LilyPond's input syntax lead themselves better to
extensibility and sometimes logical coherency which makes it easier to
deduce what to do for things, and what things you read may mean.
LilyPond tries aiming for a best compromise in the direction of
"natural", "obvious", "defensible", "logical" but they are not all the
same. Sometimes one can improve the compromises taken, sometimes this
is hard. At least LilyPond is a better starting point than MusiXTeX.

[m***@ansuz.sooke.bc.ca]

Post by David Kastrup
is hard. At least LilyPond is a better starting point than MusiXTeX.

But MusiXTeX can do "if" statements.

[David Kastrup]

Post by m***@ansuz.sooke.bc.ca

Post by David Kastrup
is hard. At least LilyPond is a better starting point than MusiXTeX.

But MusiXTeX can do "if" statements.

I have a hard time imagining how this is going to hold in a more
convincing manner than you could do it with LilyPond.

[David Sumbler]

-----Original Message-----
From: David Kastrup <***@gnu.org>
To: ***@ansuz.sooke.bc.ca
CC: lilypond-user <lilypond-***@gnu.org>
Subject: Re: Not Nice Review of the LilyPond
Date: Sun, 02 Dec 2018 17:00:33 +0100

Post by m***@ansuz.sooke.bc.ca

Post by David Kastrup
is hard. At least LilyPond is a better starting point than
MusiXTeX.

But MusiXTeX can do "if" statements.

I have a hard time imagining how this is going to hold in a more
convincing manner than you could do it with LilyPond.

***********

I felt that an "if" would be useful, so I eventually came up with:

#(define (iffable? x)
(or (string-or-music? x) (markup? x) (ly:score? x) (ly:book? x)))

iff = #(define-scheme-function
( flag var )
( boolean? iffable? )
(if
flag
(if
(string? var)
(ly:parser-include-string var)
var)))

I am sure that better programmers could do something far more elegant,
but this works for me.

Using this, I can control compilation using variables, with lines such
as:

\iff \Three "\include \"No3_score.ily\""

Instead of a string as in the example, markups, music etc. can also be
included as a result of a successful "iff" test.

I also made a \choice routine, which effectively gives an "else" result
if the test fails, but I have never actually felt any need to use it.

David

[m***@ansuz.sooke.bc.ca]

Post by m***@ansuz.sooke.bc.ca
But MusiXTeX can do "if" statements.

That is useful for conditional includes, but it can't be embedded in the
data structure that LilyPond calls "music" and stores in variables. As
soon as something is turned into "music" it has to be data, not code;
conditionals must either be evaluated before the input is turned into
"music," or by separate code (usually, in Scheme rather than in LilyPond
as such) that conditionally modifies the static "music." That latter
approach, with tags in the "music" that can be filtered out, is what's
usually recommended as a substitute for real conditionals in LilyPond, but
it's quite limiting compared to what programming languages can do with
"if."

For those familiar with programming languages it's not so mysterious why
this situation comes about. LilyPond takes care to call its variables
variables in the documentation. You reference them; you don't execute
them. They contain data, not code. Obviously, data will be the same
every time you look at it, unless you externally change it. But I wish
that without escaping to Scheme I could have something more like a macro
than like a variable, evaluating its conditionals (and doing other
programming-language stuff) every time it is used.

[David Kastrup]

Post by m***@ansuz.sooke.bc.ca

Post by m***@ansuz.sooke.bc.ca
But MusiXTeX can do "if" statements.

That is useful for conditional includes, but it can't be embedded in the
data structure that LilyPond calls "music" and stores in variables. As
soon as something is turned into "music" it has to be data, not code;
conditionals must either be evaluated before the input is turned into
"music," or by separate code (usually, in Scheme rather than in LilyPond
as such) that conditionally modifies the static "music." That latter
approach, with tags in the "music" that can be filtered out, is what's
usually recommended as a substitute for real conditionals in LilyPond, but
it's quite limiting compared to what programming languages can do with
"if."
For those familiar with programming languages it's not so mysterious why
this situation comes about. LilyPond takes care to call its variables
variables in the documentation. You reference them; you don't execute
them. They contain data, not code. Obviously, data will be the same
every time you look at it, unless you externally change it. But I wish
that without escaping to Scheme I could have something more like a macro
than like a variable, evaluating its conditionals (and doing other
programming-language stuff) every time it is used.

Have you looked at tags?

[m***@ansuz.sooke.bc.ca]

Post by David Kastrup
Have you looked at tags?

Please read my messages before responding to them.

[David Sumbler]

-----Original Message-----
From: ***@ansuz.sooke.bc.ca
To: David Sumbler <***@aeolia.co.uk>
CC: David Kastrup <***@gnu.org>, lilypond-user <lilypond-***@gnu.org>
Subject: Re: Not Nice Review of the LilyPond
Date: Sun, 2 Dec 2018 14:17:11 -0500 (EST)

Post by m***@ansuz.sooke.bc.ca
But MusiXTeX can do "if" statements.

That is useful for conditional includes, but it can't be embedded in
the
data structure that LilyPond calls "music" and stores in variables. As
soon as something is turned into "music" it has to be data, not code;
conditionals must either be evaluated before the input is turned into
"music," or by separate code (usually, in Scheme rather than in
LilyPond
as such) that conditionally modifies the static "music." That latter
approach, with tags in the "music" that can be filtered out, is what's
usually recommended as a substitute for real conditionals in LilyPond,
but
it's quite limiting compared to what programming languages can do with
"if."

For those familiar with programming languages it's not so mysterious
why
this situation comes about. LilyPond takes care to call its variables
variables in the documentation. You reference them; you don't execute
them. They contain data, not code. Obviously, data will be the same
every time you look at it, unless you externally change it. But I wish
that without escaping to Scheme I could have something more like a
macro
than like a variable, evaluating its conditionals (and doing other
programming-language stuff) every time it is used.

*************

Well, I'm not quite sure what you are after but this works:

%%%%%%%%%%%%%%%
\version "2.19.81"

#(define (iffable? x)
(or (string-or-music? x) (markup? x) (ly:score? x) (ly:book? x)))

iff = #(define-scheme-function
( flag var )
( boolean? iffable? )
(if
flag
(if
(string? var)
(ly:parser-include-string var)
var)))

partA = ##f

{ b4 b b b
\iff \partA { g g g g }
b1
}
%%%%%%%%%%%%%

Of course, that can be easily done with \tag; I just happen to like
\iff. And the test need not be a single boolean: \iff (or var1 var2)
and other Scheme expressions will work too.

David

[David Kastrup]

Post by David Sumbler
-----Original Message-----
Subject: Re: Not Nice Review of the LilyPond
Date: Sun, 2 Dec 2018 14:17:11 -0500 (EST)

Post by m***@ansuz.sooke.bc.ca
But MusiXTeX can do "if" statements.

That is useful for conditional includes, but it can't be embedded in the
data structure that LilyPond calls "music" and stores in variables. As
soon as something is turned into "music" it has to be data, not code;
conditionals must either be evaluated before the input is turned into
"music," or by separate code (usually, in Scheme rather than in LilyPond
as such) that conditionally modifies the static "music." That latter
approach, with tags in the "music" that can be filtered out, is what's
usually recommended as a substitute for real conditionals in LilyPond, but
it's quite limiting compared to what programming languages can do with
"if."
For those familiar with programming languages it's not so mysterious why
this situation comes about. LilyPond takes care to call its variables
variables in the documentation. You reference them; you don't execute
them. They contain data, not code. Obviously, data will be the same
every time you look at it, unless you externally change it. But I wish
that without escaping to Scheme I could have something more like a macro
than like a variable, evaluating its conditionals (and doing other
programming-language stuff) every time it is used.
*************

For late evaluation, there are a number of callbacks. Including using
the "elements-callback" field on sequential music, by the way. In
particular that latter one makes music length calculations less
dependable, of course, as is to be expected from any late-evaluated
"conditional".

[Sandro Santilli]

Post by Thomas Morley

Post by Sandro Santilli
Very obscure way to put chords
in parenthesis (I asked yesterday).

I beg to differ.

Really ? And right after this statement you post a 36 lines
snippet of code full of parens ? :P

I know Lilypond is powerful, that's why I still use it, but
it's hard not to notice how obscure its code is (what is it,
scheme?)

--strk;

[Thomas Morley]

Post by Sandro Santilli

Post by Thomas Morley

Post by Sandro Santilli
Very obscure way to put chords
in parenthesis (I asked yesterday).

I beg to differ.

Really ? And right after this statement you post a 36 lines
snippet of code full of parens ? :P
I know Lilypond is powerful, that's why I still use it, but
it's hard not to notice how obscure its code is (what is it,
scheme?)
--strk;

The proposed _ly-syntax_ is
\parenthesize <whatever>
\parenthesize #'left <whatever>
\parenthesize #'right <whatever>
No parens.

Obviously this is not default LilyPond, thus I proposed a _function_
which offers it.
This function is written in guile, the scheme-dialect used by LilyPond
as it's extension-language. Btw, it's the official GNU extension
language.
For _usage_ such snippets are usually stored away somewhere and
included in you actual file.

Ofcourse noone will hinder you to dive into the code of the function
or the source-code in general, but you don't need to if you simply
want to use it.



Cheers,
Harm

[Sandro Santilli]

Post by Thomas Morley
The proposed _ly-syntax_ is
\parenthesize <whatever>
\parenthesize #'left <whatever>
\parenthesize #'right <whatever>
No parens.

To be honest I still find that syntax hard to understand.
Replace the 3 <whatever> with A B and C, how would the
above code render those chords ?

I'm guessing it would be:

A ( B C )

But if that's the case, what is the initial \parenthesize for ?

Note I used code found in
http://lists.gnu.org/archive/html/lilypond-user/2016-10/msg00574.html
which has similar hard-to-understand syntax, I used as such:

| g2:6 \leftParen bes2:dim5 |
a4:m7 \rightParen d2:7

Guess how it is rendered ?
For obscure reason, the right paren goes _after_
the d2:7 (which is what I want, but looks weird
in the source code).

Please note: I love the lilypond and even more the _community_ around
it, so don't take my observations as destructive as they really don't
want to be :)

--strk;

[David Kastrup]

Post by Sandro Santilli

Post by Thomas Morley
The proposed _ly-syntax_ is
\parenthesize <whatever>
\parenthesize #'left <whatever>
\parenthesize #'right <whatever>
No parens.

To be honest I still find that syntax hard to understand.
Replace the 3 <whatever> with A B and C, how would the
above code render those chords ?
A ( B C )
But if that's the case, what is the initial \parenthesize for ?
Note I used code found in
http://lists.gnu.org/archive/html/lilypond-user/2016-10/msg00574.html
| g2:6 \leftParen bes2:dim5 |
a4:m7 \rightParen d2:7
Guess how it is rendered ?
For obscure reason, the right paren goes _after_
the d2:7 (which is what I want, but looks weird
in the source code).

\rightParen is a function taking arguments. Function arguments go after
a function.

Post by Sandro Santilli
Please note: I love the lilypond and even more the _community_ around
it, so don't take my observations as destructive as they really don't
want to be :)

There is a difference between superficial aesthetics of input and
inherent logic. LilyPond's input language tries catering quite a bit
for the former but ultimately is disciplined by the latter. There is a
difference between "I can see the music" and "I can see what happens
here". And "I can see what happens here" and "I am in control of what
happens here" and "I can change what happens here" are related and
ultimately make the program more powerful in the hand of experienced
users as well as in the hand of users aided by experienced users.

Some of the sacrifices in the superficial aesthetics are what actually
enables the community around LilyPond (that you love) to actively engage
with your problems, without the need for compiling custom versions of
LilyPond which are in more than one way a dead end and a lot of effort.

In those kinds of overall tradeoffs, I do think that LilyPond is not
doing bad generally.

[Thomas Morley]

Post by Sandro Santilli

Post by Thomas Morley
The proposed _ly-syntax_ is
\parenthesize <whatever>
\parenthesize #'left <whatever>
\parenthesize #'right <whatever>
No parens.

To be honest I still find that syntax hard to understand.
Replace the 3 <whatever> with A B and C, how would the
above code render those chords ?
A ( B C )

No.

Post by Sandro Santilli
But if that's the case, what is the initial \parenthesize for ?

Try it out ;)

The basic problem is that we have no possibility to draw parentheses
around a section of sequential music, but we can parenthesize single
events, with the parenthesize-command.


So now you have the situation to need some functionality doing what
you want _and_ you need to tell LilyPond about it.

Let's do some very fundamental brainstorming.
First: Which syntax would you prefer to tell LilyPond she should draw brackets?
As an example let's take two chord: A B
And two commands: openBracket and closeBracket.
In the end (A B) should be printed, leading to four theoretical syntax
possibilities:
1) openBracket A closeBracket B
2) openBracket A B closeBracket
3) A openBracket closeBracket B
4) A openBracket B closeBracket

The chosen syntax will have consequences. here some of them:
ad 1) This is the syntax you know from the code you use or from my
coding or from most of the workarounds which were created over the
years.
Meaning openBracket and closeBracket are usually commands/functions
doing something with their argument.
These commands and functions are usually overrides or context-settings.
ad 2) This is infix style and general deprecated in LilyPond, although
there's still a single excption, but if you search the NR for infix
you'll notice the remark about dropping this style entirely.
ad 3) I assume we agree this would be weird.
ad 4) This is post fix style and could work only if the commands
initiate something for A and B. One possibility would be a spanner and
the commands would have to be used as post-events. Like \startTextSpan
and \stopTextSpan.
Probably one could think of something at the lines of how fingerings
are printed (left or right), but I guess it would be more complicated.

To summarize:
1) and 4) remain.
Most codings tackling this problem used the 1) syntax. Although 4) is
doable I believe, at least as a spanner, I don't know any attempt
following this route, though

What do you prefer?
Tbh, I don't see any other possibility.

Apart from my LSR-snippet which I linked to already. Did you try it out?

Post by Sandro Santilli
Note I used code found in
http://lists.gnu.org/archive/html/lilypond-user/2016-10/msg00574.html
| g2:6 \leftParen bes2:dim5 |
a4:m7 \rightParen d2:7
Guess how it is rendered ?
For obscure reason,

see above

Post by Sandro Santilli
the right paren goes _after_
the d2:7 (which is what I want, but looks weird
in the source code).
Please note: I love the lilypond and even more the _community_ around
it, so don't take my observations as destructive as they really don't
want to be :)
--strk;

Cheers,
Harm

[David Kastrup]

Post by Sandro Santilli

Post by Thomas Morley

Post by Sandro Santilli
Very obscure way to put chords
in parenthesis (I asked yesterday).

I beg to differ.

Really ? And right after this statement you post a 36 lines
snippet of code full of parens ? :P
I know Lilypond is powerful, that's why I still use it, but
it's hard not to notice how obscure its code is (what is it,
scheme?)

C++. Its own language is hand-crafted syntax, and the extension
language is GUILE, a Scheme dialect. Apart from being Scheme, the
extension language shadows the structure of both the LilyPond language
and its internals pretty closely, to the degree where closures can span
across language barriers. That makes for a much more thorough and
manageable synthesis than, say, LuaTeX with its Lua "extension"
language.

If you think LilyPond's integration of extension language and document
language is "obscure", try LuaTeX. Lua by itself is a procedural
language and thus tends to be more readable to humans than Scheme which
has a more "intuitive" syntax to computers, but integrating Lua with
other languages to the degree Scheme allows for is not there.

It's also hard not to notice what kind of off-the-cuff code can be done
by people acquainted with LilyPond when you ask nicely, and this kind of
code just integrates painlessly into documents.

Make no mistake: the TeX world has its own wizards and masterpieces, but
impressive as they are, they are not "off-the-cuff" and many demonstrate
how to coax TeX in incredibly clever way to do simple things.

[Omer Katzir]

Well, I gotta say. I feel the same as the writer. LP is powerful and extremely accurate. But some things are hard to find in the documents and I think that was the point of the writer.

Sent from my iPhone

Post by Sandro Santilli

Post by Thomas Morley

Post by Sandro Santilli
Very obscure way to put chords
in parenthesis (I asked yesterday).

I beg to differ.

Really ? And right after this statement you post a 36 lines
snippet of code full of parens ? :P
I know Lilypond is powerful, that's why I still use it, but
it's hard not to notice how obscure its code is (what is it,
scheme?)
--strk;
_______________________________________________
lilypond-user mailing list
https://lists.gnu.org/mailman/listinfo/lilypond-user

[Michael Gerdau]

Post by Reggie
http://www.alethis.net/reference/lily/lily.html

Not being a native speaker the finer bashing of LP may have escaped me.

The article obviously is old referring to 2.12 documentation and 2.10.something in the version statement of some examples.

Not sure why I should be upset though.

Kind regards,
Michael