Re: LSR contribution

[Michael Käppler]

Hi Harm,
sorry that I did not respond for over one month... Many other things had
to be done.
Now I would like to finish this snippet to be free for new interesting
things. ;)

I did substantially rework some parts of the engraver, namely switching
to a list-processing-way of dealing with current/last-grobs/pitches/...
Not sure if you like this change. I like it for less code duplication...

> Hi Michael,
>
> Am Fr., 27. Dez. 2019 um 16:12 Uhr schrieb Michael Käppler <address@hidden>:
> > Hi Harm,
> > thanks for your comments and this inspiring discussion!
> me too!
>
> Iiuc, you want to keep the possibility the user defines the intervaldefs like
> #(define intervaldefs
>     '(("my-prime++" . (0 . 1))
>       ...)
Exactly.
> Fine with me, this should be mentioned in the description/comments,
> probably like
>
> %% Interval definitions alist
> %% Key:
> %% number-string determines the interval type, 1=prime, 2=second, 3=third ...
> %% plus and minus signs determine variant, no sign=perfect interval, +=major,
> %% ++=augmented, -=minor, --=diminished
>
> %% Other strings for the interval-type are possible as well, if given
> to the engraver in the same way.
> (Bad wording, you may get the point, though ... hopefully)
Done.
> Btw, I'd change
>
> %% intervals-given: list of the form
> %%   #`((interval1 ,dir1 enh1 ,color1)
> %%      (interval2 ,dir2 enh2 ,color2)
> %%      ...
> %%      (intervalN ,dirN enhN ,colorN))
> %% with
> %% intervaln: string - specifying the interval to search after
> %% dirn: integer - UP (=1) DOWN (=-1) or 0 (up and down)
> %% enhn: boolean - search for enharmonically equivalent intervals, too?
> %% colorn: lilypond color value, see NR A.7.
>
> to always use capital N for
> intervalN etc
Done. The reason was that I thought of 'n' as the "running" variable
(n=1,2,3 etc.) and 'N' as the last value,
that 'n' finally reaches.
But maybe this was rather misleading.
> > > I found no need to do work in `process-acknowledged`.
> > > Thus all work is done in 'note-head-interface of `acknowledgers`
> > > Probably more efficient, but I have not really checked.
> > I think it is definitily more efficient, since process-acknowledged is
> > called multiple times after
> > one grob has been acknowledged by the engraver. The question is to which
> > extent
> > the "educational" idea of showing the various hooks in action justifies
> > this overhead.
> I think we should go for the current code.
> Other hooks should be thoroughly demonstrated, _if_ they are needed to
> get the desired result.
> In other words, demonstrating process-acknowledged should be left to
> another LSR snippet.
Ok.
> > > Btw, there is one case, where I don't know how to deal with:
> > > 2.18.2 can't cope with an empty engraver, see:
> > >
> > > \score {
> > >     \new Staff \relative c' { c4 d }
> > >     \layout {
> > >       \context {
> > >         \Voice
> > >         \consists \color_interval_engraver #intervaldefs #`(("30-" 0 #t ,green))
> > >       }
> > >     }
> > > }
> > >
> > > No problem for 2.19.83, though.
> > Oh no, further insufficient testing of mine. The following minimal
> > "void" engraver
> > works for me with both 2.18.2 and 2.19.80:
> > `((initialize . ,(lambda (translator) #t)))
> Nice, I'd add a comment about different behaviour of 2.18.2 vs 2.19.x
> accepting an empty list as engraver.
> You go back to the list-syntax, also possible would be:
> (make-engraver ((initialize translator) '()))
Done.
> Some other remarks:
>
> the type-check uses ly:dir?, ofcourse it's my own suggestion to use
> ly:dir?, though probably worth a comment, because the allowed 0 here
> means UP _and_ DOWN as opposed to the usual CENTER.
Done.
> Some comments exceed the 80-characters line-width.
>
> For some strings you circumvent it by doing (string-append "long
> string " "other long string")
> I'll not object to do so. Though, I've no problem to simply put those
> long strings at line-begin or to decrease indentation.
> Even if that means to violate usual indentation-rules.
>
>
> All things mentioned above are micro-issues, imho, I hope you'll not
> tired of me being such a nitpicker.
Not at all. It's interesting to learn from your style!

> And a general one.
>
> If a note is last in previous interval and first in a new one, then
> the color from the new one is done, leaving the first of the previous
> interval with the for it set color:
>
> \score {
>    <<
>      \new Staff { b c' b' }
>      \new Staff { <b c' b'> }
>    >>
>    \layout {
>      \context {
>        \Voice
>        \consists
>          \color_interval_engraver #intervaldefs
>            #`(("2-" 0 #t ,green)
>               ("7+" 0 #t ,red)
>            )
>      }
>    }
> }
>
> No clue how to improve this situation.
You're absolutely right. I think this is unavoidable with this design
(coloring both notes).
I added a warning for this case and, while I was at it, some more debug
output.
Some neat solution would be to draw Horizontal_brackets instead. Thus we
could
correctly represent overlapping intervals, too.
I do not have the time to implement this, however.

Cheers,
Michael

interval-color-engraver-lsr.ly
Description: Text Data