lilypond-user
[Top][All Lists]
Advanced

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

Re: Not Nice Review of the LilyPond


From: Thomas Morley
Subject: Re: Not Nice Review of the LilyPond
Date: Sun, 2 Dec 2018 21:41:25 +0100

Am So., 2. Dez. 2018 um 19:47 Uhr schrieb Sandro Santilli <address@hidden>:
>
> On Sun, Dec 02, 2018 at 04:53:58PM +0100, Thomas Morley wrote:
> >
> > 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 )

No.

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

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

see above

> 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



reply via email to

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