Thomas Morley <thomasmorle...@gmail.com> writes:
> 2017-09-16 22:21 GMT+02:00 David Kastrup <d...@gnu.org>:
>> Thomas Morley <thomasmorle...@gmail.com> writes:
>>
>>> 2017-09-16 21:49 GMT+02:00 David Kastrup <d...@gnu.org>:
>>>
>>>> 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
