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

[Simon Albrecht]

Am 03.04.2017 um 17:08 schrieb David Kastrup:

The full-measure rest thing
would fit that engraver [Completion_rests_engraver] and its niche as another 
option.


This makes a great deal of sense, since I’m using 
Completion_heads_engraver already (for splitting notes at barlines, 
which in a barless part aren’t split). So I’ll probably open a feature 
request in the tracker for that.


Best, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>> Completion_rest_engraver is there.
>
> Ah! Sorry I didn’t think to look. I guess this thread made me assume
> it must not exist.
>
>> It doesn't change r into R.
>
> So this is the point of discussion/contention?
>
> Okay, so…
>
>   SNIPPET BEGINS
> { \time 5/8 c''8*12 }
>
> \score {
> { \time 5/8 c''8*12 }
> \layout {
> \context {
> \Voice
> \remove "Note_heads_engraver"
> \consists "Completion_heads_engraver"
> }
> }
> }
>   SNIPPET ENDS
>
> Here, the engraver properly turns the *12 into two full measures of
> note-duration plus whatever’s left over (i.e., a quarter). If there
> existed a note-head equivalent of R (i.e., “a full measure of
> note-duration, regardless of time signature”), would we not want
> Completion_heads_engraver to use it? (I certainly would!) So how is
> the rest situation different?

Shrug.  Giving Completion_heads_engraver some additional option where it
produces full-measure rests rather than normal rests would be more in
line of being a feasible option.  Though producing compressible
full-measure rests might be rather involved.

Using Completion_rest_engraver does change the semantics.  Exactly
because of dubious semantics there is the context property
completionFactor that is used for determining just what subset of
durations will actually be dealt with usefully.

The engraver is of the "convenient but flawed by design, use at your own
danger" variety that only makes sense as an explicitly user-enabled
option for particular typesetting purposes.  The full-measure rest thing
would fit that engraver and its niche as another option.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[Wols Lists]

On 02/04/17 21:24, David Kastrup wrote:
>> But does it actually demand too much of an engraver to take an r4*7
>> > event, check whether and how many full or partial measures are in its
>> > duration, write full-bar or multi-measure rests for all parts spanning
>> > full measures and normal rests for the remainder?

> What about "is fundamentally different in meaning" was unclear?  The
> rests have completely different visuals, not "just" different alignments
> and different numbers of grobs.

Maybe the bit about "the syntax is meaningless in context?"

As I understand it, in the relevant context, "R" is meaningless but full
or multiple bar rests are printed anyway?

It's ancient music, so all our pre-concieved notions of "correct" are
pretty dodgy, anyway :-)

Cheers,
Wol

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[Kieren MacMillan]

Hi David,

> Completion_rest_engraver is there.

Ah! Sorry I didn’t think to look. I guess this thread made me assume it must 
not exist.

> It doesn't change r into R.

So this is the point of discussion/contention?

Okay, so…

  SNIPPET BEGINS
{ \time 5/8 c''8*12 }

\score {
{ \time 5/8 c''8*12 }
\layout {
\context {
\Voice
\remove "Note_heads_engraver"
\consists "Completion_heads_engraver"
}
}
}
  SNIPPET ENDS

Here, the engraver properly turns the *12 into two full measures of 
note-duration plus whatever’s left over (i.e., a quarter). If there existed a 
note-head equivalent of R (i.e., “a full measure of note-duration, regardless 
of time signature”), would we not want Completion_heads_engraver to use it? (I 
certainly would!) So how is the rest situation different?

Thanks for any clarification you can give.
Kieren.



Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[David Kastrup]

Kieren MacMillan  writes:

