Re: \mark and slur

[David Kastrup]

Thomas Morley  writes:

> 2017-09-16 22:21 GMT+02:00 David Kastrup :
>> Thomas Morley  writes:
>>
>>> 2017-09-16 21:49 GMT+02:00 David Kastrup :
>>>
 And, uh, it is lacking regtests and documentation.  Because someone for
 some reason finds it less challenging to implement functionality than
 inventing examples using it...
>>>
>>> Absolutely no idea which person you may have in mind ...
>>>
 If you are testing things out anyway, at least regtests should not be
 too far away...
>>>
>>> Will do, at least for regtests and as soon as I find some time.
>>
>> Thanks.  Sorry for my mental laziness.
>
> You? Lazy? Rubbish!

What else to call someone only doing things he enjoys?  I just wish it
felt like more of a choice...

> Here my suggestion for a regtest.

Once the beans are there, I usually enjoy counting them...

> Not sure if we discuss/demonstrate problems in regtests, though.

Well, it's not as much a "problem" as a "limitation".

> Ofcourse the title would be removed (only done for demonstration here)

It's a bit obtrusive as it is now.

> and surpressing the warning probably needs to be adjusted, depending
> how 5194 will be done finally.

Sure.

> \version "2.21.0"
>
> \header {
>   texidoc = "Lone post-events are integrated into surrounding expressions.  
> Making it possible to attach them to expressions stored in variables.
> If no preceding expression is suitable they are attached to an empty chord 
> and a
> warning is printed.
> Though, as a consequence post-events may not be detected correctly, if not 
> inside of sequential music.
> "
> title = 
> \markup \rounded-box \smaller \medium \wordwrap-string \texidoc
> }

The problem is that it's unclear what the regtest display should be like
in order to be self-explanatory.  We have a lot of regtests not exactly
shining in that department...

> #(ly:expect-warning "Adding <>")
>
> nEv = c'4
^"from variable"
> seqM = { d'4 e' }

