lilypond-user
[Top][All Lists]
Advanced

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

Re: Align above "current" staff


From: David Wright
Subject: Re: Align above "current" staff
Date: Mon, 28 Sep 2020 10:50:44 -0500
User-agent: Mutt/1.10.1 (2018-07-13)

On Sun 27 Sep 2020 at 23:32:08 (-0700), Aaron Hill wrote:
> On 2020-09-27 7:35 pm, David Wright wrote:
> > I'm not sure that it does produce clarity (as opposed to merely
> > explaining the unreliability in perception). Would it not be
> > clearer to put the ossia music inside a \relative{}, so that
> > the main sequence of pitches carries through undisturbed, and
> > the ossia has its correct octave specified within itself, locally.
> > 
> > I always think it rather risky to put structure inside \relative{},
> > rather than putting the \relative{}s inside the structure.
> 
> \relative is nothing more than a tool for a job.  Providing one
> understands how it works and can manage the sequencing of notes, it is
> not wrong nor unreliable to use at a top-level.  If it were either,
> then LilyPond should not accept such usage.

I agree entirely:

I did not say it's wrong, but risky. Nor that it's unreliable
(AFAICT it's deterministic): I quoted the observation of the OP,
"placing all this inside a \relative is not reliable", which is
their perception.

That wasn't my point, which was that placing structure within
\relative{} sequences increases the burden of remembering
which structures can affect \relative's idea of note order,
and hence octavation. Add enough structure and the benefit of
\relative could be outweighed. Examples on this list abound,
the most common (IMHO) being provoked by tags. My understanding
(which could be flawed) is that some people here recommend never
using \relative on this account.

But my example was designed to ameliorate the problem, just by
enclosing the ossia phrase in its own \relative{}.

> The original \ossia function flips the arguments so the ordering of
> notes behind the scenes as \relative sees them no longer matches the
> natural progression within the input file.  As such, argument order
> matters to accommodate folks who choose to use \relative at the higher
> level and maintain consistency with the existing precedent that
> parallel sections of music are processed in the order they occur
> within the source:

[…]

> But surely the music argument *nearest* the \ossia command should be
> the notes in the ossia itself, regardless of ones preference on using
> \relative.  The alternative seems madness:

Yes, I'd agree that locality is of overriding importance for the
arguments in the call, and also that the function should respect the
note ordering so that \relative works in the expected manner. (The
implementation of that would be "way above my pay-grade".)

Actually, my post didn't express any opinion about ordering, and the
example was based on the Botero one merely because it was easier to
eliminate consideration of clefs too. The recommendation demonstrated
in the example was only to add a \relative to the ossia phrase, and
a further benefit can be illustrated by the attached, which shows
how relatively (!) easy it is to add or remove any number of ossias
if you use this construction.

Removing one is just a matter of commenting out its line (only one
line when used with your sensible ordering of arguments), and adding
one only requires the extra burden of putting { } round the main
sequence of notes covering the same time interval. The octavation of
the original remains undisturbed.

Of course, I would agree that:
  \ossia \relative { f''^"ossia" c g d } { a^"main" f d b }
looks much more tidy and hence understandable than:
  \ossia { a^"main" f d b } \relative { f''^"ossia" c g d }

Even if, as suggested later in the thread, you have ossia-above and
ossia-below, I don't think that should affect this ordering. Any
analogy with the << { } \\ { } >> construction is probably unwise,
as that's something which appears not always to be understood anyway.

Cheers,
David.

Attachment: botero.ly
Description: Text document

Attachment: botero.pdf
Description: Adobe PDF document


reply via email to

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