> Hi David (et al.),
>
>> I have a hard time understanding how one can consider the visuals of
>> 
>> { \time 2/4 r4*12 }
>> { \time 2/4 R4*12 }
>> 
>> as conveying the same semantics.
>
> I agree that the visuals of those two things do not convey the same semantics.
>
> That being said, I consider the following snippet:
>
> %%%  SNIPPET BEGINS
> \version "2.19.54"
>
> { \time 2/4 c''4*12 }
>
> \score {
> { \time 2/4 c''4*12 }
> \layout {
> \context {
> \Voice
> \remove "Note_heads_engraver"
> \consists "Completion_heads_engraver"
> }
> }
> }
> %%%  SNIPPET ENDS
>
> The [note-data] *input* of these scores is identical — hence they ostensibly 
> convey the same semantics — but the *output* obviously conveys very different 
> semantics. So the addition of the Completion_heads_engraver *changes the 
> semantic space* in a non-trivial way, to the point that the original 
> semantics of the input are (as I understand it) impossible to represent in 
> the new output environment.
>
> As I read it, Simon is simply wondering why there isn’t an equivalent for 
> rests.
> And suddenly I am, too.  =)

Completion_rest_engraver is there.  It doesn't change r into R .

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[Kieren MacMillan]

Hi David (et al.),

> I have a hard time understanding how one can consider the visuals of
> 
> { \time 2/4 r4*12 }
> { \time 2/4 R4*12 }
> 
> as conveying the same semantics.

I agree that the visuals of those two things do not convey the same semantics.

That being said, I consider the following snippet:

%%%  SNIPPET BEGINS
\version "2.19.54"

{ \time 2/4 c''4*12 }

\score {
{ \time 2/4 c''4*12 }
\layout {
\context {
\Voice
\remove "Note_heads_engraver"
\consists "Completion_heads_engraver"
}
}
}
%%%  SNIPPET ENDS

The [note-data] *input* of these scores is identical — hence they ostensibly 
convey the same semantics — but the *output* obviously conveys very different 
semantics. So the addition of the Completion_heads_engraver *changes the 
semantic space* in a non-trivial way, to the point that the original semantics 
of the input are (as I understand it) impossible to represent in the new output 
environment.

As I read it, Simon is simply wondering why there isn’t an equivalent for rests.
And suddenly I am, too.  =)

Cheers,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[David Kastrup]

Simon Albrecht  writes:

> Am 02.04.2017 um 23:56 schrieb David Kastrup:
>> I have
>> a hard time understanding how one can consider the visuals of
>>
>> { \time 2/4 r4*12 }
>> { \time 2/4 R4*12 }
>>
>> as conveying the same semantics.
>
> Well, to me the semantics are ‘maintain silence for the given
> period’.

That's Midi.  It turns out that the typeset output conveys more
information and in a different manner.

> The first of your examples does have different semantics from the
> second one, because anybody reading it would see a quarter rest and
> lots of empty space, wondering what he should do with it, so I can’t
> imagine a usecase for that actual output.

Scaled rests, like scaled durations, have uses.  And in the course of
tuplets, they are even produced automatically.  Their spacing is
different from a rest with a skip IIRC, possibly also in connection with
text scripts.

> (A gap text, obviously, should be coded with skips.)  I’m sorry if I
> seem to be apodictic, I’m genuinely wondering where the flaw is in
> that idea.

Making previously valid input produce completely different output tends
to take more than "people should have done things the way I think best
anyway" reasoning.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[Simon Albrecht]

Am 02.04.2017 um 23:56 schrieb David Kastrup:

I have
a hard time understanding how one can consider the visuals of

{ \time 2/4 r4*12 }
{ \time 2/4 R4*12 }

as conveying the same semantics.


Well, to me the semantics are ‘maintain silence for the given period’. 
The first of your examples does have different semantics from the second 
one, because anybody reading it would see a quarter rest and lots of 
empty space, wondering what he should do with it, so I can’t imagine a 
usecase for that actual output. (A gap text, obviously, should be coded 
with skips.)
I’m sorry if I seem to be apodictic, I’m genuinely wondering where the 
flaw is in that idea.


Best, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[Noeck]

Hi

> I have a hard time understanding how one can consider the visuals of
> 
> { \time 2/4 r4*12 }
> { \time 2/4 R4*12 }
> 
> as conveying the same semantics.

I don't understand what's so hard to understand about Simons question.
Of course there is a difference between the full measure rest and a
normal rest. LilyPond offers the r and R to write them. I learned that
way when learning LP and it always made sense to me. The question is if
that distinction could be done automatically without the user having to
care about it.

