Anybody else playing with GPT4 and Lilypond?
I've seen some examples of other people succeeding in getting ChatGPT with GPT4 to compose simple music in other text based music formats. I've had limited success getting it to output Lilypond code. It is able to correctly structure the code with a score block, nested contexts, and appropriately named variables, and bar checks at the end of each measure. It seems to struggle to create rhythms that fit within the time signature beyond extremely simple cases. It also seems to struggle a lot to understand what octave pitches will be in when using relative mode. It also seems to have a lot of trouble keeping track of the relationship between notes entered in different simultaneous expressions. Just asking it to repeat back which notes appear in each voice on each beat, GPT4 frequently gives stubbornly incorrect answers about the music it generated. This makes it very difficult to improve its output by giving feedback. I'm curious whether anybody else has tried playing with this. I have to imagine that GPT4 has the potential to produce higher quality Lilypond output, given some of the other impressive things it can do. Perhaps it needs to be provided with a large volume of musical repertoire in Lilypond format.
Re: Anybody else playing with GPT4 and Lilypond?
I think you may have that impression based on GPT3.5. GPT4 is already being
used to generate working non-trivial computer programs based only on a
brief text description.
On Wed, Mar 29, 2023 at 3:58 PM Alexandre Loomis
wrote:
> > given some of the other impressive things it can do
>
> I think that's been exaggerated. It's very good at generating
> plausible-sounding text responses to prompts, everything else looks
> cherry-picked.
>
> On Wed, Mar 29, 2023 at 3:54 PM Nate
> wrote:
>
>> Hah yes. It once said \begn{music} and i said "are you making this up?"
>> "I'm sorry, you're correct. The start tag should be \begin{lilypond}.
>>
>> Its super handy but you have to watch it. It can be a pathological liar.
>> I asked it how to do something on the Akai Mini Play and it said to use
>> this button On the upper left corner. when i asked for clarification
>> instead of admitting it was mistaken it said it was white and next to
>> another button. Twice it doubled down before admitting it was wrong.
>>
>> On Wed, Mar 29, 2023, 6:44 PM Saul Tobin
>> wrote:
>>
>>> I've seen some examples of other people succeeding in getting ChatGPT
>>> with GPT4 to compose simple music in other text based music formats. I've
>>> had limited success getting it to output Lilypond code. It is able to
>>> correctly structure the code with a score block, nested contexts, and
>>> appropriately named variables, and bar checks at the end of each measure.
>>> It seems to struggle to create rhythms that fit within the time signature
>>> beyond extremely simple cases. It also seems to struggle a lot to
>>> understand what octave pitches will be in when using relative mode.
>>>
>>> It also seems to have a lot of trouble keeping track of the relationship
>>> between notes entered in different simultaneous expressions. Just asking it
>>> to repeat back which notes appear in each voice on each beat, GPT4
>>> frequently gives stubbornly incorrect answers about the music it generated.
>>> This makes it very difficult to improve its output by giving feedback.
>>>
>>> I'm curious whether anybody else has tried playing with this. I have to
>>> imagine that GPT4 has the potential to produce higher quality Lilypond
>>> output, given some of the other impressive things it can do. Perhaps it
>>> needs to be provided with a large volume of musical repertoire in Lilypond
>>> format.
>>>
>>
Re: Anybody else playing with GPT4 and Lilypond?
A practical follow up question: what is currently the largest repertoire of publicly available Lilypond scores? Ideally, something like the complete Bach chorales or Mozart piano sonatas. On Wed, Mar 29, 2023 at 3:43 PM Saul Tobin wrote: > I've seen some examples of other people succeeding in getting ChatGPT with > GPT4 to compose simple music in other text based music formats. I've had > limited success getting it to output Lilypond code. It is able to correctly > structure the code with a score block, nested contexts, and appropriately > named variables, and bar checks at the end of each measure. It seems to > struggle to create rhythms that fit within the time signature beyond > extremely simple cases. It also seems to struggle a lot to understand what > octave pitches will be in when using relative mode. > > It also seems to have a lot of trouble keeping track of the relationship > between notes entered in different simultaneous expressions. Just asking it > to repeat back which notes appear in each voice on each beat, GPT4 > frequently gives stubbornly incorrect answers about the music it generated. > This makes it very difficult to improve its output by giving feedback. > > I'm curious whether anybody else has tried playing with this. I have to > imagine that GPT4 has the potential to produce higher quality Lilypond > output, given some of the other impressive things it can do. Perhaps it > needs to be provided with a large volume of musical repertoire in Lilypond > format. >
OLL autotranspose feature release
Hi all, Just want to let everyone know, auto-transpose in OpenLilyLib now has automatically inserted key signatures. https://github.com/openlilylib/oll-misc/tree/master/pitch/auto-transpose Please let me know if you run into any bugs using it. Saul
Re: nested \relative ?
The downsides seem to me like they would be very specific to a given user's workflow. On Sat, Feb 11, 2023 at 6:53 AM Kieren MacMillan < kie...@kierenmacmillan.info> wrote: > Hi Saul, > > > What is the reasoning behind having smaller relative blocks? Generally I > structure my variables as a single \relative block per variable and just > use \resetRelativeOctave at the beginning of every passage. > > One big downside of larger relative blocks is that cut-and-paste coding > becomes problematic. There are many more downsides, but I’ll let others > comment. > > Cheers, > Kieren.
Re: Duplicate marks with removed Staves (frenched)
Hi Simon,
Is there a reason to have the marks in a child context rather than just a
simultaneous music variable?
Saul
On Wed, Feb 8, 2023 at 10:24 AM Simon Albrecht
wrote:
> Hello everyone,
>
> I am working on a large score with several ChoirStaves and want to have
> BarNumbers and Marks in the middle as well. However, when I use
> \RemoveEmptyStaves, removed Staves still have their BarNumbers etc.
>
> How can I solve this without hard-coding where the Staves are removed? Of
> course I could use manual breaks and override the stencils, but that would
> be cumbersome and inflexible.
>
> See the attached/following example—of course it has nothing actually to do
> with the ChoirStaff contexts.
>
> Best, Simon
>
> %
> \version "2.25.0"
>
> \layout {
> \context {
> \Score
> \remove Bar_number_engraver
> \remove Staff_collecting_engraver
> \remove Mark_tracking_translator
> \remove Mark_engraver
> \remove Text_mark_engraver
> }
> \context {
> \ChoirStaff
> \consists Bar_number_engraver
> \consists Staff_collecting_engraver
> \consists Mark_tracking_translator
> \consists Mark_engraver
> \consists Text_mark_engraver
> }
> \context {
> \Staff
> \RemoveEmptyStaves
> }
> }
> marks = \new Devnull {
> s1
> s
> \break
> \mark\default
> s
> \textMark "here"
> s
> \break
> \mark\default
> s
> \textMark "there"
> s
> }
> A = \new Staff { 1 1 s1 s1 1 1 }
> B = \new Staff { 1 1 1 1 1 1 }
> <<
> \new ChoirStaff << \marks \A >>
> \new ChoirStaff << \marks \B >>
> >>
>
Re: Duplicate marks with removed Staves (frenched)
I think the reason is that the mark engravers belong to the staff grouping
context, which isn't removed along with the child staves. Structuring the
code like this avoids the duplicate marks:
\version "2.24.0"
\layout {
\context {
\Score
\remove Bar_number_engraver
\remove Staff_collecting_engraver
\remove Mark_tracking_translator
\remove Mark_engraver
\remove Text_mark_engraver
}
\context {
\ChoirStaff
}
\context {
\Staff
\RemoveEmptyStaves
\consists Bar_number_engraver
\consists Staff_collecting_engraver
\consists Mark_tracking_translator
\consists Mark_engraver
\consists Text_mark_engraver
}
}
marks = {
s1
s
\break
\mark\default
s
\textMark "here"
s
\break
\mark\default
s
\textMark "there"
s
}
A = { 1 1 s1 s1 1 1 }
B = { 1 1 1 1 1 1 }
<<
\new ChoirStaff <<
\new Staff << \marks \A >>
>>
\new ChoirStaff <<
\new Staff << \marks \B >>
>>
>>
Maybe I'm missing a way to do this while keeping the mark engravers in the
ChoirStaff context.
Saul
On Thu, Feb 9, 2023 at 1:29 AM Simon Albrecht
wrote:
> Hi Saul,
> On 08/02/2023 22:03, Saul Tobin wrote:
>
> Is there a reason to have the marks in a child context rather than just a
> simultaneous music variable?
>
>
> You mean the Devnull? Just convenience. It works well with the way I
> assemble different ChoirStaffs for different output formats and adding
> marks to just one or multiple of them as needed.
>
> Now this morning I had an empty extra staff appear on top and I don’t know
> why, but it shouldn’t come from the Devnull.
>
> Best, Simon
>
Re: nested \relative ?
This seems more or less equivalent to religiously putting
\resetRelativeOctave at the beginning of every phrase IMO.
On Sat, Feb 11, 2023 at 2:15 PM Simon Albrecht
wrote:
> On 10/02/2023 19:22, Saul Tobin wrote:
> > What is the reasoning behind having smaller relative blocks?
>
> I agree that there are many factors in the workflow, project and
> templates that influence this decision. I want to give just one example:
> Piano score or similar with changing number and orientation of voices.
>
> One way of setting that up (other staff would work the same): (this got
> longer than I expected, sorry)
>
>
> {
>%\oneVoice
>\relative { %{ some music %} }
><<
> \relative {
>\voiceOne
>% more music
> }
> \new Voice \relative {
>\voiceTwo
>% parallel music
> }
>>>
>\oneVoice
>\relative {
> % continue main voice without worrying about which pitch is preceding
>}
><<
> \relative {
>% independent polyphonic part
> }
> \\
> \relative {
>% can freely switch around voices during editing
>% without worrying about wrong pitches
> }
>>>
> }
>
> Another way the same thing could be set up:
>
> <<
>\new Voice = "default" {
> % one music expression for everything that’s oneVoice
> \relative {
>% first section of music
>% then I choose to stay in the music expression because it
>% immediately continues
>\voiceOne
>% second section
>\oneVoice
> }
> % now there’s a change of register, and instead of calculating
> % the number of octaves it is displaced, I just open a new
> \relative {
>% third section of music
> }
> % fourth section of music begins afresh, so I skip in this
> % music expression
> s32*7
>}
>\new Voice = "voiceOne" {
> \voiceOne
> % skips for first through third section
> \relative {
>% music for the fourth section, again just specify the first
>% pitch in absolute so I’m safe against future edits
> }
>}
>\new Voice = "voiceTwo" {
> \voiceTwo
> % skip a bit, but then...
> \voiceThree
> % I realise that I forgot a couple notes in voiceThree, but they
> % won’t influence any other pitches because of the independent
> % relative blocks
> \relative {
>% couple notes
> }
> % more skips
> \relative {
>\voiceTwo
>% second section
>% voiceXXX command inside or outside relative is of course
>% completely irrelevant and just personal preference
> }
> % skips
> {
>% fourth section is just a pedal point and doesn’t need
>% relative at all
>a,,,1~ 32.. 128 4
> }
>}
> >>
>
>
> Best, Simon
>
>
Re: Documentation: Should we possibly have aliases for current stable and current devel?
Many users have old projects on very old versions of Lilypond, and sometimes you just want to make a small edit, not update your whole project to use the new version. It's important for documentation to be available. On Mon, Feb 13, 2023, 8:41 AM Kevin Cole wrote: > On Mon, Feb 13, 2023 at 11:33 AM Lukas-Fabian Moser wrote: > > > > Hi Kevin, > > > > > On the other hand, I strongly favor sticking with a distribution's > > > package rather than starting every day with a "git pull". So, I'm > > > always slightly behind the latest and greatest. > > > > Just for the record: Your description omits the (actually quite > > convenient) middle between the two extremes: Namely, that it's quite > > easy to keep up with current LilyPond development by downloading and > > using the respective (unstable) builds that are released every few weeks > > to months. > > The point I was trying to make was "Does there REALLY need to be > documentation for versions 2.13 to 2.25? Maybe 2.20 to 2.25 would > suffice." > >
Re: Understanding marks in 2.24
I realized that the duplication is actually not an issue when using a
MarkLine context, since it isn't collecting the events from multiple
contexts, it's just listening to the event from the MarkLine itself. I
guess I'll just stick with this way of doing things.
\version "2.24.0"
\language "english"
\layout {
\context {
\name "MarkLine"
\type "Engraver_group"
\consists Axis_group_engraver
\consists Mark_engraver
\consists Metronome_mark_engraver
\consists Text_mark_engraver
\override VerticalAxisGroup.staff-affinity = #DOWN
}
\context {
\Score
\accepts MarkLine
\remove Mark_engraver
\remove Metronome_mark_engraver
\remove Text_mark_engraver
}
}
global = {
\mark\default
\tempo "foo"
s1
\mark\default
\tempo "foo"
s1
\mark\default
\tempo "foo"
s1
\textMark "foo"
s1
}
music = \relative c'' {
bf4 a c b
bf4 a c b
bf''4 a,, c b
bf4 a c b
}
\score {
<<
\new MarkLine \global
\new StaffGroup <<
\new Staff << \global \music >>
\new Staff << \global \music >>
>>
>>
}
On Tue, Jan 31, 2023 at 1:55 PM Saul Tobin
wrote:
> IMO deduplication wouldn't really be semantically contradictory, because
> the goal of allowing multiple simultaneous marks is to allow for multiple
> *different* marks at the same moment. And you could always have a context
> property to switch deduplication on/off.
>
> The scheme evaluation challenges seem like the bigger issue.
>
> Typically, the way I structure a score is to have a \global variable
> containing skips + all the information shared across all players, such as
> key, time, and marks. It goes a bit counter to that structure to either
> separate out \textMarks into their own variable or to use tagging to
> control where they display in the full score. Certainly doable, but IMO it
> would be worth at least clarifying in the documentation.
>
> Thanks for the detailed response!
>
> On Tue, Jan 31, 2023 at 1:48 PM Jean Abou Samra
> wrote:
>
>> On 31/01/2023 22:33, Jean Abou Samra wrote:
>> > Uh, why did I just write this already? The latter wouldn't
>> > be a problem. assign_event_once uses "equal?" The former,
>> > with procedures, is indeed a problem.
>> >
>> > Sorry for the noise.
>>
>>
>> Looking a bit more into define-markup-commands.scm, this
>> will occur at least with
>>
>> \markup \score
>> \markup \score-lines
>> \markup \stencil
>> \markup \on-the-fly
>> \markup \with-string-transformer
>> \markup \if
>> \markup \unless
>>
>> e.g.
>>
>> <<
>> \new Staff { \mark \markup A c' }
>> \new Staff { \mark \markup A c' }
>> >>
>>
>> vs.
>>
>> <<
>> \new Staff { \mark \markup \score { c' } c' }
>> \new Staff { \mark \markup \score { c' } c' }
>> >>
>>
>>
>> Also, allowing several text marks at the same moment
>> is one of the root motivations for \textMark, so
>> deduplicating based on markup equality would feel
>> (IMHO) surprising.
>>
>>
>>
Understanding marks in 2.24
Hi all,
I'm in the process of updating my scores from 2.18 to 2.24 (yes I skipped a
bunch of versions), and I'm trying to understand the intended use of the
new types of marks.
Take the following small example:
\version "2.24.0"
\language "english"
markGroup = \with {
\consists Mark_engraver
\consists Staff_collecting_engraver
\consists Metronome_mark_engraver
\consists Text_mark_engraver
}
music = \relative c'' {
\mark \default
\tempo "foo"
bf a c b
\mark \default
\tempo "foo"
bf a c b
\mark \default
\tempo "foo"
bf'' a,, c b
\textMark "foo"
bf a c b
}
\score {
<<
\new StaffGroup \with {
\markGroup
} <<
\new Staff \music
\new Staff \music
>>
\new StaffGroup \with {
\markGroup
}
<<
\new Staff \music
\new StaffGroup <<
\new Staff \music
\new Staff \music
>>
>>
>>
\layout {
\context {
\Score
\remove Mark_engraver
\remove Staff_collecting_engraver
\remove Metronome_mark_engraver
\remove Text_mark_engraver
}
}
}
I have a few questions:
1. How to achieve horizontal alignment and avoid vertical overlap of
RehearsalMarks and MetronomeMarks at the beginning of a system, or when
musical objects push them away from the staff as in measure 3? I have to
say I think the default output could be improved.
2. How to prevent TextMarks from printing many identical marks at the same
point in time? The docs suggest that \textMark should be used as a drop-in
replacement for \mark \markup... but the behavior seems incompatible. The
examples given are for instructions specific to a single player. Is it
feasible to use \textMark for ensemble-wide instructions without relying on
tags to prevent duplicates in the full score?
3. I formerly used a custom MarkLine context to align all marks on the same
horizontal baseline. I see that LSR lists the snippet as deprecated since a
bug was fixed that allowed mark engravers to be moved to StaffGroups
(though it is still referenced in the 2.24 docs here:
https://lilypond.org/doc/v2.24/Documentation/snippets/contexts-and-engravers#contexts-and-engravers-using-marklines-in-a-frenched-score).
Is there another preferred method to baseline-align all marks in a system?
4. What is the difference between an AdHocMark and a RehearsalMark? I find
some references to AdHocMark in the Internals docs but I'm unclear how to
actually use them.
Thanks!
Saul
Re: \stopStaff \startStaff spacing & line continuity
I believe this may be a case where you need to use \applyOutput, as
documented here:
https://extending-lilypond.readthedocs.io/en/latest/extending/translation.html#tweaking-grobs-during-translation
.
On Tue, Jan 31, 2023 at 5:57 PM Ahanu Banerjee
wrote:
> I am trying to modify the color of the ledger lines for a single note. My
> understanding is that I need to use \stopStaff and \startStaff for this.
> However, doing so causes the staff lines to be discontinuous. This rounds
> the ends of the staff lines surrounding the point at which the staff is
> stopped and causes adjacent notes to have increased horizontal spacing. How
> can this be avoided?
>
> See code below.
>
> \version "2.24.0"
> \language "english"
> { g8 \stopStaff \startStaff
> \once \override Staff.LedgerLineSpanner.color = green
> g \stopStaff \startStaff g g }
>
> Thanks,
> -Ahanu
>
Re: Understanding marks in 2.24
On Tue, Jan 31, 2023 at 1:32 PM Jean Abou Samra wrote: > On 31/01/2023 22:07, Saul Tobin wrote: > > I have a few questions: > > 1. How to achieve horizontal alignment and avoid vertical overlap of > RehearsalMarks and MetronomeMarks at the beginning of a system, or when > musical objects push them away from the staff as in measure 3? I have to > say I think the default output could be improved. > > > It's been requested a few times, but there is no easy way to do this > at the moment (although you can find some hacks in the list archives). > The hack that I used in the past was to set extra-spacing-width to something like #'(0 . 0) for both types of marks, but it seems like when systems are vertically compressed, this can interfere with the spacing of the music. Is there a way to prevent that from happening? (Or a better grob property to use to get the marks to line up?) Attached is an example in which the minimal output looks correct, but essentially the same code in the context of my full score screws up the spacing. I can achieve similar bad output in the minimal example by leaving Staff_collecting_engraver in Score instead of moving it to MarkLine (which I don't entirely understand). Bizarrely, the only thing I've tried that produces correct output everywhere I've checked is \override MetronomeMark.extra-spacing-width = #'(0 . +inf.0), which is nonsensical and emits tons of warnings. markline.ily Description: Binary data
Error in Extending Lilypond example
The fourth example engraver here: https://extending-lilypond.readthedocs.io/en/latest/extending/translation.html#fourth-engraver-example Running this code in 2.24 crashes on initializing the engraver with In procedure ly:spanner-set-bound!: Wrong type argument in position 3 (expecting Item): ().
Re: Understanding marks in 2.24
IMO deduplication wouldn't really be semantically contradictory, because
the goal of allowing multiple simultaneous marks is to allow for multiple
*different* marks at the same moment. And you could always have a context
property to switch deduplication on/off.
The scheme evaluation challenges seem like the bigger issue.
Typically, the way I structure a score is to have a \global variable
containing skips + all the information shared across all players, such as
key, time, and marks. It goes a bit counter to that structure to either
separate out \textMarks into their own variable or to use tagging to
control where they display in the full score. Certainly doable, but IMO it
would be worth at least clarifying in the documentation.
Thanks for the detailed response!
On Tue, Jan 31, 2023 at 1:48 PM Jean Abou Samra wrote:
> On 31/01/2023 22:33, Jean Abou Samra wrote:
> > Uh, why did I just write this already? The latter wouldn't
> > be a problem. assign_event_once uses "equal?" The former,
> > with procedures, is indeed a problem.
> >
> > Sorry for the noise.
>
>
> Looking a bit more into define-markup-commands.scm, this
> will occur at least with
>
> \markup \score
> \markup \score-lines
> \markup \stencil
> \markup \on-the-fly
> \markup \with-string-transformer
> \markup \if
> \markup \unless
>
> e.g.
>
> <<
> \new Staff { \mark \markup A c' }
> \new Staff { \mark \markup A c' }
> >>
>
> vs.
>
> <<
> \new Staff { \mark \markup \score { c' } c' }
> \new Staff { \mark \markup \score { c' } c' }
> >>
>
>
> Also, allowing several text marks at the same moment
> is one of the root motivations for \textMark, so
> deduplicating based on markup equality would feel
> (IMHO) surprising.
>
>
>
Re: nested \relative ?
What is the reasoning behind having smaller relative blocks? Generally I
structure my variables as a single \relative block per variable and just
use \resetRelativeOctave at the beginning of every passage.
On Fri, Feb 10, 2023 at 3:09 AM Simon Albrecht
wrote:
> Hi Darren,
> On 10/02/2023 11:46, Darren Ng wrote:
>
> \ghostNoteWhichDoesNotActuallyAppear { c,,, }
>
> I think what you want here is \resetRelativeOctave.
>
> The best solution depends on many factors around your workflow and the
> setup of your project, but generally it is recommendable to split things up
> into smaller \relative {} blocks. It has taken me a long time to get better
> at this and actually do things like (silly example)
>
> someMusicVariable = {
> \relative { c'4. e8 g4 c | a c8 a g2 }
> R1*10
> \relative { f'4. g8 e4 c | d2 c }
> }
>
> HTH, Simon
>
Re: Staff switch over page break spoils vertical spacing
Jean, please don't apologize for the constraints on your time. You contribute so much to the project and the community. Your efforts are appreciated. On Sat, Jul 8, 2023 at 8:11 PM Jean Abou Samra wrote: > Le samedi 08 juillet 2023 à 17:44 +1000, Vaughan McAlley a écrit : > > When a staff-switch line goes over a page break, the first system in the > next page is stretched and may cover the next system. In the example here, > it nearly touches, but in a full score the top system is stretched beyond > the bottom of the page. > > In the wild, a system may stretch over the next system, like the attached > picture. > > > > That smells like https://gitlab.com/lilypond/lilypond/-/issues/6551 . > > Admittedly, I'm embarrassed about this bug since it is a regression that I > introduced. (Reverting the offending commit would be easy, but that commit > fixed a bug too.) I know what needs to be done since I investigated two > weeks ago, but unfortunately I likely won't have the time to actually > prepare the patch in the coming week, sorry. > > Working around it would not exactly be straightforward either; sorry about > that too. > > Best, > Jean > >
Re: LilyPond 2.25.6
Hooray! I can finally compile my whole symphony draft on Windows! Thanks devs for all the work that went into this. On Sat, Jun 24, 2023 at 6:42 AM Jonas Hahnfeld via LilyPond user discussion wrote: > We are happy to announce the release of LilyPond 2.25.6. This is termed > a development release, but these are usually reliable for testing new > features and recent bug fixes. However, if you require stability, we > recommend using version 2.24.1, the current stable release. > Please refer to the Installing section in the Learning Manual for > instructions how to set up the provided binaries: > https://lilypond.org/doc/v2.25/Documentation/learning/installing > > This release of LilyPond includes an updated version of the library for > garbage collection that should finally address some rare crashes seen > on Windows. If you have scores that were crashing with previous > versions, including the stable LilyPond 2.24.1, please give this > development version a try and report back the results. Unless problems > are reported, we are planning to backport this update and release it as > LilyPond 2.24.2, along with a number of other bug fixes. >
Harp_pedal_engraver: an overengineered solution to a niche problem
Hello friends,
I’ve found that one of the more cumbersome tasks in Lilypond is engraving
chromatic music for concert harp. When entering markups manually for each
pedal change, it’s difficult to achieve clean and consistent formatting,
and very easy to make errors. I’d like to share my solution to this problem.
The user only needs to enter pedal settings at the beginning of a passage,
which looks like:
<>\setHarpPedals { d c b e f g a }
Harp_pedal_engraver then listens for notes and automatically prints pedal
changes when new accidentals occur. Manually entered pedal changes (using
the same function as above) are only needed if a pedal must be changed
early. Warnings are triggered if contradictory accidentals are entered.
There is support for graphical pedal diagrams with and without circles, and
the format of text pedal charts can be customized.
The engraver creates two new grobs, HarpPedalChart and HarpPedalChange,
which will typically belong to the PianoStaff or GrandStaff. I extended
side-position-interface::move-to-extremal-staff to allow for placement of
grobs below the top staff if direction is set to CENTER. The style options
and default grob positioning are based on Elaine Gould’s book and examples
I’ve seen of harpists marking up their parts.
I’ve included in the file a fairly complete set of tests and examples.
I’d welcome feedback and I’d be happy to submit this as a pull request for
either OLL or Lilypond itself if there is interest.
Some technical comments:
1. I’ve duplicated with minor changes several functions from
chord-name.scm. IMO note-name->string should be changed to accept an
integer instead of ly:pitch, to be consistent with
accidental->text-accidental-markup. I’ve also duplicated note-name->markup,
because the original implementation doesn’t allow for printing naturals,
and also because for some reason it inserts a space between the note name
and the flat sign, which IMO is quite ugly (this is a general issue I see
on both Mac and Windows when entering flat signs in markups, not just with
that function).
2. I haven’t tested localization to other language note names.
3. I would love to provide a cleaner interface for users to customize the
formatting of text pedal markings or add enclosures around graphical pedal
diagrams. For example, it would be nice to let users do something like
\override HarpPedalChart.enclosure = \markup\box\etc instead of having to
create a whole Scheme function accepting the grob as an argument. It would
also be nice to have the user be able to simply write something like
\override HarpPedalChart.format-pedal-text = #my-custom-format instead of
#(const my-custom-format). (Naturally, this relates to which logic and
properties belong to the engraver vs. the grobs – I think my choices were
sensible, but perhaps there is a better design?)
4. Right now, overrides only work with the context name specified. I’d love
to know how to make these work with just the grob name.
5. It would be nice to have the engraver ignore notes created by
\cueDuring, but as far as I can tell, these notes are indistinguishable
from ordinary notes by translation time. To workaround this, it’s necessary
to turn automatic pedal changes off during cues. Not a big deal but
slightly ugly.
6. The grob definitions are based on TextScript but I removed properties
that didn’t seem to do anything in my test examples. I have no idea if they
should be added back in or values adjusted to deal with situations my tests
didn’t cover.
harp-pedal-engraver.ily
Description: Binary data
