lilypond-user
[Top][All Lists]
Advanced

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

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


From: Carl Sorensen
Subject: Re: Best name for function to create cross-style noteheads
Date: Wed, 22 Jul 2009 08:12:26 -0600



On 7/21/09 9:01 PM, "Mark Polesky" <address@hidden> wrote:

> 
> 
> "Trevor Daniels" wrote:
>> Given the wide variation in the use of the
>> x-shaped note head I think the only possible
>> name to use is one that reflects the shape of
>> the note head - crossNote, crossNoteHead or
>> similar - rather than trying to find a suitable
>> generic name which adequately covers all these
>> disparate uses.
> 
> 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.
> 
> Another (smaller) example I've been thinking about recently is the
> diamond notehead. On a string instrument, it means to put your
> finger lightly on the string to activate a specific harmonic node,
> and we have the \harmonic command for that. But on the piano, a
> diamond notehead usually means to push down that piano key
> silently so its strings will vibrate sympathetically. There's no
> \depressSilently command, and there's no \diamond command. Even
> the glyph itself is called s0harmonic, so I'm stuck using
> \harmonic in a case that has nothing to do with harmonics. (Well,
> there *is* a diamond glyph, but it's not the same!)
> 
> Anyway, what's the best solution to this? Imagine if we replaced
> all uses of \harmonic with something like \diamond. Now strings
> and pianos would be on equal terms (I guess), but a lot of
> meaning would be lost.

The user semantic would be worse.  But the internal 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.
We often don't worry about the engraver semantics, since the engraver is
just a program, and the program can do whatever it's told.  But having good
engraver semantics helps new developers become familiar with the code.

Having the production of diamond noteheads be governed by \diamond would be
good engraver semantics.

Having \harmonic available as an alias to \diamond would be good semantics
for string music.

Having \depressSilently or \silentNote available as an alias to \diamond
would be good semantics for keyboard music.

I think it is possible to have all three, and that having all three may be
the best thing to do semantically.

There could be an argument that we don't want to unnecessarily expand the
namespace, but I think that your argument about having correct semantics is
a valid argument.

And I think that the separation of engraver semantics from user semantics is
also a valid distinction.  We do this in programming all the time, even in
LilyPond.  We define an extent (a user semantic) as a pair (a Scheme
semantic).  Then, if we want to change the Scheme semantic for some reason,
we can do so, leaving the user semantic in place.  I believe it makes sense
to do the same for music input, for the same reasons, where there is
semantic user input.

Thanks for starting the discussion on semantics.

Carl





reply via email to

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