Simon's mail makes perfectly sense to me and from all the discussion so
far, I still can't see why the distinction couldn't be done by the
engraver following a given layout setting. The two examples above only
show that LP handles r and R differently (of course).

One situation where I am not sure the automatic algo would do the right
thing is this: Generally, I would use the "R-layout" for rests of one or
more measures. But in a polyphone SATB choir, when only one voice has a
rest lasting the whole measure, is it still that clear? Isn't it more
similar to the half measure rest (r) in the other voice? Perhaps there
are clear rules for that. I just wanted to mention it.

Best,
Joram

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[David Kastrup]

Simon Albrecht  writes:

> Am 02.04.2017 um 22:48 schrieb David Kastrup:
>>> Suppose someone™ made the effort
>>> and folded Multi_measure_rest_engraver into Rest_engraver, why would
>>> such an engraver be fundamentally able to take just one type of rest
>>> and Do The Right Thing™, using ordinary rests or MMRs where
>>> appropriate?
>> Because it wouldn't be the right thing to change one for the other.
>
> Now that’s what I wanted to discuss – sorry for insisting. r and R are
> /engraved/ differently, but – thinking outside the box – as far as I
> can see, there is no semantic difference.

If that's what you wanted to discuss, then how about actually discussing
it rather than making apodictic statements?  I gave an example.  I have
a hard time understanding how one can consider the visuals of

{ \time 2/4 r4*12 }
{ \time 2/4 R4*12 }

as conveying the same semantics.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[Simon Albrecht]

Am 02.04.2017 um 22:48 schrieb David Kastrup:

Suppose someone™ made the effort
and folded Multi_measure_rest_engraver into Rest_engraver, why would
such an engraver be fundamentally able to take just one type of rest
and Do The Right Thing™, using ordinary rests or MMRs where
appropriate?

Because it wouldn't be the right thing to change one for the other.


Now that’s what I wanted to discuss – sorry for insisting. r and R are 
/engraved/ differently, but – thinking outside the box – as far as I can 
see, there is no semantic difference. Nor can I think of a usecase which 
requires distinguishing them in a way that couldn’t just as well be done 
automatically. I’m curious: does anybody have one?


Best, Simon
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[Simon Albrecht]

Am 02.04.2017 um 22:48 schrieb David Kastrup:

Forgive my ignorance, but I don’t know what part of this an engraver
can’t do.

The point is not that it can't be done but that it shouldn't be done.


Oh, sorry for the misconception.
Best, Simon
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[David Kastrup]

Simon Albrecht  writes:

> Am 02.04.2017 um 22:24 schrieb David Kastrup:
>> Simon Albrecht  writes:
>>> Am 02.04.2017 um 15:25 schrieb David Kastrup:
 R4*7 is fundamentally different in meaning (provide 7/4 total amount of
 full-measure rests) from r4*7 (a quarter rest visual with 7 times its
 length).  Full-measure rests are aligned to the middle of the bar, other
 rests are aligned to the beginning of the bar and/or parallel music.
>>> But does it actually demand too much of an engraver to take an r4*7
>>> event, check whether and how many full or partial measures are in its
>>> duration, write full-bar or multi-measure rests for all parts spanning
>>> full measures and normal rests for the remainder?
>> What about "is fundamentally different in meaning" was unclear?  The
>> rests have completely different visuals, not "just" different alignments
>> and different numbers of grobs.
>
> Forgive my ignorance, but I don’t know what part of this an engraver
> can’t do.

The point is not that it can't be done but that it shouldn't be done.

> Completion_rests_engraver checks for barlines and prints one or
> multiple rests depending on these. Suppose someone™ made the effort
> and folded Multi_measure_rest_engraver into Rest_engraver, why would
> such an engraver be fundamentally able to take just one type of rest
> and Do The Right Thing™, using ordinary rests or MMRs where
> appropriate?

Because it wouldn't be the right thing to change one for the other.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[Simon Albrecht]

Am 02.04.2017 um 22:24 schrieb David Kastrup:

Simon Albrecht  writes:

Am 02.04.2017 um 15:25 schrieb David Kastrup:

