Hi Simon,
> Am 26.05.2017 um 15:48 schrieb msk...@ansuz.sooke.bc.ca:
>> 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: i...@kierenmacmillan.info
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
