On Mon, Mar 16, 2026 at 1:17 AM Simon Albrecht <[email protected]>
wrote:
> On 15/03/2026 18:13, Luca Fascione wrote:
> > could one make a function in
> > scheme that splits on | and transforms my input into your example then?
>
> unless your \parallelMusicExtended function
> took a string as its second argument and preprocessed that string before
> handing it to the LilyPond parser as LilyPond syntax (using one of the
> ly:parser… scheme functions, been ages since I used them).
Yes, that's what I meant indeed
> But then this long string would be extremely unwieldy as input, so I
> can’t imagine
> that being worth it.
>
I don't follow, why isn't it identical to what parallelMusic takes today?
What am I missing here?
> Another very quick stab at explaining: In the “pseudo-code” you sent,
> the parser would already interpret the whole second argument to the
> \parallelMusicExtended function using notemode before the music function
> ever got to manipulate it.
I thought if it was a scheme function taking a string this wouldn't happen,
per your comment above, otherwise how does unquoted text for lyrics work?
> For me, in situations like that (where I’m tempted to write some sort of
> function to simplify LilyPond code), I usually end up choosing the
> slightly more “wordy”, but standard, input syntax and think about how to
> make the inputting itself easier.
I am confused by what you're saying. In my head this is like TeX: if a macro
can do it, it counts as being "standard" (this is how you get LaTeX,
obviously).
However, see below about Eric Benson's thing
> Depending on your setup, the tools you
> use for typing and coding, and other personal preference it could mean
> simple copy & paste, search & replace, or more advanced stuff with
> regex, macro programming etc.
>
To my eyes a file that looks like this file
----
\include "include/leadhseets_head.ly"
\parallelMusicExtended #'((chordmode . chords) voiceA (lyricmode .
lyricsOne) (lyricmode . lyricsTwo)) {
c2. |
c2 e8 c |
ma -- zing __ _ |
grace that __ _ |
}
\include "include/leadsheets_tail.ly"
----
looks cleaner than something that needs to go through python
using a makefile (say) to get to a pdf.
I have looked to how available databases of jazz leadhseets are done
at the moment, I was able to find two: one by Mark Veltzer and one by
Eric Benson/neonscribe. I seem to recall someone on this list suggested a
third one
but I couldn't find that message nor the database itself.
Veltzer's thing is based on a python preprocessing step that takes files in
a
custom format and emits lilypond source, while Benson's method is much more
lilypond centric, but I find the extensive use of "configuration"/"styling"
macros
difficult to work with (he's given new names and interfaces to most basic
functionality
in order to abstract it away and make it configurable, but the result is
that the input
doesn't look like lilypond anymore, I guess like LaTeX doesn't look like
plain TeX).
So it seems to me at the moment my options are:
A- emit classic lilypond (melody = { a b c } then chord = \chordmode { ...
} then lyricsA = \lyricmode { ... } )
B- use an external format and then a preprocessor to make lilypond out of
it (Veltzer's method)
C- make myself some lilypond macros so that I get a file that looks like
something I can keep straight in my head
but it's still clean lilypond input, and achieve this with a modicum
of scheme programming
I prefer C, but my aim is an input form that has high locality of
reference:
things close to each other in the PDF I want to be close to
each other in the input (with is what parallelMusic achieves).
Thanks Simon, appreciate you spending the time
to work through this
L
--
Luca Fascione