R4*7 is fundamentally different in meaning (provide 7/4 total amount of
full-measure rests) from r4*7 (a quarter rest visual with 7 times its
length).  Full-measure rests are aligned to the middle of the bar, other
rests are aligned to the beginning of the bar and/or parallel music.

But does it actually demand too much of an engraver to take an r4*7
event, check whether and how many full or partial measures are in its
duration, write full-bar or multi-measure rests for all parts spanning
full measures and normal rests for the remainder?

What about "is fundamentally different in meaning" was unclear?  The
rests have completely different visuals, not "just" different alignments
and different numbers of grobs.


Forgive my ignorance, but I don’t know what part of this an engraver 
can’t do. Completion_rests_engraver checks for barlines and prints one 
or multiple rests depending on these. Suppose someone™ made the effort 
and folded Multi_measure_rest_engraver into Rest_engraver, why would 
such an engraver be fundamentally able to take just one type of rest and 
Do The Right Thing™, using ordinary rests or MMRs where appropriate?


Best, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[David Kastrup]

Simon Albrecht  writes:

> Am 02.04.2017 um 15:25 schrieb David Kastrup:
>> R4*7 is fundamentally different in meaning (provide 7/4 total amount of
>> full-measure rests) from r4*7 (a quarter rest visual with 7 times its
>> length).  Full-measure rests are aligned to the middle of the bar, other
>> rests are aligned to the beginning of the bar and/or parallel music.
>
> But does it actually demand too much of an engraver to take an r4*7
> event, check whether and how many full or partial measures are in its
> duration, write full-bar or multi-measure rests for all parts spanning
> full measures and normal rests for the remainder?

What about "is fundamentally different in meaning" was unclear?  The
rests have completely different visuals, not "just" different alignments
and different numbers of grobs.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[Simon Albrecht]

Am 02.04.2017 um 15:25 schrieb David Kastrup:

R4*7 is fundamentally different in meaning (provide 7/4 total amount of
full-measure rests) from r4*7 (a quarter rest visual with 7 times its
length).  Full-measure rests are aligned to the middle of the bar, other
rests are aligned to the beginning of the bar and/or parallel music.


But does it actually demand too much of an engraver to take an r4*7 
event, check whether and how many full or partial measures are in its 
duration, write full-bar or multi-measure rests for all parts spanning 
full measures and normal rests for the remainder?


Best, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[David Kastrup]

Simon Albrecht  writes:

> Am 01.04.2017 um 17:21 schrieb David Kastrup:
>> Formatting is completely different (multi measure rests are spanners!),
>> so articulations etc will behave surprisingly if LilyPond switches on
>> its own initiative.
>
> I take that as a ‘yes, it’s possible, though the changes required to
> handling of MMRs would be quite fundamental’…

You are taking more than I provide.  A MMR is fundamentally different
from normal rests, more so than how a bordun note (which LilyPond does
not provide for) is fundamentally different from a normal note.

R4*7 is fundamentally different in meaning (provide 7/4 total amount of
full-measure rests) from r4*7 (a quarter rest visual with 7 times its
length).  Full-measure rests are aligned to the middle of the bar, other
rests are aligned to the beginning of the bar and/or parallel music.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[Simon Albrecht]

Am 01.04.2017 um 17:21 schrieb David Kastrup:

Formatting is completely different (multi measure rests are spanners!),
so articulations etc will behave surprisingly if LilyPond switches on
its own initiative.


I take that as a ‘yes, it’s possible, though the changes required to 
handling of MMRs would be quite fundamental’…


Best, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[Graham King]

On Sat, 2017-04-01 at 17:21 +0200, David Kastrup wrote:
> Simon Albrecht  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?


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[Simon Albrecht]

Am 01.04.2017 um 17:21 schrieb David Kastrup:

Polyphony can become rather awkward to read if some voice has a full bar
rest while another has material.

{
 << c''1 \\ R1 >>
}


Well, that has been typographical standard ever since engravers stopped 
center-aligning whole bar _notes_ (around the beginning of the 19th 
century, that was).


Best, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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

[David Kastrup]

Simon Albrecht  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.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

No R in input! (Proposal for discussion)

[Simon Albrecht]

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?


Best, Simon


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user