> addStaccato =
> #(define-music-function (mus)(ly:music?)
> ;; Adds staccato to every note-event
>   (music-map
> (lambda (m) (if (music-is-of-type? m 'note-event) #{ $m -. #} m))
> mus))

Problem with \addStaccato is that it's nice we can define it that way,
but once it is defined, it works independently of what you throw at it.
So it's more useful as an example rather than a test: once the
definition is done, the interpretion of the test results is not really
much related to the feature.

When I looked at the results, I did see it working on several notes in
sequential music inside of sequential music and was wondering how that
corresponded to my code when it was actually the music-map doing the
main work.

> addMarkup =
> #(define-music-function (mus)(ly:music?)
> ;; add TextScript, relying on DynamicText
>   (music-map
> (lambda (m)
>   (if (music-is-of-type? m 'note-event)
>   (let* ((arts (ly:music-property m 'articulations '()))
>  (dyn-present?
>(any
>  (lambda (a) (music-is-of-type? a 
> 'absolute-dynamic-event))

>  arts)))
> (if dyn-present?
> #{ $m _"Dynamic present " #}
Looks weird when the dynamic is _always_ printed.  More like
  #{ $m _\markup { "\\addMarkup" sees \dynamic f }
> #{ $m _"Dynamic not present " #}))
  #{ $m _\markup { "\\addMarkup" doesn't see \dynamic f }
>   m))
> mus))
>
> { 
>   %% tenuto is added to <>, a warning is issues (surpressed here)
>   %% a Slur starts at \nEv
>   -- \nEv ( 
>   %% a Slur-ending is applied to the last element of sequential music.
>   \seqM ) 
>   %% every note gets a staccato
>   \addStaccato { \nEv \seqM }
>   \textLengthOn 
>   %% presence of an absolute-dynamic-event is detected wrongly
>   \addMarkup \nEv \f ^"Selected wrongly"

More like ^"attached late", possibly just ^{"\\addMarkup" "\\nEv" "\\f"}.

>   %% works within sequential music
>   \addMarkup  { \nEv \f } 
>   %% for reference
>   \addMarkup c'\f 
> }

I think I can take it from there, more or less, though tomorrow.  I'll
probably try getting along without music-map in order not to mask too
much what the test is doing/showing.

Thanks for that push!

-- 
David Kastrup

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

Re: \mark and slur

[Thomas Morley]

2017-09-16 22:21 GMT+02:00 David Kastrup :
> Thomas Morley  writes:
>
>> 2017-09-16 21:49 GMT+02:00 David Kastrup :
>>
>>> And, uh, it is lacking regtests and documentation.  Because someone for
>>> some reason finds it less challenging to implement functionality than
>>> inventing examples using it...
>>
>> Absolutely no idea which person you may have in mind ...
>>
>>> If you are testing things out anyway, at least regtests should not be
>>> too far away...
>>
>> Will do, at least for regtests and as soon as I find some time.
>
> Thanks.  Sorry for my mental laziness.

You? Lazy? Rubbish!

Here my suggestion for a regtest. Not sure if we discuss/demonstrate
problems in regtests, though.
Ofcourse the title would be removed (only done for demonstration here)
and surpressing the warning probably needs to be adjusted, depending
how 5194 will be done finally.

Cheers,
  Harm
\version "2.21.0"

\header {
  texidoc = "Lone post-events are integrated into surrounding expressions.  
Making it possible to attach them to expressions stored in variables.
If no preceding expression is suitable they are attached to an empty chord and a
warning is printed.
Though, as a consequence post-events may not be detected correctly, if not 
inside of sequential music.
"
title = 
\markup \rounded-box \smaller \medium \wordwrap-string \texidoc
}

#(ly:expect-warning "Adding <>")

nEv = c'4
seqM = { d'4 e' }

addStaccato =
#(define-music-function (mus)(ly:music?)
;; Adds staccato to every note-event
  (music-map
(lambda (m) (if (music-is-of-type? m 'note-event) #{ $m -. #} m))
mus))

addMarkup =
#(define-music-function (mus)(ly:music?)
;; add TextScript, relying on DynamicText
  (music-map
(lambda (m)
  (if (music-is-of-type? m 'note-event)
  (let* ((arts (ly:music-property m 'articulations '()))
 (dyn-present?
   (any
 (lambda (a) (music-is-of-type? a 'absolute-dynamic-event))
 arts)))
(if dyn-present?
#{ $m _"Dynamic present " #} 
#{ $m _"Dynamic not present " #}))
  m))
mus))

{ 
  %% tenuto is added to <>, a warning is issues (surpressed here)
  %% a Slur starts at \nEv
  -- \nEv ( 
  %% a Slur-ending is applied to the last element of sequential music.
  \seqM ) 
  %% every note gets a staccato
  \addStaccato { \nEv \seqM }
  \textLengthOn 
  %% presence of an absolute-dynamic-event is detected wrongly
  \addMarkup \nEv \f ^"Selected wrongly"
  %% works within sequential music
  \addMarkup  { \nEv \f } 
  %% for reference
  \addMarkup c'\f 
}___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: \mark and slur

[David Kastrup]

Thomas Morley  writes:

> 2017-09-16 21:49 GMT+02:00 David Kastrup :
>
>> And, uh, it is lacking regtests and documentation.  Because someone for
>> some reason finds it less challenging to implement functionality than
>> inventing examples using it...
>
> Absolutely no idea which person you may have in mind ...
>
>> If you are testing things out anyway, at least regtests should not be
>> too far away...
>
> Will do, at least for regtests and as soon as I find some time.

Thanks.  Sorry for my mental laziness.

-- 
David Kastrup

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

Re: \mark and slur

[Thomas Morley]

2017-09-16 21:49 GMT+02:00 David Kastrup :
> David Kastrup  writes:
>
>> Thomas Morley  writes:
>>
>>> If I understand correctly, with this patch [issue 5581] things like
>>> below are now possible:
>>>
>>> xxx = c4
>>> { \xxx -- }
>>
>> Yes.
>>
>>> and
>
>>>   #{ $m -. #}
>>
>> Yes.  #m -. should be fine as well.
>>>
>>> Which is a big, big goody!
>>
>> Well, it's mostly convenience that allows using LilyPond syntax instead
>> of Scheme.
>
> And, uh, it is lacking regtests and documentation.  Because someone for
> some reason finds it less challenging to implement functionality than
> inventing examples using it...

Absolutely no idea which person you may have in mind ...

> If you are testing things out anyway, at least regtests should not be
> too far away...

Will do, at least for regtests and as soon as I find some time.

Cheers,
  Harm

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

Re: \mark and slur

[David Kastrup]

David Kastrup  writes:

> Thomas Morley  writes:
>
>> If I understand correctly, with this patch [issue 5581] things like
>> below are now possible:
>>
>> xxx = c4
>> { \xxx -- }
>
> Yes.
>
>> and

>>   #{ $m -. #}
>
> Yes.  #m -. should be fine as well.
>>
>> Which is a big, big goody!
>
> Well, it's mostly convenience that allows using LilyPond syntax instead
> of Scheme.

And, uh, it is lacking regtests and documentation.  Because someone for
some reason finds it less challenging to implement functionality than
inventing examples using it...

If you are testing things out anyway, at least regtests should not be
too far away...

-- 
David Kastrup

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

Re: \mark and slur

[David Kastrup]

Thomas Morley  writes:

> If I understand correctly, with this patch [issue 5581] things like
> below are now possible:
>
> xxx = c4
> { \xxx -- }

Yes.

> and
>
> foo =
> #(define-music-function (mus)(ly:music?)
>   (music-map
> (lambda (m)
>   (if (music-is-of-type? m 'note-event)
>   #{ $m -. #}

Yes.  #m -. should be fine as well.

>   m))
> mus)
>   #{
> \new ChordNames {
> \tweak self-alignment-X #LEFT
>   \mark "This function is a limited demo, don't use it for any
> other stuff."
> }
> $mus
>   #})
>
> \foo \new Staff \relative c' { c d e f g a b c }
>
> Which is a big, big goody!

Well, it's mostly convenience that allows using LilyPond syntax instead
of Scheme.

> (3)
> In the light of your explanations above I was afraid the following
> would fail (meaning the displayed expression wouldn't be complete):

Why?

> buzz =
> #(define-music-function (mus)(ly:music?)
>   (music-map
> (lambda (m)
>   (if (music-is-of-type? m 'note-event)
>   (begin
> (display-scheme-music (ly:music-property m 'articulations))
> m)
>   m))
> mus)
>   #{
> \new ChordNames {
> \tweak self-alignment-X #LEFT
>   \mark "This function is a limited demo, don't use it for any
> other stuff."
> }
> $mus
>   #})
>
> yyy = c4
>
> \buzz \new Staff { \yyy -\single \dynamicUp \f }

Try { \buzz \yyy -\single \dynamicUp \f } or even { \buzz \yyy \f }

\buzz \yyy will be interpreted _before_ \single \dynamicUp \f is
combined with c4 .

> But as far as I can tell, all works.

No.  You just used input where { } could already reattach the
post-events that did not make it at first try.

> So I can live with the problem of
>
> xxx = c4
> { \void \displayLilyMusic \xxx \f }

It's more extensive than that, but the problem can be contained using
sequential music.

-- 
David Kastrup

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

Re: \mark and slur

[Thomas Morley]

2017-09-16 13:28 GMT+02:00 David Kastrup :
> Thomas Morley  writes:
>
>> Other 5181-topic:
>> In your patch description you wrote about the problem with
>> c-\single \dynamicUp \f
>>
>> Here I can't follow, compiling this with 2.18.2 and current master
>> returns no noticeable difference for me, even using
>> display(Lily)Music.
>> May be I overlooked something.
>> Could you explain a bit more verbose?
>
> From the commit message:
>
> Issue 5181/2: Allow lone postevents in braced lists
>
> Reattaching post-events to a preceding music variable or music
> function call (or expression) is often desired but was unsupported.
>
> This commit caters for the support in braced lists.
>
> The problem with supporting such expressions _everywhere_ is that it
> breaks the use of
>
> The grammar used here is slightly wrong because it uses indicative mode
> for an irrealis.  It should rather be:
>
> The problem with supporting such expressions _everywhere_ would be that
> it would break the use of ... since then \f would be attached to
> \dynamicUp instead of ...
>
> c-\single \dynamicUp \f
>
> since then \f is attached to \dynamicUp instead of becoming the second
> argument to \single, due to operator precedence.  So reattaching lone
> post-events is only done with lower precedence in selected constructs.
>
> This part of the commit message explains why it has not been possible to
> support things like
>
> xxx = c4
>
> { \void \displayLilyMusic \xxx \f }
>
> even while \xxx \f now works.  If the grammar precendences in this case
> would have combined \xxx \f, they would also combine \dynamicUp \f in
> the use case involving \single since \dynamicUp is a bona-fide
> (non-post-event) music expression.
>
> So I just committed with unsuitable grammar for a hypothetical.  You
> will not be able to see the described problem with anything committed to
> the central repository, but there may be a few instances in the reflog
> of my personal repository.  Basically I wanted to commit an
> implementation that happened not to pass the regtests, so I had to scrap
> that approach after convincing myself that this could not otherwise be
> made to work.
>
> --
> David Kastrup

Thanks for the explanations.

(1)
In this thread we mostly discussed what happens for examples like:
{ -"foo" r4 }
especially which sort of warning should be printed.
(I'm fine with 5194 and will comment in this way)
But let me focus on other parts:

(2)
If I understand correctly, with this patch things like below are now possible:

xxx = c4
{ \xxx -- }

and

foo =
#(define-music-function (mus)(ly:music?)
  (music-map
(lambda (m)
  (if (music-is-of-type? m 'note-event)
  #{ $m -. #}
  m))
mus)
  #{
\new ChordNames {
\tweak self-alignment-X #LEFT
  \mark "This function is a limited demo, don't use it for any
other stuff."
}
$mus
  #})

\foo \new Staff \relative c' { c d e f g a b c }

Which is a big, big goody!

(3)
In the light of your explanations above I was afraid the following
would fail (meaning the displayed expression wouldn't be complete):

buzz =
#(define-music-function (mus)(ly:music?)
  (music-map
(lambda (m)
  (if (music-is-of-type? m 'note-event)
  (begin
(display-scheme-music (ly:music-property m 'articulations))
m)
  m))
mus)
  #{
\new ChordNames {
\tweak self-alignment-X #LEFT
  \mark "This function is a limited demo, don't use it for any
other stuff."
}
$mus
  #})

yyy = c4

\buzz \new Staff { \yyy -\single \dynamicUp \f }

But as far as I can tell, all works.

So I can live with the problem of

xxx = c4
{ \void \displayLilyMusic \xxx \f }



Great stuff!!


Cheers,
  Harm

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

Re: \mark and slur

[David Kastrup]

David Kastrup  writes:

> Noeck  writes:
>
>> Hi,
>>
>>> Note or chord or rest or skip or bass figure or cluster note or lyrics
>>> or multimeasure rest.  Something like that.
>>
>> :)
>>
>>> Slur or phrasing slur or absolute dynamic or annote output or arpeggio
>>> or articulation or beam or beam forbid or bendafter or crescendo or
>>> decrescendo or episema or, well, the alphabet is long yet.
>>
>> :) Well that's what I feared.
>>
>>> SlurEvent has the advantage that it is a property of the music
>>> expression one can get and print comparatively easy.
>>
>> I expected something like that. So it would be an easy and helpful
>> improvement of the message. One could also automatically remove the
>> "Event" part.  But there's not much gain.
>
> Slur is a grob type.  slur-event is a stream event class.  At the point
> the error message is triggered, we are processing music expressions.
> For someone without a clue about LilyPond internals, SlurEvent is not
> harder to decipher than Slur, and someone versed in LilyPond will be
> quite confused to read about a Slur in this context.
>
> So there's not just "not much gain" but only confusion to be had by
> trying to masquerade the type of the music expression.  If we try to
> substitute technical terms by handwaving, we are not likely to match the
> hand size of every LilyPond user well.

Further bikeshedding on
, code review at
.

-- 
David Kastrup

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

Re: \mark and slur

[David Kastrup]

Thomas Morley  writes:

> 2017-09-15 1:11 GMT+02:00 David Kastrup :
>> Thomas Morley  writes:
>
 Frankly, what does it even _mean_ to use a
 particular righthand finger and string for a non-existing note?
>>>
>>> Well, that hold as well for:
>>> { -1 -- d' }
>>> but this one works.
>>
>> That's because historically you could do
>>
>> -1-2-3
>>
>> and consequently _equivalently_
>>
>> << 
>>s-1-2-3 >>
>>
>> either of which do the formatting differently from , using
>> the Fingering_engraver rather than the New_fingering_engraver .
>>
>> But this historic crap is so unrelated to issue 5181 that I am not
>> interested in discussing or addressing it in this context.  Issue 5181
>> does not touch it.
>
> Indeed.
> I didn't intend to object, just to point to possible expectations.
> Also, adding post-events to non-existing notes does not make a lot of
> sense, musically speaking, yes.
> But LilyPond accepts already
> { <>^.\fermata }
> Ok, the output is bad, but the "does it make sense?"-argument is then
> not that strong, imho.

I was not talking about post-events in general (which include things
like \< which are partly even positioned deliberately between notes).
But a righthand finger indication or a string number?

Might make sense when putting such execution instructions into a
separate music variable, but they are mostly used for guitar and other
quite explicitly polyphonic instruments so the note/event association
seems important.

-- 
David Kastrup

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

Re: \mark and slur

[Thomas Morley]

2017-09-15 1:11 GMT+02:00 David Kastrup :
> Thomas Morley  writes:

>>> Frankly, what does it even _mean_ to use a
>>> particular righthand finger and string for a non-existing note?
>>
>> Well, that hold as well for:
>> { -1 -- d' }
>> but this one works.
>
> That's because historically you could do
>
> -1-2-3
>
> and consequently _equivalently_
>
> << 
>s-1-2-3 >>
>
> either of which do the formatting differently from , using
> the Fingering_engraver rather than the New_fingering_engraver .
>
> But this historic crap is so unrelated to issue 5181 that I am not
> interested in discussing or addressing it in this context.  Issue 5181
> does not touch it.

Indeed.
I didn't intend to object, just to point to possible expectations.
Also, adding post-events to non-existing notes does not make a lot of
sense, musically speaking, yes.
But LilyPond accepts already
{ <>^.\fermata }
Ok, the output is bad, but the "does it make sense?"-argument is then
not that strong, imho.


Other 5181-topic:
In your patch description you wrote about the problem with
c-\single \dynamicUp \f

Here I can't follow, compiling this with 2.18.2 and current master
returns no noticeable difference for me, even using
display(Lily)Music.
May be I overlooked something.
Could you explain a bit more verbose?


Cheers,
  Harm

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

Re: \mark and slur

[David Kastrup]

Thomas Morley  writes:

> Other 5181-topic:
> In your patch description you wrote about the problem with
> c-\single \dynamicUp \f
>
> Here I can't follow, compiling this with 2.18.2 and current master
> returns no noticeable difference for me, even using
> display(Lily)Music.
> May be I overlooked something.
> Could you explain a bit more verbose?

>From the commit message:

Issue 5181/2: Allow lone postevents in braced lists

Reattaching post-events to a preceding music variable or music
function call (or expression) is often desired but was unsupported.

This commit caters for the support in braced lists.

The problem with supporting such expressions _everywhere_ is that it
breaks the use of

The grammar used here is slightly wrong because it uses indicative mode
for an irrealis.  It should rather be:

The problem with supporting such expressions _everywhere_ would be that
it would break the use of ... since then \f would be attached to
\dynamicUp instead of ...

c-\single \dynamicUp \f

since then \f is attached to \dynamicUp instead of becoming the second
argument to \single, due to operator precedence.  So reattaching lone
post-events is only done with lower precedence in selected constructs.

This part of the commit message explains why it has not been possible to
support things like

xxx = c4

{ \void \displayLilyMusic \xxx \f }

even while \xxx \f now works.  If the grammar precendences in this case
would have combined \xxx \f, they would also combine \dynamicUp \f in
the use case involving \single since \dynamicUp is a bona-fide
(non-post-event) music expression.

So I just committed with unsuitable grammar for a hypothetical.  You
will not be able to see the described problem with anything committed to
the central repository, but there may be a few instances in the reflog
of my personal repository.  Basically I wanted to commit an
implementation that happened not to pass the regtests, so I had to scrap
that approach after convincing myself that this could not otherwise be
made to work.

-- 
David Kastrup

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

Re: \mark and slur

[David Kastrup]

Thomas Morley  writes:

> 2017-09-15 0:25 GMT+02:00 David Kastrup :
>> Thomas Morley  writes:
>>
>>> I'd go for post-event(s)
>>> Plural, because there may be more than one. See example below
>>
>> But every one gets its own warning, so each warning is only for one.
>
> Well, then I'd expect two warnings for:
> { \fermata -- d' }
> because two post-events are present.
> At least the following let me think that _two_ are there:
>
> foo =
> #(define-music-function (mus)(ly:music?)
>   (music-map
> (lambda (m)
>   (if (music-is-of-type? m 'post-event)
>   (begin
> (display-scheme-music m)
> m)
>   m))
> mus))
>
> \foo { \fermata -- d' }
>
> But I only get
> warning: Adding <> for attaching loose post-event
> {
>   \fermata -- d' }
>
> Which I take as _one_ warning.

Ah, you are right.  lily/parser.yy has

bad = scm_cons (scm_car (post), bad);

instead of, say,

bad = scm_append (scm_list_2 (post, bad));

It's only the first post-event which gets flagged with a warning right
now.

> Acknowlegged.
>
>> Frankly, what does it even _mean_ to use a
>> particular righthand finger and string for a non-existing note?
>
> Well, that hold as well for:
> { -1 -- d' }
> but this one works.

That's because historically you could do

-1-2-3

and consequently _equivalently_

<< 
   s-1-2-3 >>

either of which do the formatting differently from , using
the Fingering_engraver rather than the New_fingering_engraver .

But this historic crap is so unrelated to issue 5181 that I am not
interested in discussing or addressing it in this context.  Issue 5181
does not touch it.

>>> Your patch-descriptions reads (among other stuff):
>>>
>>> "Parser: Add reverse_music_list function
>>>
>>> This function does not just reverse a music list but also integrates
>>> post events into the respective preceding expressions. If that is not
>>> possible, a warning is printed and they are either dropped or attached
>>> to an empty chord (depending on a call parameter).
>>> "
>>>
>>> So I'd rather expect a warning if stuff is dropped.
>>
>> It isn't.  Please take a look at the output of \displayMusic .  It is
>> not _dropped_ but rather ignored since no engraver listens for those
>> events and they aren't attached to notes where the
>> New_fingering_engraver would get to consider them.
>>
>> They are part of the expression, as announced.
>
> Ok, I've read "dropped" as dropped from printing, so this was sort of
> misunderstanding on my part.

Well, this _is_ the parser.  It's separate from turning stuff into print
or to Midi.  Stuff that fails to appear in print is admittedly not
really popular with users and probably more surprising than stuff that
fails to appear in Midi.  The situation is better than it was in 2.12
(?) and has not changed recently.

-- 
David Kastrup

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

Re: \mark and slur

[Thomas Morley]

2017-09-15 0:25 GMT+02:00 David Kastrup :
> Thomas Morley  writes:
>
>> I'd go for post-event(s)
>> Plural, because there may be more than one. See example below
>
> But every one gets its own warning, so each warning is only for one.

Well, then I'd expect two warnings for:
{ \fermata -- d' }
because two post-events are present.
At least the following let me think that _two_ are there:

foo =
#(define-music-function (mus)(ly:music?)
  (music-map
(lambda (m)
  (if (music-is-of-type? m 'post-event)
  (begin
(display-scheme-music m)
m)
  m))
mus))

\foo { \fermata -- d' }

But I only get
warning: Adding <> for attaching loose post-event
{
  \fermata -- d' }

Which I take as _one_ warning.

>
>> But
>> { -\3 -\rightHandFinger #2 d'4 }
>> issues the warning, the image doesn't contain the post-events, though.
>> Not a problem of your patch, because a spelled out version fails as well:
>> { <>\3\rightHandFinger #2 d'4 }
>>
>> I guess it's because the post-events are attached to an event-chord
>> and not a note-event, since
>> { d'4\3\rightHandFinger #2 }
>> works as expected. But I'm guessing...
>>
>> Nevertheless, the current warning feels like lily would fix the
>> problem, but doesn't.
>
> It fixes the problem of post-events attached to nothing.

Ok, understood.

> Try
> \displayMusic if you don't believe it.

I did :)

>
> The "problem" of explicit per-note articulations (like string and
> right-finger numbers) not getting engraved when attached to a whole
> chord has always been there.  That they _do_ appear for
> { d'4\3\rightHandFinger #2 } has not been historically the case.  It's
> the somewhat edgy
>
> commit 84cad110c3bbaeca8e5144dba7f8756b89100396
> Author: David Kastrup 
> Date:   Sat Apr 21 22:30:55 2012 +0200
>
> Let rhythmic-engraver make its articulation-or-event decision based on 
> current listeners
>
> This removes the dependency of the rhythmic engraver on a static list
> of unlistened event classes and thus is part of work on issue 2449.
>
> As one effect, string numbers on isolated notes in Voice contexts are
> now typeset by default since the string numbers have no listener in
> Voice contexts even though they would have one in TabVoice.
>
> and similar which does that.

Acknowlegged.

> Frankly, what does it even _mean_ to use a
> particular righthand finger and string for a non-existing note?

Well, that hold as well for:
{ -1 -- d' }
but this one works.

>
>> Your patch-descriptions reads (among other stuff):
>>
>> "Parser: Add reverse_music_list function
>>
>> This function does not just reverse a music list but also integrates
>> post events into the respective preceding expressions. If that is not
>> possible, a warning is printed and they are either dropped or attached
>> to an empty chord (depending on a call parameter).
>> "
>>
>> So I'd rather expect a warning if stuff is dropped.
>
> It isn't.  Please take a look at the output of \displayMusic .  It is
> not _dropped_ but rather ignored since no engraver listens for those
> events and they aren't attached to notes where the
> New_fingering_engraver would get to consider them.
>
> They are part of the expression, as announced.

Ok, I've read "dropped" as dropped from printing, so this was sort of
misunderstanding on my part.


Cheers,
  Harm

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

RE: \mark and slur

[Mark Stephen Mrotek]

David,

Understood. Thank you.

Mark

-Original Message-
From: David Kastrup [mailto:d...@gnu.org] 
Sent: Thursday, September 14, 2017 1:52 PM
To: Mark Stephen Mrotek <carsonm...@ca.rr.com>
Cc: 'Gianmaria Lari' <gianmarial...@gmail.com>; 'lilypond-user'
<lilypond-user@gnu.org>
Subject: Re: \mark and slur

"Mark Stephen Mrotek" <carsonm...@ca.rr.com> writes:

> David Kastrup [mailto:d...@gnu.org]  wrote:
>> <lilypond-user@gnu.org>
>> Subject: Re: \mark and slur
>>
>> "Mark Stephen Mrotek" <carsonm...@ca.rr.com> writes:
>>
>>> Try
>>>
>>> c4 c c d
>>>
>>>(c4^\markup {"X"}) c c c
>>
>> Shrug.  If you insist on that kind of organization you can try
>>
>> \version "2.19.65"
>>
>> \fixed c' {
>>
>>   c4 c c d
>>
>>   (\mark "X" c4) c c c
>>
>> }
>>
>> But it's really a delusion you are getting and becomes rather 
>> strained once you go, like
>>
>> \version "2.19.65"
>>
>> \fixed c' {
>>
>   c4 c c d
>
>   (|\mark "X" c4) c c c
>
> }
>
> What I presented was a suggestion that "worked."
> In no way, shape, or form was it an "insistence."

It was meant as "if _one_ insists on that kind of organization" (rather than
_you_) and referred to you trying to give a version matching the original
spirit which constituted the frame of reference or insistence.

Basically, I saw you as trying to accommodate an assumed insistence rather
than being insistant yourself.  I just don't think that this manner of
writing warrants accommodation: there just are too many cases where it will
get strained to the point of falling apart.

--
David Kastrup


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

Re: \mark and slur

[David Kastrup]

Thomas Morley  writes:

> I'd go for post-event(s)
> Plural, because there may be more than one. See example below

But every one gets its own warning, so each warning is only for one.

> But
> { -\3 -\rightHandFinger #2 d'4 }
> issues the warning, the image doesn't contain the post-events, though.
> Not a problem of your patch, because a spelled out version fails as well:
> { <>\3\rightHandFinger #2 d'4 }
>
> I guess it's because the post-events are attached to an event-chord
> and not a note-event, since
> { d'4\3\rightHandFinger #2 }
> works as expected. But I'm guessing...
>
> Nevertheless, the current warning feels like lily would fix the
> problem, but doesn't.

It fixes the problem of post-events attached to nothing.  Try
\displayMusic if you don't believe it.

The "problem" of explicit per-note articulations (like string and
right-finger numbers) not getting engraved when attached to a whole
chord has always been there.  That they _do_ appear for
{ d'4\3\rightHandFinger #2 } has not been historically the case.  It's
the somewhat edgy

commit 84cad110c3bbaeca8e5144dba7f8756b89100396
Author: David Kastrup 
Date:   Sat Apr 21 22:30:55 2012 +0200

Let rhythmic-engraver make its articulation-or-event decision based on 
current listeners

This removes the dependency of the rhythmic engraver on a static list
of unlistened event classes and thus is part of work on issue 2449.

As one effect, string numbers on isolated notes in Voice contexts are
now typeset by default since the string numbers have no listener in
Voice contexts even though they would have one in TabVoice.

and similar which does that.  Frankly, what does it even _mean_ to use a
particular righthand finger and string for a non-existing note?

> Your patch-descriptions reads (among other stuff):
>
> "Parser: Add reverse_music_list function
>
> This function does not just reverse a music list but also integrates
> post events into the respective preceding expressions. If that is not
> possible, a warning is printed and they are either dropped or attached
> to an empty chord (depending on a call parameter).
> "
>
> So I'd rather expect a warning if stuff is dropped.

It isn't.  Please take a look at the output of \displayMusic .  It is
not _dropped_ but rather ignored since no engraver listens for those
events and they aren't attached to notes where the
New_fingering_engraver would get to consider them.

They are part of the expression, as announced.

-- 
David Kastrup

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

Re: \mark and slur

[Thomas Morley]

Hi David,

I know played a little with your fix issue 5181

On current topic:

2017-09-14 15:57 GMT+02:00 David Kastrup :
> David Kastrup  writes:

> Note: another component that may possibly be included in the warning
> message for this input would be "SlurEvent".  Would
>
> sll.ly:4:13: warning: Adding <> for attaching loose SlurEvent
>\mark "X"
>  (c4) c c c
>
> be any better?

I'd go for post-event(s)
Plural, because there may be more than one. See example below

> Or not mention the expedient of <> at all (might make it
> harder for the user to figure out a workaround for his situation)?

I'd likely drop mentioning <>


Other thoughts.

I tested:

{
  -1
  --
  -\markup "foo"
  -\tweak outside-staff-priority #200
  \upbow
  -\tweak outside-staff-priority #-200
  \fermata
  d'
}

Which throws the warning, but works nicely otherwise.


But
{ -\3 -\rightHandFinger #2 d'4 }
issues the warning, the image doesn't contain the post-events, though.
Not a problem of your patch, because a spelled out version fails as well:
{ <>\3\rightHandFinger #2 d'4 }

I guess it's because the post-events are attached to an event-chord
and not a note-event, since
{ d'4\3\rightHandFinger #2 }
works as expected. But I'm guessing...

Nevertheless, the current warning feels like lily would fix the
problem, but doesn't.


Your patch-descriptions reads (among other stuff):

"Parser: Add reverse_music_list function

This function does not just reverse a music list but also integrates
post events into the respective preceding expressions. If that is not
possible, a warning is printed and they are either dropped or attached
to an empty chord (depending on a call parameter).
"

So I'd rather expect a warning if stuff is dropped.


Cheers,
  Harm

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

Re: \mark and slur

[Flaming Hakama by Elaine]

> From: Noeck 
> Hi,
>
> > warning: Adding <> for attaching loose post-event
>
> I would understand it best if the warning said any of:
>
> Cannot attach slur to preceding expression
> Slur is not attached to note or chord
> Cannot attach slur to note or chord
> No note or chord before this slur to attach it to (is that English?)
> No note or chord is preceeding this slur
>

Regarding the English, some strict grammarians might scoff with sentences
that end with prepositions.  However, this is the way most people talk, so
I wouldn't rule out that formulation on that basis.

Here are some variations to consider that are more grammatical:

Could not find a preceding note or chord to which to attach this slur
Slur is not preceded by a note or chord
Slur lacks a preceding note or chord to which to attach



HTH,

David Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
self-immolation.info
skype: flaming_hakama
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: \mark and slur

[David Kastrup]

"Mark Stephen Mrotek" <carsonm...@ca.rr.com> writes:

> David Kastrup [mailto:d...@gnu.org]  wrote:
>> <lilypond-user@gnu.org>
>> Subject: Re: \mark and slur
>>
>> "Mark Stephen Mrotek" <carsonm...@ca.rr.com> writes:
>>
>>> Try
>>>
>>> c4 c c d
>>>
>>>(c4^\markup {"X"}) c c c
>>
>> Shrug.  If you insist on that kind of organization you can try
>>
>> \version "2.19.65"
>>
>> \fixed c' {
>>
>>   c4 c c d 
>>
>>   (\mark "X" c4) c c c 
>>
>> }
>>
>> But it's really a delusion you are getting and becomes rather strained once
>> you go, like
>>
>> \version "2.19.65"
>>
>> \fixed c' {
>>
>   c4 c c d 
>
>   (|\mark "X" c4) c c c 
>
> }
>
> What I presented was a suggestion that "worked."
> In no way, shape, or form was it an "insistence."

It was meant as "if _one_ insists on that kind of organization" (rather
than _you_) and referred to you trying to give a version matching the
original spirit which constituted the frame of reference or insistence.

Basically, I saw you as trying to accommodate an assumed insistence
rather than being insistant yourself.  I just don't think that this
manner of writing warrants accommodation: there just are too many cases
where it will get strained to the point of falling apart.

-- 
David Kastrup

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

Re: \mark and slur

[David Kastrup]

Noeck  writes:

> Hi,
>
>> Note or chord or rest or skip or bass figure or cluster note or lyrics
>> or multimeasure rest.  Something like that.
>
> :)
>
>> Slur or phrasing slur or absolute dynamic or annote output or arpeggio
>> or articulation or beam or beam forbid or bendafter or crescendo or
>> decrescendo or episema or, well, the alphabet is long yet.
>
> :) Well that's what I feared.
>
>> SlurEvent has the advantage that it is a property of the music
>> expression one can get and print comparatively easy.
>
> I expected something like that. So it would be an easy and helpful
> improvement of the message. One could also automatically remove the
> "Event" part.  But there's not much gain.

Slur is a grob type.  slur-event is a stream event class.  At the point
the error message is triggered, we are processing music expressions.
For someone without a clue about LilyPond internals, SlurEvent is not
harder to decipher than Slur, and someone versed in LilyPond will be
quite confused to read about a Slur in this context.

So there's not just "not much gain" but only confusion to be had by
trying to masquerade the type of the music expression.  If we try to
substitute technical terms by handwaving, we are not likely to match the
hand size of every LilyPond user well.

-- 
David Kastrup

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

Re: \mark and slur

[Noeck]

Hi,

> Note or chord or rest or skip or bass figure or cluster note or lyrics
> or multimeasure rest.  Something like that.

:)

> Slur or phrasing slur or absolute dynamic or annote output or arpeggio
> or articulation or beam or beam forbid or bendafter or crescendo or
> decrescendo or episema or, well, the alphabet is long yet.

:) Well that's what I feared.

> SlurEvent has the advantage that it is a property of the music
> expression one can get and print comparatively easy.

I expected something like that. So it would be an easy and helpful
improvement of the message. One could also automatically remove the
"Event" part.  But there's not much gain.

Joram

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

RE: \mark and slur

[Mark Stephen Mrotek]

David,

What I presented was a suggestion that "worked."
In no way, shape, or form was it an "insistence."

With sincere respect for your work,

Mark

-Original Message-
From: David Kastrup [mailto:d...@gnu.org] 
Sent: Thursday, September 14, 2017 12:10 PM
To: Mark Stephen Mrotek <carsonm...@ca.rr.com>
Cc: 'Gianmaria Lari' <gianmarial...@gmail.com>; 'lilypond-user'
<lilypond-user@gnu.org>
Subject: Re: \mark and slur

"Mark Stephen Mrotek" <carsonm...@ca.rr.com> writes:

> Try
>
> c4 c c d
>
>(c4^\markup {"X"}) c c c

Shrug.  If you insist on that kind of organization you can try

\version "2.19.65"

\fixed c' {

  c4 c c d 

  (\mark "X" c4) c c c 

}

But it's really a delusion you are getting and becomes rather strained once
you go, like

\version "2.19.65"

\fixed c' {

  c4 c c d 

  (|\mark "X" c4) c c c 

}

--
David Kastrup


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

Re: \mark and slur

[David Kastrup]

Noeck  writes:

> Hi,
>
>> warning: Adding <> for attaching loose post-event
>
> I would understand it best if the warning said any of:
>
> Cannot attach slur to preceding expression
> Slur is not attached to note or chord
> Cannot attach slur to note or chord
> No note or chord before this slur to attach it to (is that English?)
> No note or chord is preceeding this slur
>
>
> post-event or SlurEvent sounds too technical for me.

They are intentionally technical.  post-event is a literal text,
SlurEvent would depend on the actual event in question.

> But I don't know if the above wording would be general enough. Is
> "note or chord" correct or just one (perhaps most frequent) case?

Note or chord or rest or skip or bass figure or cluster note or lyrics
or multimeasure rest.  Something like that.

> Can a SlurEvent be something else than a slur? Is there a benefit of
>  calling it SlurEvent instead of slur?

Slur or phrasing slur or absolute dynamic or annote output or arpeggio
or articulation or beam or beam forbid or bendafter or crescendo or
decrescendo or episema or, well, the alphabet is long yet.

SlurEvent has the advantage that it is a property of the music
expression one can get and print comparatively easy.

-- 
David Kastrup

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

Re: \mark and slur

[David Kastrup]

"Mark Stephen Mrotek"  writes:

> Try
>
> c4 c c d 
>
>(c4^\markup {"X"}) c c c

Shrug.  If you insist on that kind of organization you can try

\version "2.19.65"

\fixed c' {

  c4 c c d 

  (\mark "X" c4) c c c 

}

But it's really a delusion you are getting and becomes rather strained
once you go, like

\version "2.19.65"

\fixed c' {

  c4 c c d 

  (|\mark "X" c4) c c c 

}

-- 
David Kastrup

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

Re: \mark and slur

[Noeck]

Hi,

> warning: Adding <> for attaching loose post-event

I would understand it best if the warning said any of:

Cannot attach slur to preceding expression
Slur is not attached to note or chord
Cannot attach slur to note or chord
No note or chord before this slur to attach it to (is that English?)
No note or chord is preceeding this slur


post-event or SlurEvent sounds too technical for me. But I don't know if
the above wording would be general enough. Is "note or chord" correct or
just one (perhaps most frequent) case? Can a SlurEvent be something else
than a slur? Is there a benefit of calling it SlurEvent instead of slur?

The new warning is definitely much clearer than the one before.

Cheers,
Joram

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

RE: \mark and slur

[Mark Stephen Mrotek]

Gianmaria,

 

Try

c4 c c d 

   (c4^\markup {"X"}) c c c

 

Mark

 

From: lilypond-user [mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] 
On Behalf Of Gianmaria Lari
Sent: Thursday, September 14, 2017 2:14 AM
To: lilypond-user 
Subject: \mark and slur

 

This compiles well

 

\version "2.19.65"

\fixed c' {

  c4 c c d 

  (c4) c c c 

}

 

but when I add a \mark like this

 

\version "2.19.65"

\fixed c' {

  c4 c c d 

  \mark "X" (c4) c c c 

}

 

it doesn't. I know the problem is related to the slur and I can move the mark 
before d but why I should not be able to put it at beginning of the second 
measure?

 

Thank you, g.

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

Re: \mark and slur

[David Kastrup]

Rutger Hofman  writes:

> On 14-09-17 15:57, David Kastrup wrote:
>>
>> Note: another component that may possibly be included in the warning
>> message for this input would be "SlurEvent".  Would
>>
>> sll.ly:4:13: warning: Adding <> for attaching loose SlurEvent
>> \mark "X"
>>   (c4) c c c
>>
>> be any better?  Or not mention the expedient of <> at all (might make it
>> harder for the user to figure out a workaround for his situation)?
>>
>> sll.ly:4:13: warning: Cannot attach SlurEvent to preceding expression
>> \mark "X"
>>   (c4) c c c
>
> This one comes closest for me. I think it could be helpful to also
> explain that the 'preceding expression' is not a note, and that that
> is required for a SlurEvent/slur? Or is doing this for all possible
> error scenarios a lifetime job?

This is a compilation warning, not a manual entry.  It should usually
fit one line comfortably.  Flagging the preceding expression as well
with a message of its own seems not helpful since there is nothing
actually wrong with it on its own and since it is, well, the preceding
expression.  It's directly adjacent.

>> or for brevity
>>
>> sll.ly:4:13: warning: unattachable SlurEvent
>> \mark "X"
>>   (c4) c c c
>
> But this is just me; maybe others have different feelings.

Shrug.  Warning messages are no substitute for reading an introduction
into how to use LilyPond, and fallback behavior and suggestions will
usually be modelled on the assumption that people write code that is at
least somewhat similar to code as it should be written and is shown in
the manuals.

LilyPond's error and warning messages will never obviate reading a
tutorial.

So I'm not really excited about the importance of repainting this bike
shed and people who'd very much prefer it differently would be
well-advised to make proposals of their own rather than expecting me to
invest large amounts of time into proposals for which they can then give
performance points.

-- 
David Kastrup

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

Re: \mark and slur

[Rutger Hofman]

On 14-09-17 15:57, David Kastrup wrote:

David Kastrup  writes:


Rutger Hofman  writes:


My preference would be to clearly explain that '(' is an attribute of
the note that directly precedes it.


That's what the "loose post-event" bit is supposed to be about.


Yes, I understand. But still, I fear it is a steep hurdle for the 
uninitiated to understand that 'loose post-event'.



GNU LilyPond 2.21.0
Processing `sll.ly'
Parsing...
sll.ly:4:13: warning: Adding <> for attaching loose post-event
\mark "X"
  (c4) c c c


If you have a better proposal for the error message, let fly.


Note: another component that may possibly be included in the warning
message for this input would be "SlurEvent".  Would


sll.ly:4:13: warning: Adding <> for attaching loose SlurEvent
\mark "X"
  (c4) c c c


be any better?  Or not mention the expedient of <> at all (might make it
harder for the user to figure out a workaround for his situation)?


sll.ly:4:13: warning: Cannot attach SlurEvent to preceding expression
\mark "X"
  (c4) c c c


This one comes closest for me. I think it could be helpful to also 
explain that the 'preceding expression' is not a note, and that that is 
required for a SlurEvent/slur? Or is doing this for all possible error 
scenarios a lifetime job?



or for brevity


sll.ly:4:13: warning: unattachable SlurEvent
\mark "X"
  (c4) c c c


But this is just me; maybe others have different feelings.

Rutger


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

Re: \mark and slur

[David Kastrup]

David Kastrup  writes:

> Rutger Hofman  writes:
>
>> My preference would be to clearly explain that '(' is an attribute of
>> the note that directly precedes it.
>
> That's what the "loose post-event" bit is supposed to be about.
>
 GNU LilyPond 2.21.0
 Processing `sll.ly'
 Parsing...
 sll.ly:4:13: warning: Adding <> for attaching loose post-event
\mark "X"
  (c4) c c c
>
> If you have a better proposal for the error message, let fly.

Note: another component that may possibly be included in the warning
message for this input would be "SlurEvent".  Would

 sll.ly:4:13: warning: Adding <> for attaching loose SlurEvent
\mark "X"
  (c4) c c c

be any better?  Or not mention the expedient of <> at all (might make it
harder for the user to figure out a workaround for his situation)?

 sll.ly:4:13: warning: Cannot attach SlurEvent to preceding expression
\mark "X"
  (c4) c c c

or for brevity

 sll.ly:4:13: warning: unattachable SlurEvent
\mark "X"
  (c4) c c c


-- 
David Kastrup

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

Re: \mark and slur

[David Kastrup]

Rutger Hofman  writes:

> But isn't the start time of this <> the start time of the c4 in the
> second line, so that <>( c4) is equivalent to c4(); which causes the
> warnings 'cannot end slur' for ')' and 'unterminated slur' for '('?

Yes and yes.

> My guess is that this insertion of <> makes things more complicated
> for us, unenlightened users, if anything.

In this case, it leads to followup warnings (rather than a fatal error
bombing out completely): the underlying assumption is that the syntax
needs fixing, not that the complete timing is wrong.

Either way, warnings should always be addressed by the user.  They
indicate something being fishy.

> My preference would be to clearly explain that '(' is an attribute of
> the note that directly precedes it.

That's what the "loose post-event" bit is supposed to be about.

>>> GNU LilyPond 2.21.0
>>> Processing `sll.ly'
>>> Parsing...
>>> sll.ly:4:13: warning: Adding <> for attaching loose post-event
>>>\mark "X"
>>>  (c4) c c c

If you have a better proposal for the error message, let fly.

Me:

>>> Is that more helpful than previously?

Malte:

>> If adding <> is the thing that is done now, of course this is more
>> helpful.

As you can see, Malte isn't of your opinion, and I am less than sure.
Independent of the general impression, the text of the warning might be
subject to improvement.

-- 
David Kastrup

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

Re: \mark and slur

[Rutger Hofman]

But isn't the start time of this <> the start time of the c4 in the 
second line, so that <>( c4) is equivalent to c4(); which causes the 
warnings 'cannot end slur' for ')' and 'unterminated slur' for '('?
My guess is that this insertion of <> makes things more complicated for 
us, unenlightened users, if anything.


My preference would be to clearly explain that '(' is an attribute of 
the note that directly precedes it.


Rutger

On 14-09-17 11:53, Malte Meyn wrote:



Am 14.09.2017 um 11:43 schrieb David Kastrup:

Incidentally, current master delivers the following verbiage:

GNU LilyPond 2.21.0
Processing `sll.ly'
Parsing...
sll.ly:4:13: warning: Adding <> for attaching loose post-event
   \mark "X"
 (c4) c c c
Interpreting music...
sll.ly:4:16: warning: cannot end slur
   \mark "X" (c4
) c c c
sll.ly:4:13: warning: unterminated slur
   \mark "X"
 (c4) c c c
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `/tmp/lilypond-U2WM3z'...
Converting to `sll.pdf'...
Deleting `/tmp/lilypond-U2WM3z'...
Success: compilation successfully completed


Is that more helpful than previously?


If adding <> is the thing that is done now, of course this is more 
helpful. Would it be possible to add that <> in the following warnings 
too? I suppose no because locations in the file would get messed up if 
added things were shown.


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


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

Re: \mark and slur

[Gianmaria Lari]

David Kastrup wrote:


> People tend to ignore warnings
> anyway.


I personally ignore warnings only when I don't see them. And I normally
don't see them when they are in a long list of other information (maybe
written in small character etc. etc :))

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

Re: \mark and slur

[Gianmaria Lari]

Thank you Malte and Phil!

It works well and your suggestion make sense. I normally didn't pay much
attention to this thing, now I will.

Gianmaria

On 14 September 2017 at 11:27, Malte Meyn  wrote:

>
>
> Am 14.09.2017 um 11:14 schrieb Gianmaria Lari:
>
>>c4 c c d
>>(c4) c c c
>>
>
> […]
>
>c4 c c d
>>\mark "X" (c4) c c c
>>
>
> The start of slur belongs to the d, not the c.
>
> Writing
> d (c)
> is possible and equivalent to
> d( c)
> but the latter more clearly says what’s going on.
>
> You tried to write
> d \mark X (c)
> so the \mark X goes between the d and the (. This cannot work, it has to be
> d( \mark X c)
> I would strongly recommend to put slur, beam, tie, … starts directly after
> the note they belong to instead of directly in front of the next note to
> avoid these situations.
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: How near is 2.20? [was: Re: \mark and slur]

[David Kastrup]

Malte Meyn  writes:

> Am 14.09.2017 um 11:43 schrieb David Kastrup:
>> Incidentally, current master delivers the following verbiage:
>>
>> GNU LilyPond 2.21.0
>
> […]
>
>> Is that more helpful than previously?
>>
>> GNU LilyPond 2.19.80
>
> This looks nice :) Do I understand correctly that after 2.19.65
> follows 2.21.0 in the master branch and the new stable/2.20 branch
> does some cherry-picking for 2.19.80+ and 2.20.0? Can you predict
> approximately how long it will take to reach 2.20.0?

Longer than any prediction I make.

> Vorfreude ist die schönste Freude :)

There is still a bad sort-of regression with regard to repeats I want to
fix.  Current productivity/self-motivation is pretty bad, partly because
after my stroke I don't really want to skip on my blood pressure
medication, and blood pressure is related to productivity.  But I'm on
it.

-- 
David Kastrup

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

Re: \mark and slur

[David Kastrup]

Malte Meyn  writes:

> Am 14.09.2017 um 11:43 schrieb David Kastrup:
>> Incidentally, current master delivers the following verbiage:
>>
>> GNU LilyPond 2.21.0
>> Processing `sll.ly'
>> Parsing...
>> sll.ly:4:13: warning: Adding <> for attaching loose post-event
>>\mark "X"
>>  (c4) c c c
>> Interpreting music...
>> sll.ly:4:16: warning: cannot end slur
>>\mark "X" (c4
>> ) c c c
>> sll.ly:4:13: warning: unterminated slur
>>\mark "X"
>>  (c4) c c c
>> Preprocessing graphical objects...
>> Finding the ideal number of pages...
>> Fitting music on 1 page...
>> Drawing systems...
>> Layout output to `/tmp/lilypond-U2WM3z'...
>> Converting to `sll.pdf'...
>> Deleting `/tmp/lilypond-U2WM3z'...
>> Success: compilation successfully completed
>>
>>
>> Is that more helpful than previously?
>
> If adding <> is the thing that is done now, of course this is more
> helpful.

I'm not sure it would help here.  People tend to ignore warnings
anyway.  The idea was to suggest a course that would help in case that
the result is indeed what people wanted.

> Would it be possible to add that <> in the following warnings too? I
> suppose no because locations in the file would get messed up if added
> things were shown.

Locations in the file are locations in the file.  LilyPond does not
change the input.  Creating location markers for imaginary input seems
like a really bad idea.

-- 
David Kastrup

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

How near is 2.20? [was: Re: \mark and slur]

[Malte Meyn]

Am 14.09.2017 um 11:43 schrieb David Kastrup:

Incidentally, current master delivers the following verbiage:

GNU LilyPond 2.21.0


[…]


Is that more helpful than previously?

GNU LilyPond 2.19.80


This looks nice :) Do I understand correctly that after 2.19.65 follows 
2.21.0 in the master branch and the new stable/2.20 branch does some 
cherry-picking for 2.19.80+ and 2.20.0? Can you predict approximately 
how long it will take to reach 2.20.0?


Vorfreude ist die schönste Freude :)

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

Re: \mark and slur

[Malte Meyn]

Am 14.09.2017 um 11:43 schrieb David Kastrup:

Incidentally, current master delivers the following verbiage:

GNU LilyPond 2.21.0
Processing `sll.ly'
Parsing...
sll.ly:4:13: warning: Adding <> for attaching loose post-event
   \mark "X"
 (c4) c c c
Interpreting music...
sll.ly:4:16: warning: cannot end slur
   \mark "X" (c4
) c c c
sll.ly:4:13: warning: unterminated slur
   \mark "X"
 (c4) c c c
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `/tmp/lilypond-U2WM3z'...
Converting to `sll.pdf'...
Deleting `/tmp/lilypond-U2WM3z'...
Success: compilation successfully completed


Is that more helpful than previously?


If adding <> is the thing that is done now, of course this is more 
helpful. Would it be possible to add that <> in the following warnings 
too? I suppose no because locations in the file would get messed up if 
added things were shown.


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

Re: \mark and slur

[David Kastrup]

Malte Meyn  writes:

> Am 14.09.2017 um 11:14 schrieb Gianmaria Lari:
>>c4 c c d
>>(c4) c c c
>
> […]
>
>>c4 c c d
>>\mark "X" (c4) c c c
>
> The start of slur belongs to the d, not the c.
>
> Writing
>   d (c)
> is possible and equivalent to
>   d( c)
> but the latter more clearly says what’s going on.
>
> You tried to write
>   d \mark X (c)
> so the \mark X goes between the d and the (. This cannot work, it has to be
>   d( \mark X c)
> I would strongly recommend to put slur, beam, tie, … starts directly
> after the note they belong to instead of directly in front of the next
> note to avoid these situations.

Incidentally, current master delivers the following verbiage:

GNU LilyPond 2.21.0
Processing `sll.ly'
Parsing...
sll.ly:4:13: warning: Adding <> for attaching loose post-event
  \mark "X" 
(c4) c c c
Interpreting music...
sll.ly:4:16: warning: cannot end slur
  \mark "X" (c4
   ) c c c
sll.ly:4:13: warning: unterminated slur
  \mark "X" 
(c4) c c c
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `/tmp/lilypond-U2WM3z'...
Converting to `sll.pdf'...
Deleting `/tmp/lilypond-U2WM3z'...
Success: compilation successfully completed


Is that more helpful than previously?

GNU LilyPond 2.19.80
Processing `sll.ly'
Parsing...
sll.ly:4:13: error: syntax error, unexpected EVENT_IDENTIFIER
  \mark "X" 
(c4) c c c
sll.ly:2:1: error: errors found, ignoring music expression

\fixed c' {
fatal error: failed files: "sll.ly"


-- 
David Kastrup

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

Re: \mark and slur

[Phil Holmes]

It's not the position of the mark that is wrong - it's the slur.  This applies 
to a note and so must follow the note immediately.  Move the ( to the end of 
the previous line and all will be well.

--
Phil Holmes


  - Original Message - 
  From: Gianmaria Lari 
  To: lilypond-user 
  Sent: Thursday, September 14, 2017 10:14 AM
  Subject: \mark and slur


  This compiles well


\version "2.19.65"
\fixed c' {
  c4 c c d 
  (c4) c c c 
}


  but when I add a \mark like this


\version "2.19.65"
\fixed c' {

  c4 c c d 
  \mark "X" (c4) c c c 
}



  it doesn't. I know the problem is related to the slur and I can move the mark 
before d but why I should not be able to put it at beginning of the second 
measure?


  Thank you, g.


--


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

Re: \mark and slur

[Malte Meyn]

Am 14.09.2017 um 11:14 schrieb Gianmaria Lari:

   c4 c c d
   (c4) c c c


[…]


   c4 c c d
   \mark "X" (c4) c c c


The start of slur belongs to the d, not the c.

Writing
d (c)
is possible and equivalent to
d( c)
but the latter more clearly says what’s going on.

You tried to write
d \mark X (c)
so the \mark X goes between the d and the (. This cannot work, it has to be
d( \mark X c)
I would strongly recommend to put slur, beam, tie, … starts directly 
after the note they belong to instead of directly in front of the next 
note to avoid these situations.


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