lilypond-user
[Top][All Lists]
Advanced

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

Re: Proposed new available and recommended behavior of \relative


From: David Kastrup
Subject: Re: Proposed new available and recommended behavior of \relative
Date: Sat, 09 Mar 2013 16:33:17 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Olivier Biot <address@hidden> writes:

> On Sat, Mar 9, 2013 at 12:20 AM, David Kastrup <address@hidden> wrote:

[...]

>     > Personally I think that
>     >
>     > c'' \relative { ... }
>     >
>     > is more intuitive than
>     >
>     > \relative c'' { ... }
>     
>     
>     music functions don't look back into context, and if they are in
>     variables, they don't even _have_ context.
>
> I wasn't aware of this - I took for granted that this was needed to
> keep state. Probably \relative does this under the hood.

It walks through the music, calling every expression's
to-relative-callback if available and uses a default conversion if not.
The relative-callback of the resulting expression is transparent, so the
contents of an inner \relative are invisible to an outer one.

> Considering that \relative came as a feature after the core LilyPond
> was written, it makes sense to me now.

No idea about that.  I moved \relative from the parser into a music
function sometime in 2.15.  I don't know about its previous history.

>     The default LilyPond pitch. If you personally think that could be
>     made to work, I am looking forward to your sample implementation.
>
> Well, since there is no state information available as you stated,
> this is going to be tricky indeed, unless we add another command that
> adds some context the same way \relative computes the closest pitch to
> transform a relative pitch expression into absolute pitches.

I don't understand, but presumably we are working from different
assumptions.

>     Or actually even a coherent and comprehensive human-readable
>     definition that could be placed in the manual and would make it
>     possible for a user to predict LilyPond's behavior without
>     experimenting.
>
> I see that as less of a problem. I'd read c'' \relative { e g b } as
> c'', then after this a series of relative pitches starting from the
> last known pitch (or c' - the default LilyPond pitch).

This needs a coherent and comprehensive definition of "last known pitch"
and a definition when "or c'" is going to kick in.  So far this is
mostly hand-waving, and I am quite skeptical it can be taken beyond that
stage.

> Thinking of which, I believe I am struggling with "music entry
> notation" versus "music storage": writing in relative pitch is often
> easier for note entry, but absolute pitches are IMHO better suited for
> storing music.

The result of \relative _is_ stored as absolute pitches.  It is only
very occasionally that pitches are stored as relative, and then LilyPond
does not know about it.  Example:

xxx = { c d e f g }

Relative or absolute?  You can equally well now write

\new Voice { \relative c' \xxx }

or

\new Voice { \xxx }

or even both.  So in _this_ case, pitches have been stored as absolute
as well as relative in the same variable.  But if you write

xxx = \relative c' { c d e f g }

they are stored as absolute pitches, period.  No amount of \relative
placed around \xxx will change its pitches any more.

-- 
David Kastrup



reply via email to

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