lilypond-user
[Top][All Lists]
Advanced

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

Re: Chords in LilyPond


From: Kieren MacMillan
Subject: Re: Chords in LilyPond
Date: Fri, 26 May 2017 14:44:19 -0400

Hi Simon,

> Am 26.05.2017 um 15:48 schrieb address@hidden:
>> On Fri, 26 May 2017, Simon Albrecht wrote:
>>> Well, input syntax does not equal desired output.
>> For ordinary users, it does.
> 
> I have no idea what you’re talking about.

He’s saying that, because chord symbols are essentially just text, the 
“ordinary user” (whatever that actually means?) *expects* to be able to type 
something that looks essentially like the intended output. And, having taught 
(or at least attempted to teach) a number of people to use Lilypond, I can 
confirm that such people do exist.

> from where do you get the idea that a chord symbol that should appear as 
> roughly Gm7(b5)/7 should have to be input in exactly that way?

It’s been so long since I used Finale or Sibelius (thank goodness!), so I can’t 
even remember how those apps deal with chord input/throughput/output. Can 
anyone here comment on what those apps do right, wrong, and indifferent in this 
regard?

In any case, it’s fairly easy to get into such people’s mindset: music notation 
is visually so dissimilar to written text that the “black-box magic” required 
to take an input like ‘c4’ and make an output of beautifully engraved music is 
easy to handwave away; on the other hand, chord symbol notation is visually 
almost identical to text, so the urge for the input to match the output is 
naturally stronger.

> Even with non-semantic markup you’d need at least something like
> \markup { Gm7 \super { 7 \concat { \flat 5 } } /7 }
> and that does not take care of the size of the flat, nor of kerning.

I don’t think that’s precisely true… I mean, by your own admission, typing “c4” 
(which is hardly “semantic markup”) in Lilypond doesn’t result in a [text] c or 
a [numeric] 4, because a large amount of processing and formatting takes place 
after the input-parsing stage is complete. So why would it be impossible to 
write

    Gm7(b5)

and have Lilypond figure out to turn the ‘b' into a flat, raise everything 
after the ‘m’ (if that’s the user’s preference), etc.? And at that point, 
sizing/scaling of the components, kerning, etc., would surely be automatable, 
too. It would be a parser-level change/improvement, almost certainly… but while 
potentially undesirable, I don’t immediately understand why it’s technically 
impossible.

We (well, at least *I*) keep bragging how superior Lilypond is — here’s a 
perfect opportunity to prove it!  =)

Cheers,
Kieren.
________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: address@hidden




reply via email to

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