lilypond-user
[Top][All Lists]
Advanced

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

Re: The tweak command


From: David Kastrup
Subject: Re: The tweak command
Date: Thu, 20 Sep 2012 15:45:26 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

"Peter Gentry" <address@hidden> writes:

> Doing a bit of study on the tweak command there is some apparent minor
> contradiction.
>
> The manual states categorically that the \tweak command must be
> preceeded by an articulation (often the "use default" articulation -
> is used).

If it says "articulation" that might be an error.  It is more like a
"direction indicator" or something like that, with "-" being the neutral
direction.

> However many examples omit an articulation - is this when a default
> articulation is implied?

No, it is when not an articulation (and/or post-event) is being tweaked
but rather a standalone music expression, one that does not attach to
the preceding music.

> Would it be prudent for a blundering old fogie to always supply an
> articulation even though it may be implied?

No.  In an assigment, there is no change:

xxx=-\tweak ...

and

xxx=\tweak ...

are basically equivalent.  I am saying "basically" here although this is
not quite correct: the first form accepts only a subset of arguments (a
"closed" argument list).  But the _use_ of \xxx afterwards does no
longer know whether - was involved in the assignment.

Inside of a music expression, LilyPond needs to know in advance, before
starting to look at \tweak's arguments, whether you want to use it for
tweaking a postevent or a standalone event.  Again, this will cause
different decisions for parsing the argument list.

The documentation of music functions in the "Extending Guide" has some
details, but the underlying reasons are involved with the categories the
type of parser LilyPond uses can handle in connection with lookahead.

I am currently working on an approach that will enable me to obliterate
most of those annoyingly hairsplitting distinctions that are a real mess
to explain and take into account.  This even tripped me up in
<URL:http://code.google.com/p/lilypond/issues/detail?id=2067#c19> in a
manner I failed to predict.

In 2.14 times, basically only music expressions wrapped in EventChord
were standalone, the rest were postevents (this can't be the whole story
since it would have meant { ... } would have been a postevent after
assigning to a variable, but it is the part of the story I can remember
right now).  Nowadays, the presence of the "post-event" type tag on a
music expression makes this decision, so it is not hard-wired.  But
while this works after assigning to a variable (which then becomes
either a MUSIC_IDENTIFIER or an EVENT_IDENTIFIER as far as the parser is
concerned), it does not work for music functions like \tweak, so you
need to spell out whether it is going to end up as a post-event, using -
before it, when not assigning to a variable but using it in the middle
of an expression.

Making music function calls like \tweak syntactically self-contained,
meaning that you don't need to specifically mark them differently when
using them on post-events rather than standalone expressions, is not
easy to do.  I'm on it.

2.14 at the same time was less powerful, and had quite a few more of
those arbitrary seeming syntactic restrictions concerning music
functions.  So while I am not already where I want to be, I did make
considerable progress.

-- 
David Kastrup




reply via email to

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