Re: Best name for function to create cross-style noteheads

[Carl Sorensen]

On 7/22/09 8:29 AM, "Kieren MacMillan" <address@hidden>
wrote:

> Hi all,
> 
> Just adding my 2¢...
> 
>>> I might disagree. I'm big on semantics, and I would rather have a
>>> lot of commands that create the same look but mean different
>>> things, than have one command that creates a look which could mean
>>> a lot of different things. I don't know how people will be using
>>> LilyPond in the future, but I'd like for the program not to get
>>> stuck in ambiguous semantics.
>> 
>> I agree with your concern with semantics.
> 
> -1: I would much rather see one WISIWYG (What It Says Is What You
> Get) function rather than multiple WIMGRITSCDF (What It Means Gets
> Resolved Internally To Some Completely Different Function) functions.
> First of all, it minimizes namespace crowding; secondly, it reduces
> confusion and complexity in the docs (no need for crossrefs, etc.).
> 
>> The user semantic would be worse.
> 
> -1: The *composer-user* semantic might [!] be worse, but the
> *engraver-user* semantic would be better.
> 
>> There are two different kinds of semantics that apply.  One is the
>> semantic
>> that the composer sees.  The other is the semantic that the
>> engraver sees.
> 
> If by "engraver" you mean "person who is using Lilypond to engrave",
> then +1.  =)
> 
> The main problem I see in this thread is that we're trying to turn
> Lilypond into a *composing* application rather than thinking of it as
> purely an *engraving* application: when I *compose* for strings (I
> use pen and paper) I create/use/think "harmonics", but when I
> *engrave* the score (I use Lilypond) I code/use/think "diamond".
> 

I think I have a better definition now.  Instead of "user" and "engraver", I
want "music" and "engraving".  The key objective of LilyPond is to have the
author of a LilyPond input file specify only the musical semantics (i.e. the
intended musical meaning).  Then a perfect LilyPond would know exactly what
to do with that musical meaning to make a perfectly-engraved score.

"harmonics" is a muscial semantic; "diamond" is an engraving semantic.  I
think that the closer we get to musical semantics, the better LilyPond input
is.

As an example of this point, I cringe every time I have to tweak something
to make it work, because I'm working in engraving semantics, not musical
semantics.  Moving slur control points is an example of this; there's no
musical content at all in the location of slur control points; it's all
engraving content.   While I want to have access to the engraving content,
I'd prefer never to have to touch it, because a perfect LilyPond would do
all the engraving automatically.  I'd tell it what I want musically; it
would give me perfect output sheet music.

For me, I think the "correct musical semantics" argument overrides the
"don't expand the namespace" argument.

Thanks,

Carl