Hi,
Am Fr., 7. Okt. 2022 um 07:44 Uhr schrieb tk5wbps2--- via Discussions
on LilyPond development <lilypond-devel@gnu.org>:
>
> I'm considering contributing to lilypond.
>
welcome to the pond
>
> The two features I propose are as follows.
>
> 1) An option to include rests in tablature (with \tabFullNotation).
>
Afaict, this the default with \tabFullNotation. See the output of:
\new TabStaff \with { \tabFullNotation }
\new TabVoice {
<<
{ r8 r r r }
\\
{ r4 r }
>>
r2
R1*2
\compressEmptyMeasures
R1*7
R1*20
}
>
> 2) An alternative tablature full notation style that more closely resembles
> standard notation note heads and stems.
>
Could you provide some images from printed editions?
>
> To my knowledge as of version 12.13.13
>
Most likely you mean 2.23.13. Though the default behaviour is much older.
>
lilypond engraves tablature numbers for half notes as having two stems
and half notes and whole notes without a circle. I propose an option
for lilypond to engrave tablature numbers for half notes or half-note
chords with a circle and a single stem instead of two stems. Whole
notes and whole-note chords would be circled without a stem. In the
case of multiple voices, the tablature numbers of each voice would be
circled in the group of notes that share a stem. For example, this
could be a set of voices that have half notes sharing a stem pointing
up and an eighth note with a stem pointing down. Numbers corresponding
to half notes would be circled together with an upward stem from the
edge of the circle, and the number corresponding to the eighth note
would not be circled or otherwise changed (except to avoid collision
with the circle, see below). If a voice has a half note with stem
pointing up and another voice has a half note with stem pointing down,
then the two numbers would be circled separately, one with an upward
stem starting at the edge of the first circle and another with a
downward stem starting at the edge of the second circle. In scores
I've seen with circled tablature numbers, collisions between numbers
and circles are avoided by shifting numbers out of a straight vertical
column, which I suspect is quite different than how tablature is
currently handled internally and might require significant effort to
implement, but that's just a guess.
>
Here a quick and hacky mockup:
\new TabStaff \with {
\tabFullNotation
\revert Stem.stencil
\override TabNoteHead.layer = 200
\override TabNoteHead.stencil =
#(grob-transformer 'stencil
(lambda (grob orig)
(let* ((par-x (ly:grob-parent grob X))
(nhds
(if (grob::has-interface par-x 'note-column-interface)
(ly:grob-object par-x 'note-heads #f)
#f))
(thickness 0.1)
(padding 0.02))
(if (and nhds
(eqv? (ly:grob-array-length nhds) 1)
(< (ly:grob-property grob 'duration-log) 2))
(circle-stencil orig thickness padding)
orig))))
\override NoteColumn.stencil =
#(lambda (grob)
(let ((nhds (ly:grob-object grob 'note-heads #f))
(thickness 0.1)
(padding 0.02))
(if (and nhds (> (ly:grob-array-length nhds) 1))
(let ((nhds-x-ext (ly:relative-group-extent nhds grob X))
(nhds-y-ext (ly:relative-group-extent nhds grob Y))
(stem (ly:grob-object grob 'stem)))
(if (< (ly:grob-property stem 'duration-log) 2)
(rounded-box-stencil
(ly:make-stencil '() nhds-x-ext nhds-y-ext)
thickness
padding
1)
'())))))
}
\new TabVoice {
d1 d2 d4 d8 d16 r
<d f a>1
<< < gis b e' >2 \\ < e, b, e > >>
<< { g8 a b g } \\ g2 >>
\mergeDifferentlyHeadedOn
<< { g8 a b g } \\ g2 >>
}
>
> Are either of these features fit for future lilypond?
>
Currently the discussion is about going for a new stable 2.24.
New features will be most likely implemented in 2.25. Though usually
the new stable and the following new devel-version are released at the
same time.
>
> Are either of these features currently present, and I've overlooked them? If
> so, would you like me to contribute documentation?
>
Above mockup needs some love, if you like...
Once it is ready it should be documented ofcourse.
>
> I'm only familiar with a subset of C++ up to C++03. Would my lack of
> knowledge of modern C++ exclude me from being a contributor? I'm also not an
> expert on UB in C++, although I very much want to avoid it. Would that
> exclude me from being a contributor?
>
As you've seen, it was all scheme-work not C++.
I don't know C++ myself. This excludes me from C++ work ofcourse, but
not from scheme-stuff, etc. Many parts in the source are done in
.scm-files.
So this is nothing excluding you from contribution.
>
> If the project is interested in my contributions, we can discuss the first
> feature in more detail. I'd like to start with the first feature to get
> experience with the lilypond source. If all that goes well, then I'd consider
> specifying and working on the second feature.
>
Patches are always welcome!
Discussing projects on this list first is the right way.
Again, welcome to LilyPond.
Cheers,
Harm
