lilypond-user
[Top][All Lists]
Advanced

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

Re: No R in input! (Proposal for discussion)


From: Graham King
Subject: Re: No R in input! (Proposal for discussion)
Date: Sun, 02 Apr 2017 13:00:56 +0100

On Sat, 2017-04-01 at 17:21 +0200, David Kastrup wrote:
> Simon Albrecht <address@hidden> writes:
> 
> > Hello everybody,
> >
> > once again I find myself typesetting ancient music, which poses
> > special challenges with regard to separation of content and
> > presentation. Right now, I’m talking about the fact that bar lines are
> > an editor’s decision and not part of the musical content – different
> > editors might place bar lines after a breve, a semibreve, none at all,
> > or only inbetween staves.
> >
> > This means amongst others that in order to use the same music source
> > for different editions, it should not be hardcoded which rests are
> > MMRs and which aren’t. Also, I don’t think there’s any ambiguity in
> > the following translation: Every rest which fills one or more entire
> > bars should be treated as a MMR by the typesetting engine.
> >
> > Thus, I would like to deliver a plea to perspectively abolish the
> > distinction between r and R in LilyPond source code and have the
> > engravers handle the difference.
> >
> > This would also get us rid of one possibility to make mistakes in engraving.
> >
> > I had this idea right now and it feels too convincing to me to
> > actually be as good as it seems. Hence I’d love to hear your
> > opinions. What complications are there (aside from the effort of
> > implementation) that I fail to see?
> 
> Polyphony can become rather awkward to read if some voice has a full bar
> rest while another has material.
> 
> {
>     << c''1 \\ R1 >>
> }
> 
> Formatting is completely different (multi measure rests are spanners!),
> so articulations etc will behave surprisingly if LilyPond switches on
> its own initiative.
> 
As a fellow-editor of editions from mensural notation, I too would
welcome Simon's proposal to separate presentation from content.  In the
context of such editions, the objections that David identifies would not
arise.
Could Simon's proposal be implemented as an engraver, to be invoked in
such editions alongside Completion_rest_engraver ?
Autoidentify_whole_measure_rest_engraver anyone?




reply via email to

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