Re: Key signatures in MIDI output

[mskala]

On Sat, 11 May 2024, Giles Boardman wrote:

> I have now been more systematic in my approach and conclude that \key is not
> reflected in MIDI output. I tried various positions for events and in each

Well, it definitely is reflected in the output in my own tests.  The
example code I posted, when run through Lilypond 2.24.1, produces a MIDI
file containing key change events.  There may be some relevant
distinctions in terms of which version of Lilypond you're running and
exactly where you put the \key commands in the input.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: Key signatures in MIDI output

[mskala]

On Sat, 11 May 2024, Giles Boardman wrote:

> When I create MIDI output from Lilypond, if I have imported a MIDI file and
> then resaved it with changes made in LilyPond, the output is like that, too.

Lilypond as such does not import MIDI files.  I think you must be using
some piece of software other than Lilypond, and that is relevant to the
issues you're experiencing.

On the off chance that you might be using midi2ly, I tried round-tripping
my example code through that, and got suggestive results.

I take this code:

\score {
\new Voice {
  \key c \major
  c'4 d'4 e'4 f'4 |
  \key d \minor
  bes4 a4 g4 f4 |
}
\layout { }
\midi { }
}

and run it through Lilypond to get a MIDI file.  Then I take the resulting
MIDI file, which contains key changes at the marked locations, and run it
through midi2ly.  The result is a complicated mess, 74 lines long.  If I
run *that*, the midi2ly output, through Lilypond a second time to get a
PDF file, then the PDF file shows a D-minor key signature at the start of
each of the two bars, no C-major at all.

That seems like it could be relevant to the complaint of Lilypond losing
key changes.  It seems to come about because the control track in the MIDI
file translates into a silent voice in the midi2ly output, and that voice
has a D-minor key signature at the start which overrides the C-major key
signature in the other voice.  But it's an issue on *input*, in that
midi2csv is creating an unusual file structure, nothing to do with MIDI
output or the Lilypond program itself.

I think it's important to understand that Lilypond is not a MIDI file
editor.  MIDI files in Lilypond are treated as final output (much like PDF
files), not as an editable format.

To start with a MIDI file, "import" it with midi2ly, edit the resulting
Lilypond code, and then "resave" it with Lilypond, is not the usual
workflow and is likely to cause problems even if there is some technical
possibility of doing it.  "Importing" and "resaving" are not ordinarily
done with Lilypond.  The intended use of Lilypond is in a one-way flow
from ideas to *.ly source code to PDF or MIDI output, and the midi2ly
utility which creates an exception to that flow is intended only to be
used once, to produce a file parts of which can be cut and pasted into a
new Lilypond source file.  Repeated round-trips between MIDI and Lilypond
source format are asking for trouble.

Of course, you may not actually be using midi2ly at all, in which case the
above is irrelevant.  I'm only guessing based on your description of
"importing" a MIDI file, which stands out as an unusual (indeed,
impossible) thing to do with the main Lilypond program.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: Key signatures in MIDI output

[mskala]

On Fri, 10 May 2024, Hans Åberg wrote:

> > signature.  The MIDI file does not contain that information; it is up to
> > whatever software reads the MIDI file, to display it appropriately.
>
> So to go back to staff notation from MIDI, one must know what enharmonic
> equivalences that have been applied.

Yes - and it's not Lilypond that does that step, so if the translation
back to staff notation is not as desired, there's little that can be done
within Lilypond to fix it.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: Key signatures in MIDI output

[mskala]

On Fri, 10 May 2024, Hans Åberg wrote:

> Programs like ABC work so that one writes the music without accidentals,
> and then apply a key signature to get them. It was my reading that the
> OP asked for that.

Okay.  I didn't read it that way because the OP said he was getting
correct output in the PDF, and if he'd misunderstood the input format in
the way you describe, then the PDF would be wrong too.

But something else that occurred to me is that there may be a further
misunderstanding of MIDI format in play here:  MIDI never contains
"accidentals" at all.  It only contains note numbers.  In my example code:

\score {
  \new Voice {
\key c \major
c'4 d'4 e'4 f'4 |
\key d \minor
bes4 a4 g4 f4 |
  }
  \layout { }
  \midi { }
}

The MIDI output will contain roughly this information:

key change, C major
note 60
note 62
note 64
note 65
key change, D minor
note 58
note 57
note 55
note 53

If some other software, reading the MIDI file, displays these as notes
with or without accidentals, and does or doesn't make the key-change
events visible, then that has very little to do with Lilypond, which only
generates the above data.  Note 60, for instance, might be a C or a
B-sharp.  Even if it is B-sharp, it might be displayed with or without a
sharp sign depending on whether there is one in the displayed key
signature.  The MIDI file does not contain that information; it is up to
whatever software reads the MIDI file, to display it appropriately.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: Key signatures in MIDI output

[mskala]

On Fri, 10 May 2024, Hans Åberg wrote:

> To change the MIDI output, you will need to change the notes, say by
> transposing or something else.

MIDI files can include events ("key-change meta messages") for key
signatures, each specifying a root and whether it's major or minor (which
actually makes them more expressive than standard notation which can't
distinguish, for instance, between C major and A minor).  Lilypond
generates these events in the MIDI files on each key change in my
installation.  If Giles's installation appears not to, I wonder whether
that may be due to an issue with the software he's using to examine the
MIDI files.

For instance, this input produces a MIDI file with key-change events at
the indicated places:

\score {
  \new Voice {
\key c \major
c'4 d'4 e'4 f'4 |
\key d \minor
bes4 a4 g4 f4 |
  }
  \layout { }
  \midi { }
}

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: Is there a more complete predefined-guitar-fretboards.ly?

[mskala]

On Mon, 29 Apr 2024, Kevin Cole wrote:

> "predefined-guitar-ninth-fretboards.ly" get the job done. But on a few
> occasions I've had to resort to studying some online tutorial and
> constructing the diagrams from scratch.

Not a complete solution, but my chord database at
   https://files.northcoastsynthesis.com/chords/C

already exposes the Lilypond code for each fretboard diagram in an HTML
comment.  In Firefox, if you right-click and choose "inspect" on a
diagram, then "Edit as HTML" on the enclosing "fretboard-item" div, you
can find the \fret-diagram command and copy out the code for use in your
own Lilypond document.  Most other browsers should be able to do something
similar.  If this is a feature people want and will use, then I can try to
add something to make the source code more visible, most likely a
"lilypond" button to make it visible and copyable without using the
browser's source-viewing tools.

Automatically generating a file of preferred fretboard diagrams for many
chords wouldn't be easy because I don't have a strong sense of which ones
are easiest or preferable to play; I'm not really a guitarist myself.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: subscript in lyrics

[mskala]

On Sat, 20 Apr 2024, David Olson wrote:

> I'm a lyric poet writing songs about science.
>
> "CO2" is three syllables and often works better than "carbon dioxide".
>
> It's acceptable even if "2" doesn't appear as a subscript (one sees this
> usage frequently), but subscript would be cool. 
>
> A superscript option would be cool too.

Easy enough to do using \markup and \sub, as in:

<<
  \new Voice = melody { c'2 c'2 | c'4 bes4 f'2 | }
  \new Lyrics \lyricsto melody { \lyricmode {
"ooh!" "ooh!" C O \markup { \sub { "2" } "!" }
  } }
>>

There are a number of variations possible:  \super for superscript,
\normal-size-sub for subscript without making the font smaller (which
might be easier to read even if it's not standard chemistry usage), and so
on.  In general, you can just break into \markup and use any of the usual
markup commands.  See "Formatting text" in the Notation manual:
   https://lilypond.org/doc/v2.24/Documentation/notation/formatting-text

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: Time measurement

[mskala]

On Thu, 14 Mar 2024, Jean Abou Samra wrote:

> > “This sounds like a job for… Custom Engraver!!”  :)
>
> #(define (Custom_engraver!! context)
>(define (format-time seconds)

Thanks!  I haven't tested this extensively, but so far it looks like it
works well.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Time measurement

[mskala]

Is there any easy way to find out the time in seconds from the start of a
score to a specified point, corresponding to the timing of the MIDI
output?  I can count measures and do math on the tempo, but that's
less than ideal in the face of multiple tempo changes.  Another idea would
be to just cut the score at the desire point and then measure the length
of the MIDI output file.  I can already manually examine the MIDI output,
find the desired point in the music, and record its timing, but that's
a fair bit of work.

I only really need to do this for a few points, a few times, and I just
want to know the numbers, not necessarily typeset them.  But a more
automated method along the lines of a \midiTime markup that would actually
typeset the time to that point automatically, would be fun too.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: { } not sounding right.

[mskala]

On Fri, 19 Jan 2024, Werner LEMBERG wrote:

> This is a limitation of MIDI: You can only have a single pitch bend
> per time step per channel.  LilyPond's rather primitive MIDI 1.0
> output provides no means to circumvent this limitation.

I've sometimes gotten good use out of LilyPond code from others on the
list, that splits chords into separate voices so that I can then put them
in separate MIDI channels, both to allow separate pitch bend for
microtonal pitch and to allow recording on a monophonic synthesizer.  A
couple of threads about it:

   https://lists.gnu.org/archive/html/lilypond-user/2015-09/msg00394.html
   https://lists.gnu.org/archive/html/lilypond-user/2023-05/msg00274.html

It's advisable to read the entire threads, because there are multiple
solutions proposed and errors corrected, with varying advantages and
disadvantages.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: Grandstaff multi-bar rest count shared between staves

[mskala]

On Wed, 17 Jan 2024, Martin Brown wrote:

> To answer my own question, I've fudged this with:
>     \omit MultiMeasureRestNumber at the start of the bass line
>     \override MultiMeasureRestNumber.Y-offset = -5 at the start of the
> treble line
> but that seems a bit fragile. Eg. if the staves need to be separated more.
> Any other solutions?

Although still not a perfect solution, you may be able to make it less
fragile by putting a Dynamics context between the two staves, adding the
multi-measure rest engraver to that, and then hiding the actual rests
there, to only show the numbers.  I still have to add an offset adjustment
to make this look decent, but I think the offset adjustment shouldn't
change with the height of the things in the staves.  The height of other
things in the Dynamics context, if any, will be less variable.

There are probably more elegant ways to do the overriding, such as
defining a new context just for this purpose instead of modifying
"Dynamics."  But this is what I got from a quick experiment.

\new PianoStaff <<
  \new Staff {
\omit MultiMeasureRestNumber
\clef treble
\compressMMRests { 1 | R1*10 | 1 | }
  }
  \new Dynamics {
\hide MultiMeasureRest
\override MultiMeasureRestNumber.Y-offset = -1
\compressMMRests { s1 | R1*10 | s1 | }
  }
  \new Staff {
\omit MultiMeasureRestNumber
\clef bass
\compressMMRests { g1 | R1*10 | g1 | }
  }
>>

\layout {
  \context { \Dynamics \consists Multi_measure_rest_engraver }
}


-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: Transpose from major to minor key

[mskala]

On Thu, 11 Jan 2024, Wol wrote:

> You need to remember lilypond thinks in terms of pitch, not note names. Unlike
> some (most?) other music software. So "\transpose g e" says "transpose EVERY
> note up A TONE".

I'm not sure it's quite right to say that Lilypond thinks in terms of
pitch, not note names, because it selects the spelling of transposed notes
based on the note names.  For instance, \transpose c cis fis gives fisis ,
not g , whereas \transpose b, c fis gives g.  The one-semitone
transposition of the same note is different depending on the note names
used to specify it.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: zero-duration s to hold marks

[mskala]

On Wed, 10 Jan 2024, Raphael Mankin wrote:

> That strikes me as being a programmer's response, and I speak as a programmer
> for over 50 years. Using <> works, but it is unintuitive. If s0 is more
> intuitive then that should be considered for future inclusion.

It's intuitive to me that s0 means a spacer rest of infinite duration,
because it's one whole note divided by zero.  And it opens the door
to using 0 as a duration denominator for other things than "s", as in "c0"
and "0", let alone constructions like "s0." which would seem to be
a spacer of one and one half times infinite duration.  I don't think it's
a good idea to open those doors.  There doesn't seem to be any way to
allow zero as the duration denominator except as a unique exception; it
cannot be done in a way that's consistent with other syntax.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: Output PDF to stdout

[mskala]

On Fri, 5 Jan 2024, Dr. Arne Babenhauserheide wrote:

> > intermediate "files" will be written to and read from the buffer cache at
> > RAM speed and only later go to the disk in the background.
>
> That depends on the file system and its synchronization model. I once
> sped up a script to control a cluster by more than factor 10 by avoiding
> intermediate writes to the shared network filesystem of the cluster
> nodes. That made the difference between 15 minutes and 30 seconds
> runtime.

I'm sure you're already aware of the important differences between that
and the situation described in this thread.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: Output PDF to stdout

[mskala]

On Thu, 4 Jan 2024, Volodymyr Prokopyuk wrote:

> My motivation behind using lilypond in a pipeline is to speed up PDF
> generation by avoiding storing intermediary files on disk. The pipeline I'd

Is that issue real?  In Linux and most other operating systems,
intermediate "files" will be written to and read from the buffer cache at
RAM speed and only later go to the disk in the background.  The subsequent
process that uses the file won't be waiting for the disk I/O to complete.
Even if a pipe might theoretically be even faster than the buffer cache,
the intermediate unoptimized PDF is unlikely to be the bottleneck step in
generation of an optimized PDF.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: Is there a property that would set all of the "above staff" text to "above chordnames"

[mskala]

On Mon, 1 Jan 2024, Kevin Cole wrote:

> What I mean is, I often have a situation where there's only a wee bit
> o' text occasionally, above the staff. But I frequently have
> ChordNames. It seems to me that the ChordNames would be better placed
> below the occasional text, and I was hoping that, rather than manually

You can't really put the text in a Staff and have ChordNames appear
between the text and the staff, because ChordNames is a context kind of
like a staff in itself.  Trying to position it in the middle of a Staff
context is a recipe for annoyance.  But if you're willing to define the
text separately, you could create a Dynamics context and put your text
there to get a similar visual effect.  The nonstaff-nonstaff padding
override can be varied to taste; without it, the text collides with the
top of the ChordNames in an unsightly way.

global = {
  \time 4/4
  \key c \major
}

textMarkups = {
  s1^\markup \bold "CHORUS" |
  s1 |
  s1 |
  s1 |
}

chordNames = \chordmode {
  \global
  f2 d2:m | c4 s4 c8 g8:7 c4 | g4 c4 f4 c4 | g4 s4 g2:7|
}

melody = \relative c'' {
  \global
  \clef treble
  a2 f2 |
  g4 g4 g8[ f8] e4 |
  d4. e8 f4 e4 |
  d4 b4 g2 |
}

\score {
  <<
\new Dynamics \with {
  \override VerticalAxisGroup.nonstaff-nonstaff-spacing.padding = #1
} { \textMarkups }
\new ChordNames \chordNames
\new Voice = "mel" { \melody }
  >>
}

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: Hide chords

[mskala]

On Tue, 5 Dec 2023, Jan wrote:

> What is the recommended method to “hide” chord names for a couple of 
> measures? For example, in the snipped below I’d like to hide the chords for 
> measures 5 to 8.

Depending on exactly how you're generating the chord names in the first
place, it may be easy to use spacer rests, as in:

\new ChordNames { \chordmode { c1 | a1:m | s1 | g1 | } }

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: Articulate has trouble with grace note at time signature change

[mskala]

On Wed, 22 Nov 2023, Werner LEMBERG wrote:

> Please check the looong list of bugs related to `\articulate` whether
> it has already been reported.

Seems to be #3696, reported - by you - in 2013.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Articulate has trouble with grace note at time signature change

[mskala]

This fails in 2.24.1 with messages about mid-measure time signature
change and failed barcheck:

\include "articulate.ly"
\articulate
{
  \time 4/4
  c'1 |
  \time 3/2
  \grace d'8 c'1. |
}

Succeeds if \articulate is not used.  I can work around it by tagging MIDI
and non-MIDI versions of the music, with the time signature change moved
somewhere else in the MIDI version, but this becomes complicated given
that my actual score has eight parallel variables at the point where it
bites, all of which will need alternate versions.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: Still failing to operate lilypond 2.20.0 64-bit version.

[mskala]

On Fri, 6 Oct 2023, Werner LEMBERG wrote:

> Thanks.  I think it's ghostscript – there are no pre-built packages
> available either.  While LilyPond doesn't link to it in normal builds,
> gs is needed for converting LilyPond's EPS output files to PDF.  In
> other words, a MacPorts user still needs a compiler...

If LilyPond doesn't link to gs but only execs it, then gs having an
incompatible version of GPL from LilyPond's version should not render
either binary undistributable, even together.  GNU's position seems to be
that exec is a boundary across which it's not necessary for licenses to be
compatible.  Of course, whether MacPorts's automated determination of
distributability can capture this distinction, is another question.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: Merging dynamics with music

[mskala]

On Sat, 16 Sep 2023, Knute Snortum wrote:

> Try moving the Dynamic performer to the Staff level. 

Cutting and pasting this code produces two pages of error messages because
it's full of "non-breaking space" characters which LilyPond can't process,
but I was able to get the desired results by re-typing it.  Thanks for
your help.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: Merging dynamics with music

[mskala]

On Sat, 16 Sep 2023, David Kastrup wrote:
> > With the following code, the notes in the MIDI file still are both at
> > default velocity.  Explicitly instantiating the Staff does make a
> > difference in the visual output.
> >
> > MyMusic = { c'1 c'1 }
> > MyDynamics = { s1\ppp s1\fff }
> >
> > \score {
> >   \new Staff << \MyMusic \MyDynamics >>
> >   \layout { }
> >   \midi { }
> > }
>
> My mistake: Dynamic_performer by default lives at Voice level, so you'd
> need \new Voice here in order to issue the dynamics on a level visible
> to MIDI.

Thank you.  That works for the given example.  However, with more
complicated music that already contains multiple voices (as is typical of
the piano music where a between-staff Dynamics context would be used in
the first place), it doesn't work.  For example:

MyMusic = { << { c'1 c'1 } \\ { e'1 e'1 } >> }
MyDynamics = { s1\ppp s1\fff }

\score {
  \new Voice << \MyMusic \MyDynamics >>
  \layout { }
  \midi { }
}

With that code all the notes end up at default velocity.

You mention that Dynamic_performer "lives at Voice level" by default.  Is
this a default I can override, and would that help?

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: Merging dynamics with music

[mskala]

On Sat, 16 Sep 2023, David Kastrup wrote:

> Try
>
> \new Staff << \MyMusic \MyDynamics >>
>
> since otherwise the variables will end up in separate Staff contexts.

With the following code, the notes in the MIDI file still are both at
default velocity.  Explicitly instantiating the Staff does make a
difference in the visual output.

MyMusic = { c'1 c'1 }
MyDynamics = { s1\ppp s1\fff }

\score {
  \new Staff << \MyMusic \MyDynamics >>
  \layout { }
  \midi { }
}


-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Merging dynamics with music

[mskala]

I'm trying to use a Dynamics context to put dynamics between the staves of
a PianoStaff.  As such, I've got my notes and my dynamics in two separate
variables.  For MIDI output, I'd like to merge the contents of the music
variable and the dynamics variable and generate MIDI from the result.
But I can't find a way to merge the two variables and have the dynamics
really affect the MIDI velocity of the notes.

Here's some code I've tried; I've also tried many much more complicated
variations.  Note that although the Dynamics context is part of the
motivation for this question, the question is about merging music
variables and the problem shows up even without the existence of a
Dynamics context.

MyMusic = { c'1 c'1 }
MyDynamics = { s1\ppp s1\fff }

\score {
  << \MyMusic \MyDynamics >>
  \layout { }
  \midi { }
}

After compiling that, I get a MIDI file in which the notes are just at the
default velocity without any dynamics being applied.

This code seems to be parallel to examples I've seen online of templates
for use of the Dynamics context, and I've seen examples both on this list
and elsewhere of people doing what seems to be exactly the same thing I'm
doing, with << >> for combining the variables to generate MIDI output; but
I haven't found any example of merging dynamics with notes that actually
works with MIDI when I compile it myself.  I wonder if something may have
changed in a recent version of LilyPond such that older examples no longer
work.

I've also tried << { } \\ { } >>, partCombine, several different
arrangements of explicitly instantiated Voices or Staffs, and so on.
Although I can get the visual output to look good, nothing seems to work
for applying the dynamics from one variable to the notes from another in a
way that will really appear in MIDI output.

What is the correct way to merge the variables in this situation?

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: Doubling a note makes MIDI output louder

[mskala]

On Sun, 9 Jul 2023, Knute Snortum wrote:

> note out of the other hand.  This is why I suggested that the MIDI performer
> could ignore \parenthesize notes.  Would this create a pile of workarounds
> for you?

Not as long as I don't use \parenthesize.  But I think it's preferable not
to have a presentation command ("print this in parentheses") with
non-obvious semantic consequences ("don't include these notes in MIDI
output").  Parentheses can mean many different things in different pieces
of music; your situation is only one of those.  Making remove-from-MIDI
always the behaviour of parentheses, or the default unless overridden,
would create Surprises! for anyone who tries to use parentheses for some
other purpose and expects them to just be marks on the page.

Better for "don't include this in MIDI" to be a separate command instead
of a side effect of parentheses.  Less good, but pragmatic because it
doesn't require changing LilyPond, would be to use "tagging" to exclude
the unwanted notes from the version of the music used to generate MIDI.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: Doubling a note makes MIDI output louder

[mskala]

On Sun, 9 Jul 2023, David Wright wrote:

> players. But that's the problem here. When two real voices happen on
> the same note, the result doesn't sound like one louder voice, yet
> that's the effect you get from MIDI,¹ where the "two" voices are

Not on *my* MIDI synthesizer.  Two notes are two notes!  I'm inclined to
be concerned by this because I do a lot of doubling of notes between
different MIDI channels.  Each channel plays on a different patch, or in a
separate monophonic recording run on the same patch, and a doubled note is
quite different from a louder note.

If LilyPond were to start automatically deleting notes because someone
think's it's a bug for unisons to exist between MIDI tracks, it would make
the pile of workarounds I already need to use to get decent MIDI out of
LilyPond, that much worse.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: Doubling a note makes MIDI output louder

[mskala]

On Sun, 9 Jul 2023, Knute Snortum wrote:

> In the MWE the instrument is a piano, so you wouldn't want the note to sound
> louder than the surrounding notes, because the doubled note is played by
> only one hand.  But I can see this might be a problem if the two staves were
> for two voices.  Maybe you want it louder in that situation?  That's why I

LilyPond generates separate MIDI tracks, in separate channels, for the two
staves, so as far as anything playing the MIDI file is concerned, it is
not a "louder" note; it is two notes in unison.  Nothing about a standard
MIDI file indicates to the playing software that these two tracks happen
to be the right and left hands on a single instrument.

If you don't want the two notes to play at once, I think what needs to be
changed is the fact that LilyPond is generating separate tracks per stave.
You might be able to use \partcombine to collapse them into a single
track and eliminate unisons.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: Doubling a note makes MIDI output louder

[mskala]

On Sun, 9 Jul 2023, Knute Snortum wrote:

> I'm not sure exactly how one would deal with this problem, other than with
> tags.  Maybe \parenthesize could not produce MIDI output?  Or is there a way

Is that a problem?  If these are two notes in different MIDI channels,
then the MIDI output is just reflecting what you wrote - two notes played
at once that happen to be the same pitch - and deleting one would be
incorrect.  If the MIDI output is really just a single "louder" note (what
does that mean - higher velocity?) then it implies some deliberate
detection of this case within LilyPond, which might reasonably be
adjustable.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: chord.ly to extract notes from chords breaks with new Guile

[mskala]

On Wed, 31 May 2023, Gilles Thibault wrote:

> Not hardly tested but this should work :

Thanks for looking at it further.  I hate to impose on you because I've
already decided to solve this problem in external postprocessing of the
MIDI files, so I hope you won't put a lot of effort into trying to satisfy
my use case with modifications to your script.  I don't think doing it in
Lilypond is really the right solution for me because to really solve it I
need to automatically handle *all* cases of simultaneous notes.  I need,
at each point in time, to have at most one note per track, exactly one
track per note, and silence in any leftover tracks, regardless of the
voice/chord structure of the music.

The code you provide works for the specific example I gave, where the
desired silence comes from a note written as a single note instead of a
chord, but there are many other cases (illustrating the problem with
minimal examples).  In particular:

* change b2 to 2 and the b2 comes out in two tracks.  Maybe it would
  never occur to me to write a one-note chord, but a similar issue can
  happen between two- and three-note chords, or anywhere the number of
  notes per chord in a voice is not always the same.

* a one-voice passage added outside the << >> construct comes out in two
  tracks

* if each of two voices sometimes contains two simultaneous notes, but
  only at most three notes are simultaneous overall, then I need to either
  use four output tracks, or carefully split and then merge to bring it
  down to three, and handling this kind of thing becomes steadily more
  complicated as the number of voices and simultaneous notes grows.

Resolving these points and any other similar ones that may come up, seems
like a lot of work.  If an in-Lilypond solution means I need to do things
like maintain the same number of Voice contexts throughout the entire
piece of music, or think hard about which note/voice index needs to merge
with which other one to minimize the overall number of tracks without ever
having more than one note simultaneous in a track, then we quickly
approach a point where it would be less work for me to just write out the
intended output by hand and not have Lilypond calculate it at all.

In external MIDI processing it's relatively easy:  at every "Note on"
message in chronological order, I can route the note to an unused track or
else know unambiguously that I need more tracks.  At every "Note off," the
track in question becomes available again.  The external code basically
does the same thing that a polyphonic synthesizer would do, just with
output to new MIDI tracks instead of directly to hardware voices.  No need
for separate handling of Lilypond's "single note," "chord," and "voice"
concepts.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: chord.ly to extract notes from chords breaks with new Guile

[mskala]

On Mon, 29 May 2023, Gilles Thibault wrote:

> chord.ly has been renamed to chordsAndVoices.ly (it deals also now with
> Voices)
> You can donwload it here :

Thanks a lot!

As far as I know, the new version works fine.  The problem in the old
version was just because of the non-breaking spaces in the lines I
modified according to instructions from the mailing list.  That was a
problem I encountered back in 2015 too, and thought I had fixed then.  My
version of the file is unmodified since 2015; evidently some non-breaking
spaces survived the earlier fix, and earlier versions of Lilypond ignored
them.  I don't know why the latest version had a problem with these
characters given that earlier versions didn't, but I also don't know why
earlier versions *didn't* have a problem with these particular
non-breaking spaces when others in the same file caused a lot of trouble.

I will say again, as I said in 2015, that I wish people would stop trying
to use HTML for email.  That's where the non-breaking spaces came from.

Anyway, even the old version of chord.ly contained support for separating
voices, which I hadn't previously touched but I investigated just recently
in the hope of separating MIDI notes that don't have identical timing.

That is, if my input is
   << { a1 } \\ { b2 2 } >>

it would be nice to be able to separate it out into three separate outputs
for separate MIDI channels, like:
  { a1 }
  { b2 c2 }
  { r2 d2 }

Unfortunately, both the old chord.ly and new chordsAndVoices.ly code have
the same problem with respect to voices that I encountered in 2015 with
respect to notes within a chord:  requesting a non-existent voice index
returns the last voice instead of silence.  That seems to be the intended
behaviour of the code in your application, so it's not exactly a bug, but
it isn't what I need.

I think the really right answer for me is to not use Lilypond to do this
note-separation at all, but to do postprocessing with other tools on the
MIDI files generated by Lilypond instead.  I'm more confident of really
getting correct results from that in all the different cases of
simultaneous notes, than I would be by trying to do the separation inside
Lilypond.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: chord.ly to extract notes from chords breaks with new Guile

[mskala]

On Sat, 27 May 2023, David Kastrup wrote:

> which contains a delirious number of unbreakable spaces, code \xa0
> instead of \x20 as for a normal, breakable space.

Thanks!  Correcting these seems to have fixed the problem, at least for
the moment.

I don't know why the old version needed *some* of the non-breaking spaces
to be changed to regular spaces and did not require this of *all* of them,
nor why the new version would be different.  But that's not important.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: chord.ly to extract notes from chords breaks with new Guile

[mskala]

On Sat, 27 May 2023, Jean Abou Samra wrote:

> Are you sure that this is the correct example? That the file chord.ly it
> uses is the same as the one you sent? That LilyPond is the one you believe
> and unpatched, etc. ?

Yes, using the chord.ly file I attached to my message, extracted from the
message as it came back through the mailing list, with the three-line
input cut and pasted from my message as it came back through the mailing
list, and the version of Lilypond I compiled from the sources in the file
lilypond-2.24.1.tar.gz downloaded from the lilypond.org Web site, I get
these messages:

GNU LilyPond 2.24.1 (running Guile 2.2)
Processing `test.ly'
Parsing...ERROR: In procedure %resolve-variable:
Unbound variable: #{ }#

> I can't reproduce your problem (on Fedora); it compiles fine for me and
> prints a single MM rest.

Interesting.  What's the provenance of your Lilypond executable - did you
also compile from source, or use a Fedora package?

I wonder if the issue could be with my Guile 2.2 installation, which I
also compiled from sources.  I'm using Slackware, which does not have a
Guile 2.2 package, having skipped all the way to version 3.  I had to
install Guile 2.2 over top of that in order to get a version of Lilypond
that would report itself as using Guile 2.2, but if the build was still
partly using Slackware's packaged Guile 3.0 somehow, that could explain
the difference in our results.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

chord.ly to extract notes from chords breaks with new Guile

[mskala]

Back in 2015 people on the list helped me with extracting notes from
chords, in this thread:
   https://lists.gnu.org/archive/html/lilypond-user/2015-09/msg00394.html

The solution from 2015 has broken now, in the transition between versions
2.21.0 and 2.24.1.  I think it's because of changes in Guile 2.2.  I
haven't had the opportunity to test with versions strictly between 2.21.0
and 2.24.1.

My situation is that I have music containing chords which I want to play
on a monophonic synthesizer, by generating separate MIDI tracks such that
in each track there is only one note playing at a time.  After recording
the tracks separately I'll mix the audio files.  So I'd like to have a
function I can call that takes in music with multi-note chords and selects
just one note from each chord.  Making it a little more complicated, the
number of notes in the chords varies, including some single notes that
Lilypond may represent internally as different from "chords."  I need to
generate as many tracks as the maximum number of notes that will play
simultaneously, but have silence in the extra tracks at times when there
are fewer notes playing than there are tracks.

So, for instance, if my input looks like
  { c4 4 4 }

then I want to generate tracks that might look like
  { c4 c4 c4 }
  { r4 e4 e4 }
  { r4 r4 g4 }

It's not important which tracks get which notes and which tracks get
silence; all that matters is that the union of the output tracks should be
the same notes that were in the input, with silence assigned to
unused tracks.  It would be nice if it could handle more complicated
structures of overlapping notes like
  << { c2 } { d4 e4 } >>

but the solution I've been using since 2015 doesn't, there are some
foreseeable problems with doing that in the general case, and it's not my
main concern right now.  The main issue is that I want my existing files
that work to continue working in more recent Lilypond.

This is a near-dealbreaker for me using a more recent Lilypond at all - I
could and might fix it by just sticking to 2.21.0 indefinitely - but I'd
really like to also be able to override midiDrumPitches, which seems to be
new in some version more recent than 2.21.

Here's a small example showing the problem:

\include "chord.ly"
music = { 1 }
{ \extractNote #3 \music }

In version 2.21.0 that produces a whole-note rest.  In version 2.24.1 with
Guile 2.2 it gives this error output:

GNU LilyPond 2.24.1 (running Guile 2.2)
Processing `test.ly'
Parsing...ERROR: In procedure %resolve-variable:
Unbound variable: #{ }#

Lilypond 2.24.1 compiled with Guile 3.0.9 also gives this error.

I attach the version of chord.ly I'm using, which I got from the 2015
discussion.  I found these links helpful at that time and I think one of
them contained the original for this version of chord.ly:
  http://gillesth.free.fr/Lilypond/chord/
  http://www.lilypondforum.de/index.php?topic=2080.msg11479#msg11479

but those links are both dead now, making it difficult for me to figure
out exactly which changes I applied to get it to work in 2015.  The
version currently in LSR snippet number 545 does not give the unbound
variable error, but it is dated earlier, and it has the problem for which
I started the 2015 thread:  on an out-of-range index it just returns the
last note (d in my example) instead of returning silence.

The present error output seems to be specific to the case of extracting a
note that doesn't exist, such as the third note of a two-note chord in my
example.  It works without error if I only ask for notes that exist.
However, I can't really avoid giving an out-of-range index; being able to
do that and get silence is a big part of the point of the exercise.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/%% version Y/M/D = 2015/03/23
%% LSR = http://lsr.di.unimi.it/LSR/Item?u=1=761
%% LSR = http://lsr.di.unimi.it/LSR/Item?u=1=545
%% for Lilypond 2.16 or higher.
%% last major change in extract-note function : as \tuplet as now
%% a 'duration property, we have to deal with this special case.
%% by chord->note. You can now specified several numbers, to
%% extract several notes at one time

#(define (noteEvent? music)
(eq? (ly:music-property music 'name) 'NoteEvent))

#(define (no-duration? music)
(not (ly:duration? (ly:music-property music 'duration

#(define (expand-q-chords music); for q chords : see chord-repetition-init.ly
(expand-repeat-chords! (list 'rhythmic-event) music))

%%  extractNote  %
#(define tagNotExtractNote (gensym))
#(use-modules (ice-9 receive)) %% for the use of receive

#(define (chord->note chord n . args)
"Return either the note n of chord chord, keeping articulations or if other
numbers are specified in args, a chord with the matching notes."
(receive (notes others)
 (partition noteEvent? (ly:music-property chord 'elements))
 (if (null? notes)
   chord
   (let* ((len (length 

Re: Fyi: this list, lilypond-user, just had it's subject [tag] and footer removed

[mskala]

On Fri, 25 Oct 2019, Andrew Bernard wrote:
> complex part of this, along with SPF and DKIM. The change that is being made
> here is clearly necessary to me, and explains some of the list issues people
> were having lately. Sadly, it's probably unintelligible to non-experts.

I run a mail server too, and I think From: munging is a better solution.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: Fyi: this list, lilypond-user, just had it's subject [tag] and footer removed

[mskala]

On Thu, 24 Oct 2019, sysad...@gnu.org wrote:
> Any list administrator for this list is free to change these settings
> back, instructions are below.

I hope that it will be changed back.  The subject tag is useful for
automatic categorization of incoming messages.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

Re: Creating MP3 files

[mskala]

On Tue, 15 Oct 2019, Martin Tarenskeen wrote:
> On Mon, 14 Oct 2019, msk...@ansuz.sooke.bc.ca wrote:
>
> > There are free soundfonts available, and other commercial ones for sounds
> > other than piano, but I don't have specific recommendations.
>
> You will need a General Midi (GM/GS/XG) compatible soundfont to play/convert
> Midifiles with correct sounds if you have defined other instruments than just
> piano (the default instrument) in your lilypond score.

Not necessarily - you can remap the instrument numbers either in Lilypond
or most synth software.  I did that to use a non-GM organ soundfont with
different instrument numbers for the different stops, in
https://audio.northcoastsynthesis.com/?t=loquat .  But it's
true that using a soundfont with GM numbers will give you one less thing
to think about, if the GM instruments are the ones you want to use.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Creating MP3 files

[mskala]

On Mon, 14 Oct 2019, Lisa C Lewis wrote:
> It appears that LilyPond only creates MIDI output.  Given that I need to
> share the audio with other people who may not have MIDI players, is
> there a means of generating MP3 files?  If not, what do folks recommend
> for converting MIDI to MP3?  I've looked through the documentation, but
> if it's in there I missed it.

Creating MP3, or any digital-audio format, requires synthesizing the
actual sounds of the notes.  It's far outside the scope of what a music
notation program does and no surprise Lilypond doesn't do it;
Lilypond isn't even good at MIDI, and MIDI is much closer to scope.

I usually use TiMidity++ (http://timidity.sourceforge.net/) to synthesize
WAV files from Lilypond MIDI output, then LAME to encode the WAV files
into MP3 (encoding MP3 would usually also be a separate step from the
audio synthesis).  With this or any software synth, the choice of a
library of patches or samples is also quite important - probably more
important to the final sound than the synthesis software itself.  Most
often, I use the "Nordic Upright Piano" soundfont which I licensed from
Precisionsound; they appear to be selling it now at
   
https://majesy.com/samples-sounds/nordic-upright-piano-v2-multiformat-krock.html

but that wasn't the Web site through which I bought the product several
years ago; I don't know the history there.  There are free soundfonts
available, and other commercial ones for sounds other than piano, but I
don't have specific recommendations.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Input syntax question

[mskala]

On Mon, 30 Sep 2019, David Kastrup wrote:
> The respective lines in lily/lexer.ll read
>
> A [a-zA-Z\200-\377]
> SYMBOL{A}([-_]{A}|{A})*
> COMMAND   \\{SYMBOL}

Interesting that this disagrees with the item from the Notation Reference
cited elsewhere in the thread, which says hyphens and underscores aren't
allowed.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Input syntax question

[mskala]

On Mon, 30 Sep 2019, Andrew Bernard wrote:
> The grammar is in Appendix A of the Lilypond Contributor's Guide.

Thanks.  How about the definitions of the terminals, such as STRING
and SYMBOL?

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Input syntax question

[mskala]

On Sun, 29 Sep 2019, Thomas Morley wrote:
> > What characters are allowed in variable names?
>
> From NR:
> "The name of a [LilyPond-]variable should have alphabetic characters
> only; no numbers, underscores or dashes."

Thanks.  I had a hard time finding this in the manual.

> Note the "yet"!! It may change in future versions.

Is there a formal grammar of the Lilypond language anywhere, other than
the source code itself?

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Input syntax question

[mskala]

What characters are allowed in variable names?

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Links in PDF-Files

[mskala]

On Fri, 20 Sep 2019, sir.teddy.the.fi...@gmail.com wrote:
> Why does lilypond add these links and is there a way to prevent it from
> doing so?

Use the "-dno-point-and-click" option on the command line when you run
LilyPond to turn off these links.  The links are intended to make it
easier to open the relevant point in the source file when using an editor
that supports that - they can be integrated with editors like Emacs.
That's a pretty specialized use case, though, and I don't know why the
feature is turned on by default.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Migrating from commercial music notation software to free alternative

[mskala]

On Wed, 12 Jun 2019, David Kastrup wrote:
> > LaTeX users are accustomed to writing macros in a Turing-complete language
> > with, for instance, if statements.
>
> LaTeX or TeX users?

I said LaTeX users because you did, but the statement is true about both.
TeX users were the original topic of this thread.

> TeX's macros are so peculiar because they rely on ad-hoc macro argument

LilyPond's programming model is very different from TeX's, and will not be
familiar to someone who comes in expecting to program LilyPond the same
way as TeX.  LilyPond is not a "TeX-based" or a "TeX-like" system.  Your
insistence that TeX is "peculiar" suggests that you think, as I do, that
programming LilyPond is much different from programming TeX - which is
what the original poster needs to know.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Migrating from commercial music notation software to free alternative

[mskala]

On Wed, 12 Jun 2019, David Kastrup wrote:
> > nor conceptually TeX-like, despite the fact that it uses backslashes.
>
> It's a batch processing system with plain text input syntax.  That makes
> for workflows not unaccustomed to LaTeX users.  By the way, it did

LaTeX users are accustomed to writing macros in a Turing-complete language
with, for instance, if statements.  LilyPond has no equivalent concept to
TeX macros:  variable values in LilyPond are data, not code, and are
completely evaluated when parsed and assigned.  They always do exactly the
same thing every time subsequently invoked, and cannot contain real
conditionals or parameterized behaviour.  All the programming-language
functionality in LilyPond is shifted into "music functions" that can be
applied to the dead data, but never used inline if they are to retain
their programmable behaviour.  Complete evaluation at parse time makes
programming a much different experience, and not one likely to be familiar
to a TeX or LaTeX user.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Migrating from commercial music notation software to free alternative

[mskala]

On Wed, 12 Jun 2019, ah wrote:
> ... using a TeX-based or TeX-like (free) music composition system, if
> available and doing all programming, templating etc. in this myself.
> Advantages: platform independent and free.

Lilypond is not TeX-based nor conceptually TeX-like, despite the fact that
it uses backslashes.  Its programming interface is all based on Scheme and
works quite differently from TeX macro expansion.  If you just mean "free"
when you say TeX-like, fine, but if you want something that is
programmable the same way TeX is, then you should consider other free
software that is more closely connected to TeX.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Vertical spacing of numeric time signature

[mskala]

On Thu, 9 May 2019, Malte Meyn wrote:
> Am 09.05.19 um 16:53 schrieb msk...@ansuz.sooke.bc.ca:
> > Is there any simple way to modify the vertical spacing between numerator
> > and denominator in a numeric time signature?
> >
>
> Not really simple. But it can be done by redefining the stencil:

Thanks!

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Vertical spacing of numeric time signature

[mskala]

Is there any simple way to modify the vertical spacing between numerator
and denominator in a numeric time signature?

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Fine bar line \break before repeat sign

[mskala]

On Tue, 7 May 2019, Adam Good wrote:
> I'm baffled by bar lines. In the example below, I would like for the f1 bar
> to use a "final" bar line as in \bar "|." the \break then on the next line
> begin with a repeat sign. The manual doesn't hint at this
>
> http://lilypond.org/doc/v2.19/Documentation/notation/bars#bar-lines

If I'm correctly understanding what you want, this seems to do it:

\defineBarLine ".|:-|." #'("|." ".|:" "")

\relative {
  f'1 \bar ".|:-|." \break
  \repeat volta 2 { g1 } \break
  a1
  b1 \bar "|."
}


-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: tag issue

[mskala]

On Sat, 13 Apr 2019, Gianmaria Lari wrote:
>     \tag #'testOne a 
>   \tag #'testTwo b
> ~
>   \tag #'testOne a 
>   \tag #'testTwo b
>
>   }
>
>
> But then why lilypond removes the tie? Shouldn't just remove the expression
> following testTwo that is "b" ?

The tie is not a separate object.  The tie is part of the first b and that
b is tagged with testTwo.  So when everything tagged testTwo is removed,
the b is removed, and the tie disappears.

This issue is another aspect of the fact that LilyPond "music" is data,
not code, and cannot contain real conditionals.  It's also related to why
one writes "a( b c)" to slur all three notes together, not "(a b c)".
The parentheses do NOT designate a syntatic group as they do in pretty
much all real programming languages including Scheme; in LilyPond, a
parenthesis is a modification to the properties of the preceding note.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Flat flared hairpins

[mskala]

On Tue, 1 Jan 2019, Andrew Bernard wrote:
> American floors: 11 12 14 15
> English floors: 11 12 13 14
>
> I saw this a lot when I worked in new York.

I think this custom has persisted in the USA because large buildings need
to have "mechanical" or "service" floors not directly visited by the
regular occupants, and if you're going to have the elevator skip a floor
anyway, you might choose it to be the one with a number some people want
to avoid.  In East Asia, where the number 4 is similarly considered
unlucky, the number 4 is sometimes skipped - and I've even seen a building
where the floor numbering skipped both 4 and 13.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Not Nice Review of the LilyPond

[mskala]

On Sun, 2 Dec 2018, David Kastrup wrote:
> Have you looked at tags?

Please read my messages before responding to them.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Not Nice Review of the LilyPond

[mskala]

On Sun, 2 Dec 2018, David Sumbler wrote:
> > But MusiXTeX can do "if" statements.

> I felt that an "if" would be useful, so I eventually came up with:

That is useful for conditional includes, but it can't be embedded in the
data structure that LilyPond calls "music" and stores in variables.  As
soon as something is turned into "music" it has to be data, not code;
conditionals must either be evaluated before the input is turned into
"music," or by separate code (usually, in Scheme rather than in LilyPond
as such) that conditionally modifies the static "music."  That latter
approach, with tags in the "music" that can be filtered out, is what's
usually recommended as a substitute for real conditionals in LilyPond, but
it's quite limiting compared to what programming languages can do with
"if."

For those familiar with programming languages it's not so mysterious why
this situation comes about.  LilyPond takes care to call its variables
variables in the documentation.  You reference them; you don't execute
them.  They contain data, not code.  Obviously, data will be the same
every time you look at it, unless you externally change it.  But I wish
that without escaping to Scheme I could have something more like a macro
than like a variable, evaluating its conditionals (and doing other
programming-language stuff) every time it is used.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Not Nice Review of the LilyPond

[mskala]

On Sun, 2 Dec 2018, David Kastrup wrote:
> is hard.  At least LilyPond is a better starting point than MusiXTeX.

But MusiXTeX can do "if" statements.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Octave shifts in polyphonic setting

[mskala]

On Tue, 25 Sep 2018, Jogchum Reitsma wrote:
> Restoring this from the first bars affected by adding or deleting apostrophes
> or comma's, sometimes lead again to side effects. Rather frustrating...
>
> Is there a way to prevent this?

Are you using relative mode?  I only use absolute, myself; every pitch
specifies its octave and they don't change depending on the cutting and
pasting of other notes.  I find that the annoyance of having to debug this
kind of thing in relative mode outweighs the convenience of leaving out
octaves on some pitches.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: OT: typewriter LaTeX package

[mskala]

On Fri, 16 Feb 2018, Karlin High wrote:
> Have you ever seen Luc Devroye's "On Snot and Fonts" website, with info on
> over 70,000 fonts? Looks like he picked up the Vintage Type collection at some
> point.

Yes, I'm even listed in there myself.  Great resource.  Doesn't look like
he has more recent information on Vintage Type, though.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: OT: typewriter LaTeX package

[mskala]

On Fri, 16 Feb 2018, Shane Brandes wrote:
> Got it to work. Figured out you can change to what ever font you want
> in the sty file. Lessening the the grayscale variability and some of
> the other variables with the use of a historical font yields really
> convincing period style documents. This is absolutely great.

Really real typewritten documents wouldn't have every instance of every
letter shifted independently at random as this package does, though.
Instead, individual typewriters would have unique but systematic
distortions.  Maybe on my typewriter, each "e" would be a little lower
than the baseline and each "T" would be tiled three degrees; and on your
typewriter it would be some other distinctive pattern.  These kinds of
things were important in forensic analysis as a way of identifying which
typewriter was used to produce a document.

When it comes to fonts, at one point when I needed a nice-looking
simulated typewriter font I ended up licensing Underwood Typewriter from
Vintage Type, who used to be at vintagetype.com but now don't seem to be
on the Web.  I don't know if that means they're out of business.  The site
at vintagetype.co doesn't seem to be the same company.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: OT: typewriter LaTeX package

[mskala]

On Thu, 15 Feb 2018, Torsten Hämmerle wrote:
> Let me assure you that Urs is right: in Germany, without any doubt, there is
> no double space.

> It says that there is only ONE space after punctuation marks according to
> German standards.

> Finally Associated Press Stylebook (!): "Use a single space after a period
> at the end of a sentence."

All present tense... there's no doubt that the narrow space is more common
*today*, but typewritten documents in the typewriter era (which ended in
roughly the 1980s) are not necessarily the same story.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: OT: typewriter LaTeX package

[mskala]

On Thu, 15 Feb 2018, Urs Liska wrote:
> > that may not be standard for proportional typesetting (even LaTeX's
> > standard 1.33 factor is no longer popular) but the double-width sentence
> > space was universal in typewritten texts when typewriters were common.
> >
>
> Are you sure this is not related to language and culture? I can't recall

It may be.  I was talking about English-language typewritten texts.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: OT: typewriter LaTeX package

[mskala]

On Thu, 15 Feb 2018, Urs Liska wrote:
> Sorry for the OT post, but I just have to share this new LaTeX package:
> http://www.ctan.org/pkg/typewriter
>
> I really hope I'll find an opportunity to use it soon:-)

Cute.  For the genuine typewriter feel, it's important for the
between-sentences space to be twice the width of the between-words space;
that may not be standard for proportional typesetting (even LaTeX's
standard 1.33 factor is no longer popular) but the double-width sentence
space was universal in typewritten texts when typewriters were common.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Pitch inflection

[mskala]

On Tue, 30 Jan 2018, David Kastrup wrote:
> > as closely as possible I don't want to substitute quarter-tone symbols. Is
> > there a simple way to insert arrows in place of accidentals? Playback is
> > not an issue.
>
> Quarter notes wouldn't work anyway since you'd not be able to
> distinguish a quarter note up from e from a quarter note down from f.

Really?  The input { eih'1 feh'1 } seems to work for me, producing
distinct "e half-sharp" and "f half-flat" notation even though in 24-EDO
these are the same pitch.  It seems like just replacing the "half-sharp"
and "half-flat" symbols with up and down arrows would be enough to satisfy
the original poster's request.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: [OT] Linux Users

[mskala]

On Fri, 17 Nov 2017, Brett M. Gilio wrote:
> How many Linux users are out there in the Lilypond community? Do any of
> you use other type-setting software such as LaTeX or Csound rather than
> graphical tools?

One here.  I'm not sure Csound qualifies as typesetting software, but I
use it often for synthesis, and LaTeX for typesetting.  I use Lilypond
(from the command line, usually invoked by a Makefile) for translating
between human and machine-readable music in both directions:  sometimes
I'll compose music in the form of a Lilypond file and use Lilypond to
convert it to MIDI which I can use with my hardware and software
synthesizers, and sometimes I write software that generates music in the
form of Lilypond files, which I engrave to make human-readable PDFs.  I do
pretty much of my computing in a Linux environment.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: [OT] Grammatic gender

[mskala]

On Fri, 17 Nov 2017, J Martin Rushton wrote:
> There is a similar issue with the "apologetic apostrophe" in Scots.
> From the 18thC to mid-20thC writers inserted apostrophes where Scots
> didn't have a consonant that English does.  For instance the English
> word "give" is equivalent to the Scots word "gie".  The apologetic
> apostrophe would render this "gi'e" but this is now frowned upon.

Maybe someday writers of English will ha[v]e to use apologetic
square brackets.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Text listing output in .txt file

[mskala]

On Wed, 2 Aug 2017, Daniel Sanmartín Nieto wrote:
> Is it possible to get a .txt output with a listing of text inputs written
> throughout the music file?

Does this have to be done all in Lilypond?  Because it would be trivial to
write your bits of text as comments with "%" and then extract them
into a separate file using an external utility like grep or perl.
Something like:

{
  c4 d e f |
% text 1
  g f e d |
% text 2
}

and then

grep '%' score.ly > score.txt

which would give

% text 1
% text 2

or, more elegantly because it separates out just the comment text,

perl -ne 'print "$1" if /%\s*(.*)/' score.ly > score.txt

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Help changing chord names

[mskala]

On Mon, 17 Jul 2017, Tom Swan wrote:
> Hi. How do I change the chord name to just D13, not D9 13, as in the
> following snippet? This is probably rudimentary, but I'm a bit rusty and
> just getting back into lp. Thanks. -- Tom

Looks like the use case for this thread:
   http://lilypond.1069038.n5.nabble.com/ChordMarkup-context-tt204258.html

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ChordMarkup context

[mskala]

On Wed, 5 Jul 2017, Thomas Morley wrote:
> So I tried a proof of concept, although I'm not convinced of the idea
> to have chords as markup only.

Thank you!  This seems to be a big improvement and I hope it'll reduce the
perennial confusion people have with chord names, if we can simply point
them to it as a way to print names that match the input.

> Also, one drawback may be the huge amount of string-operations. I fear
> it may come at a cost (compilation time) and other problems once

My guess is that since chord names are most often used at all for things
like popular songs, which are relatively short and may not contain a whole
lot of other difficult engraving, this won't be prohibitive in practice.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Circular dependencies - Deadlock

[mskala]

On Wed, 21 Jun 2017, caag...@gmail.com wrote:
> On 06/21/2017 11:10 PM, Johan Vromans wrote:
> > If you have a non-infinite recursive include it will continue.
>
> I think that would require solving the Halting Problem first.

That's true if it has to determine whether the recursion is infinite, but
my understanding of the proposal was that Lilypond would continue with a
warning in any case, not trying to decide whether it's infinite, and let
the user deal with shutting it down if in fact it is infinite.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Circular dependencies - Deadlock

[mskala]

On Wed, 21 Jun 2017, Johan Vromans wrote:
> Instead of aborting, LP could issue a warning that it detected a circular
> include. If it then hangs, you have a clue what is going on. If you have a
> non-infinite recursive include it will continue.

If it's only a warning (we need not get back into the "fatal warnings and
non-fatal errors" discussion) then this seems harmless.  Another point
worth considering, though, is that it's not trivial to detect whether two
paths represent the same file.  Doing it correctly is more than just a
string comparison, and unlikely to be portable.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Circular dependencies - Deadlock

[mskala]

On Wed, 21 Jun 2017, Simon Albrecht wrote:
> It would be even better, I think, if Lily noticed the circular dependency and
> aborted with an informative message instead of just running on forever.

This may be a problem if there's any possibility of an include being
conditional.  Then, someone could write a non-infinite recursive include
deliberately, and be disappointed when Lilypond breaks it.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Circular dependencies - Deadlock

[mskala]

On Wed, 21 Jun 2017, Michael Käppler wrote:
> foo.ily:
> \include "bar.ly"

> bar.ly:
> \include "foo.ily"

> Am I right to consider this a bug?

I don't think so - at least not a bug in Lilypond.  It's just doing what
you told it to do, and most other language parsers that have an "include"
facility will similarly be unable to give a useful result when fed
infinitely recursive include files.  The usual advice to users is not to
write such input.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: lilypondblog.org: A Simple Trick to Help all Musicians

[mskala]

On Wed, 21 Jun 2017, Urs Liska wrote:
> Do you think you can come up with a topic that actually relates to music
> notation and still allows you to introduce your article? As it is I'm not

I would advise caution here.  It sounds to me like the person didn't know
she was writing to a mailing list, and not even having done that much
homework about whom she was contacting suggests her interest is primarily
in advertising her own thing, not in anything that would align with our
interests.  I regularly get solicitations from people offering to "help"
me with "free content" for my own Web site when it's clear they have no
idea what my Web site is about and they just want access to my audience
for their own message.  When I'm feeling very generous I tell them how
much I charge for advertising, and then I never hear from them again.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Chords in LilyPond

[mskala]

On Fri, 26 May 2017, Kieren MacMillan wrote:
> And I must say, I see his point: your implication seems to be that the
> tolerance the “ordinary user” apparently has for working in a
> notoriously uninviting and unfriendly [other people’s words, not mine!]
> non-GUI-based batch-processed music engraving system suddenly disappears
> [only] when it comes to chords…

I'm describing what I have seen on the list.  Users frequently come here
to ask "When I typed this chord symbol, why was something else engraved?".
They do not ask that about single notes.  We can guess as to why it
happens with chord symbols and not with single notes, and I think your
guess that it's because chord symbols look like text and notes do not is a
good guess.  But it ultimately doesn't matter *why* it happens.  It does
happen.  Wouldn't it be nice if it didn't happen?

What I see is a problem that really occurs, frequently, and could be
solved easily.  And a resistance to solving it in the way that would work,
because that solution would not also solve hypothetical problems that do
not frequently occur and could be solved in other ways anyway.  This seems
like cutting off the nose to spite the face.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Chords in LilyPond

[mskala]

On Fri, 26 May 2017, Kieren MacMillan wrote:
> You do know that you’re not *forced* to use ChordNames, right? (Of

> If you want to type something and simply have it appear as you typed it
> (i.e., with no use or need for manipulations like transposition), why
> not just use Lyrics? It already does exactly what you want, e.g.

That in fact is what I do in my own engraving.  It works pretty well; not
perfectly because the spacing and fonts aren't the same as would be
produced by the ChordNames context.  Last time I discussed this suggestion
on the list, I suggested that the code for \chordtext could well be
derived from the lyrics code.  But this approach isn't discoverable for a
user who only reads the instructions.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Chords in LilyPond

[mskala]

On Fri, 26 May 2017, Simon Albrecht wrote:
> Am 26.05.2017 um 15:48 schrieb msk...@ansuz.sooke.bc.ca:
> > On Fri, 26 May 2017, Simon Albrecht wrote:
> > > Well, input syntax does not equal desired output.
> > For ordinary users, it does.
>
> I have no idea what you’re talking about.

Chords.  As the subject line says.

> { c4 } does not print a ‘4’

That's not a chord.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Chords in LilyPond

[mskala]

On Fri, 26 May 2017, Henning Hraban Ramm wrote:
> I would manually write C/a if I want to let the player chose between c major 
> and a minor.
> (Lowercase letters for minor chords needed a while to be possible with 
> LilyPond, but they are.)

It's fine if you want to write that and you and the reader know what it
means, but I think most readers would interpret it as "C with A in the
bass" (and why that chord is not called A-minor-seventh, left unclear).
This would be a problem for a system like current LilyPond that insists on
translating it to notes and back, because the internal representation for
the choice is likely to collide with that for a chord which really is "C
with A in the bass"; but it'd be no problem with a system that just
formats and prints what's typed, in which "C/a" can mean anything and the
system doesn't need to interpret it.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Chords in LilyPond

[mskala]

On Fri, 26 May 2017, Simon Albrecht wrote:
> Well, input syntax does not equal desired output.

For ordinary users, it does.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Chords in LilyPond

[mskala]

On Fri, 26 May 2017, Thomas Morley wrote:
> (Close to) all requested stuff is possible even right know. Ofcourse

The problem is not that LilyPond cannot print the desired symbols.  The
problem is that the input to print those symbols does not match the
output, and the mapping from input to output is not straightforward,
discoverable, nor understandable to non-expert users *even with
documentation*.  Mere possibility of printing the symbols is not relevant
to this thread, so I'll skip further comment on it.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Chords in LilyPond

[mskala]

On Thu, 25 May 2017, Mats Behre wrote:
> While this is true, in order to support things like transposition (which I for
> one use frequently) I think you will have to devise formats for input and
> internal representation (they may be the same) that identifies both all

Yes, if you're doing transposition - or stuff like auto-generated guitar
diagrams, which is another thing people like to have - then you need an
internal representation that admits generating note sets.  A
print-what-I-typed feature doesn't address that and couldn't replace the
existing mess; it would have to be an addition, not a replacement.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Chords in LilyPond

[mskala]

On Thu, 25 May 2017, Thomas Morley wrote:
> I vaguely remember such threads.
> Though, could you give some examples (or links) so it is present here as well?

Request for "rootless slash chords" from 2014 but brought up in a thread
here last month:
  https://sourceforge.net/p/testlilyissues/issues/3909/
The discussion on that issue assumes that the user will enter something
like
  \chordmode { c c/e c/g }
to get the desired output of
  C /E /G
with LilyPond doing some kind of translation to not show roots when there's
a slash, but what would make sense would be for the user to enter
  \chordtext { c /e /g }
and get
  C /E /G
That would be easy by directly printing the input with only formatting
translations (I am counting the lowercase to uppercase conversion as
formatting) and much harder with an attempt to go to notes and back in
between.

Request for "alt" notation for chords:
  http://lists.gnu.org/archive/html/lilypond-user/2017-02/msg00644.html
Here a chord symbol *does not correspond to a fixed set of notes*; it's
deliberately leaving a choice for the performer, making any translation to
notes and back difficult.  The thread includes a suggested "solution" of
  \chords {
\once\override ChordName.Text = \markup { G \super { 7 alt } }
g:7^5
  }
but it sure would be easier to just type
  \chordtext { G7alt }
Note the desired symbol does NOT contain a colon or a caret or a 5; why
are those things needed in the input?  They exist to help LilyPond decide
on a note set, which is unnecessary for engraving the symbol.  Requiring
an entire line of override code just for one symbol is a lot to ask, too;
and yes, it could be achieved with less per-chord work when there are a
lot of them by defining a chord name override or a macro, but this is
still a lot harder than just typing
  \chordtext { G7alt }
Any ambiguity in what that *engraves* is only at the level of "which parts
of this symbol does the user want superscripted?".  We cannot expect to
translate it to notes cleanly without more information about what it
means, but we don't need to know what it means to engrave it.

This thread:
  http://lists.gnu.org/archive/html/lilypond-user/2017-02/msg00600.html
User wants to enter:
  \chordmode { e13 }
and get
  E13
but instead he gets
  E9 13
The reasons for this are arcane, and attempts to "solve" it are predicated
on deciding which notes are meant to be in an E13 chord when it's not
otherwise modified - which is not a universally agreed point among
musicians, and should be completely irrelevant to the question of how to
engrave the letter "E" and the numerals "1" and "3".  At one point in the
discussion is it pointed out that he could get
  E13
by entering
  \chordmode { e:11.13 }
but I think it ought to be clear why that isn't ideal.

This thread:
  http://lists.gnu.org/archive/html/lilypond-user/2017-01/msg00248.html
User wants to engrave a chord they describe as "Gm7(b5)/F" and is told to
type
  g : m7.5- / f
Note the desired output does not contain a colon or hyphen.  Using that
suggestion, as in
  \new ChordNames { \chordmode { g : m7.5- / f } }
will actually engrave
  Gø/F
(where the ø is superscript).  User doesn't pursue it further, but this
output does not closely resemble the requested
  Gm7(b5)/F

That's just this year's worth.  Four threads in five months.

Counterpoint:  "but MIDI!" is a common argument for why chords ought to
always have translations to notes.  I use MIDI a lot myself.  But if we
care so much about MIDI, why can't we have better MIDI support - such as
the ability to enter arbitrary control changes (ideally: also raw
hexadecimal bytes, for SYSEXes and such), and to handle repeats correctly?
In order to get even halfway reasonable MIDI output, I need to write two
copies of my music, one for engraving and one for MIDI, with as much as
possible shared between them using variables (but that, in turn, harmed by
the nonexistence of any real "if" statements).  Really generating correct
MIDI from the same music used for engraving seems to be a lost cause.
The usual answer when those things are brought up is that LilyPond is
about engraving, not about MIDI, and the MIDI features are only meant for
"proofreading," not to generate high-quality MIDI that could (for
instance) be fed into a synthesizer for performance.  But if LilyPond is
not about MIDI, chord names should not be about MIDI either.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Chords in LilyPond

[mskala]

On Thu, 25 May 2017, Charles Winston wrote:
> > On May 25, 2017, at 12:26 AM, Kieren MacMillan
> >  wrote: Except  contains a
> > huge amount of information that cannot currently be input in
> > \chordmode (as far as I know).
> >
> > Ultimately, as long as we end up with an input system robust enough to
> > convey that amount of information, I don’t particularly care whether
> > it’s in \chordmode or whatever.
>
> True. I think ideally we need an input mode that is stronger than
> chordmode, or we at least need to improve chordmode to be able to handle

This is why I think the chord names -> music -> chord names flow is a
problem.  Real users do not think in terms of a translation from input to
notes and then from notes to output; as seen in the recurring threads on
this mailing list, most non-expert users don't even realize that "chord
mode" and the "ChordNames context" are two different things that do not
necessarily always go together.  The natural way for typesetting of chord
names to occur is by a direct mapping from input chord names to output
chord names without going through the current "music" data struture
consisting of notes, at all.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Permission for music

[mskala]

On Wed, 24 May 2017, David Wright wrote:
> Perhaps this is because educators are pandering to their ignorance,
> thus decreasing the likelihood they'll ever encounter the term.
> I'm glad that LilyPond's authors know precisely what it does so well.

Removing the advertisement is much easier than educating everyone who will
ever look at a piece of sheet music about what the word "engrave" means.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Chords in LilyPond

[mskala]

On Wed, 24 May 2017, Charles Winston wrote:
> I’m participating in the Google Summer of Code working on improving 
> LilyPond’s internal representation of chords. The goal here is to create a 
> data structure that will represent a chord’s semantics beyond just a list of 
> notes in the chord. The current representation contains almost no information 
> other than a list of notes, and we want to change this to include other 
> semantic information, i.e. the root, quality, extensions. The current 
> representation causes the chord naming process to infer the correct name from 
> only the notes in the chord, which can create some problems—it would be much 
> better to maintain the information provided by the user in chord mode about 
> the semantics of the chord through to the naming process. Here is a rough 
> list of semantic information I believe should be included in the data 
> structure:

Correctly printing chord names - and specifically "Why doesn't the output
match what I typed?" - is a huge problem for users, and is a recurring
thread on this list, so I certainly think improvements there would be a
good thing.

What I think is most needed is a chord-naming mode that *just prints what
the user typed*, formatted with the fonts, spacing, and so on that we
expect for chord names - not translating it to an "internal
representation" of notes plus extra data as LilyPond "music" at all.  But
I was shouted down last time I proposed that, I think by people who
thought I had claimed it would solve all possible obscure problems for
imaginable hypothetical users.  As I made clear, it would only solve the
main problem of 99% of relevant users who actually exist, and that wasn't
enough to satisfy the list.

Failing a direct "print what I typed" mode, adding a lot of extra data to
the internal representation while keeping the current framework is the
hard way to get the input to match the output, but it'd be an improvement
and we need an improvement.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Permission for music

[mskala]

On Wed, 24 May 2017, Simon Albrecht wrote:
> > This is one reason that putting advertising for the LilyPond Web site in
> > every PDF document by default may not be such a great idea.  It makes
> > LilyPond appear to have a meaningful connection with the content.
>
> Only if you overlook that the tagline specifically says the music was
> _engraved_ with LilyPond, which does not tell anything about any connection
> between LilyPond and the _content_.

But people do overlook that, as this thread demonstrates.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Permission for music

[mskala]

On Wed, 24 May 2017, Manuela Gößnitzer wrote:
> Which website would that be? AFAIK this here is a mailing list, there is no
> website with music sheets.

This is one reason that putting advertising for the LilyPond Web site in
every PDF document by default may not be such a great idea.  It makes
LilyPond appear to have a meaningful connection with the content.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: compile time linux/windows

[mskala]

On Thu, 4 May 2017, Orm Finnendahl wrote:
> Does somene have similar experiences and could someone with a Windows
> computer maybe compile the score and report back to the list so that
> we can narrow down the culprit?
>
> Is it the lilypond version or could it be a wrong setup?

Seems to me that it's absolutely necessary to test the two machines with
as many variables the same as possible - for instance, the same version of
Lilypond.  When you've got different versions, different CPUs, different
amounts of RAM, different operating systems, and are running Lilypond
through different interfaces, there's no way to know which variable is
the one that matters, or whether the effect comes from something more
complicated than just one variable.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Parallel Square Premusic

[mskala]

On Thu, 23 Mar 2017, David Kastrup wrote:
> Punch cards seem to the best medium for your format.  Not just that they
> are rigidly column-based, but you'll also easily distinguish letters

With careful programming you can probably get the card punch to serve as a
musical instrument, too.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: What can Premusic do that others can't?

[mskala]

On Tue, 21 Mar 2017, Flaming Hakama by Elaine wrote:
> The only time I've even seen an attempt at irrational durations was in the
> one other thread on this list that was actually more annoying, more
> aggressive and differently clueless.  I believe the intended durations were
> 1/sqrt(71) or something equally undiscernable.

FWIW, I've written algorithmically-generated music with irrational
durations by a process described at
   http://ansuz.sooke.bc.ca/professional/music/notes-on-notes-on-the-plane.pdf

and I think it came out pretty well.  It's not deliberately written with
irrational timing just to be annoying; the square roots come naturally
from the underlying geometric model and couldn't be easily removed without
compromising that in a significant way.  Unfortunately, the audio
recordings are currently offline because I stopped paying for SoundCloud,
but I plan to put them back online elsewhere within a month or two, and
could provide files on request if anyone asks me off-list.

I used Lilypond to do some notation examples in that document, but I
didn't attempt to create a complete score of the composition in music
notation nor figure out what such a thing would sensibly look like.  It's
not intended for human performance and the actual score is a set of Csound
files.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Re: What can Premusic do that others can't?

[mskala]

Please trim quotes in replies.

On Mon, 20 Mar 2017, Jeffery Shivers wrote:
> On Mon, Mar 20, 2017 at 7:04 PM,   wrote:
> > me out? And what about my code is so cryptic? Can't anyone read a
> > "dadadaaa"?
>
> No. Probably for the same reason *anyone* can't just read binary code.
>
> You might be able to sell that to those violin playing robots in Japan though.

I think they would prefer "ダダダーー".  ASCII isn't universal and there
are good reasons for Unicode, even the parts that are hard to type on "the
keyboard everybody has."

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: 13th chord?

[mskala]

On Sun, 26 Feb 2017, Wols Lists wrote:
> The OP complained that when he asked for "C13" he got "C 9 13". Sounds
> to me like now, if he asks for "C13" that's what he'll get, but if he
> asks for "C13 (A13)" he's going to get "C 9 13 (A 9 13)". That's almost
> worse!!!

What do you mean by "now"?  That certainly doesn't describe current
LilyPond, nor my proposal.

I've said it clearly enough times already, but I'll say it again:  I think
there should be a feature to print what was typed, in the visual format of
chord names, without interpreting it as music.  No more or less.  And this
is proposed as a new feature, without deleting the existing features.

Would it support transposition?  No, but it wouldn't harm users who want
to do transposition with the currently-existing features.

Would it directly support MIDI, automatic fingering charts, or any other
features that require LilyPond to interpret the input as music?  No,
because the point is to NOT interpret the input as music, only as stuff to
be printed.  But, again, it wouldn't harm users who want to use or extend
the currently-existing features for those things.

Would it stem the relentless stream of new users asking for help with
chord names on this mailing list?  Yes, if properly implemented and
documented as a first-class feature and not a "poor cousin," because what
those users really want is to have the chord names they typed, printed,
and only that.

But the clear consensus of the list seems to be that nothing suitable for
the 99% use case can be allowed to exist if it isn't also all things to
everyone, so I'll bow out of the discussion now.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: 13th chord?

[mskala]

On Sun, 26 Feb 2017, Wols Lists wrote:
> > I don't know what that refers to.  Are you confusing me with someone else?
> >
> "I imagine it would make sense for most of its code to derive from the
> code currently used for lyrics, but that fact would preferably NOT be
> visible to users."

The difference between the new feature coming from lyrics code and the
new feature being implemented in some other way should not be visible
to users.

The difference between using the new feature at all, and not using it,
should absolutely be visible to users.  That is the purpose of having it.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: 13th chord?

[mskala]

On Sun, 26 Feb 2017, Anthony Youngman wrote:
> Replying to myself - remember, you said the user shouldn't notice any
> difference. With my code, if you want to change the capo key, it's a

I don't know what that refers to.  Are you confusing me with someone else?

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: 13th chord?

[mskala]

On Sun, 26 Feb 2017, Anthony Youngman wrote:
> EXCEPT.
>
> This is *exactly* the scenario in which you will want my chord transposition
> code, and that doesn't make sense in a lyrics scenario.

Then they can use the existing code.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: 13th chord?

[mskala]

On Sun, 26 Feb 2017, Thomas Morley wrote:
> If the chordNameFunction (ignatzek-chord-names) does not do what we
> want, we should improve it, but not drop a plethora of
> lily-functionality.

I'm not proposing to "drop a plethora of lily-functionality" but only to
provide something that will be useful in the very common case of people
wanting to print chord names and wanting the output to match the input.
The proposed new feature would not be a modification of chord mode nor of
ChordNames, but a third thing separate from either of those two.  I
imagine it would make sense for most of its code to derive from the code
currently used for lyrics, but that fact would preferably NOT be visible
to users.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: 13th chord?

[mskala]

On Sun, 26 Feb 2017, David Kastrup wrote:
> To me it would seem that the default mode of operation should be for
> them to have matched rules where feasible, in order to have least
> element of surprise.

I agree, but A. it may not be feasible in some important cases, and
B. even matched rules wouldn't really solve the problem, because users
would still have to explain to both the input and output systems their
own preferred conversion between note sets and displayed chord symbols.
(It doesn't help that the standard and traditional musical rules are
*screwy* and the nonstandard rules many people want to use are even
screwier.)

Users want what they type to match what is displayed, even when it doesn't
follow the default rules and possibly even when it doesn't follow any
rules.  For the common use case of chord mode being used solely to
generate notes for ChordNames, and ChordNames getting its notes solely
from chord mode, we don't really need the notes at all.  Just turning the
user's input directly into markup would make all the common problems with
chords disappear.

I've actually used lyrics to print chord names sometimes when I just
couldn't get "proper" ChordNames contexts to do what I wanted.  It seems
like lyrics are 80% of the way to the markup idea I'm describing.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: 13th chord?

[mskala]

On Sun, 26 Feb 2017, Wols Lists wrote:
> I'm guessing lily is taking *in* his request for "C 13", converting it
> into the chord, and then converting that chord *back* into what it
> thinks is called "C 9 13". With the result that lily's output does *not*
> match the user's input. Frustrating!

Okay, I think I see the issue - it's the same problem everybody has with
chord mode and ChordNames, which is that those two things are completely
separate from each other despite the usual use case treating them as a
single entity.

\chordmode { c:13 } turns into 

\new ChordNames {  } prints "C9 13"

I agree it looks like a bug, but because of the separation between chord
mode and ChordNames, each is going to point the finger at the other as
being at fault, because each one is using its own rules which taken
independently seem sensible.  The real solution would be a thing like
ChordNames that is actally a specialized markup mode and just *prints
whatever is typed dammit*, with minimal formatting transformations
(perhaps automatically putting numbers in superscript, and that's about
all), instead of trying to convert to "music" and back.

Probably the easiest thing to do is use an override on printing the chord,
and just ignore the fact that the notes are wrong internally (which
doesn't matter as long as the chord mode input is only used for
ChordNames).  Like so:

chExceptionMusic = {
  1-\markup { \super "13" }
}

chExceptions = #( append
  ( sequential-music-to-chord-exceptions chExceptionMusic #t)
  ignatzekExceptions)

\new ChordNames {
  \set chordNameExceptions = #chExceptions
  \chordmode { c:13 }
}

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: 13th chord?

[mskala]

On Sat, 25 Feb 2017, Rob Torop wrote:
> 13 chord would be rendered as C13 in Ignatzek notation. My question is - is
> there a way for me to omit the "9" in the chord name?  My experience is

There's no "9" in the chord name "C13", so what are you really asking?

Do you want to enter a chord name and get a C13 chord with no ninth (or,
presumably, eleventh) in it - that is, the notes C E G Bb A?  In that
case, try
  \chordmode { c:13^9 }
This is also the same thing as a
seventh chord with added thirteenth, so you could use
  \chordmode { c:7.13 }

Do you want to change the input syntax so that
  \chordmode { c:13 }
will have the same effect currently achieved by
  \chordmode { c:13^9 }
?
If so, that's probably a bad idea and it's unlikely anyone here will be
eager to help you do it.  You'd have to go find whatever code parses
input in chord mode, and hack that.  This would break compatibility
between your customized version of LilyPond and files created to use
chord mode with the released version.

Do you want to enter these notes, by whatever means, and have the chord
name that is displayed by a ChordNames context be "C13" and not something
else, in particular, not mentioning the ninth?  (The default naming
scheme seems to be "C7 13".)  In that case, you can use a chord name
exception as described at
   
http://lilypond.org/doc/v2.19/Documentation/notation/displaying-chords#Selected-Snippets-62
 .

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: 48 and 72 ET

[mskala]

On Fri, 10 Feb 2017, David Kastrup wrote:
> enthused.  Why wouldn't we want to have best practices pointed out and
> promoted on the user list?

Best practices do not include attacking other list users.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: 48 and 72 ET

[mskala]

On Thu, 9 Feb 2017, David Kastrup wrote:
> I'll stick with my "that doesn't even make sense" verdict, thank you
> very much.

Don't ask the question if you're going to attack the answer.  Your
contributions to LilyPond development don't excuse you from practicing
basic civility.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

RE: Trolling and unacceptable behaviour on the list

[mskala]

On Sat, 19 Nov 2016, Andrew Bernard wrote:
> The people making it a big deal is just me. Now having lost all credibility,
> it's time I unsubscribed and stopped contributing.

Your call, but I didn't say "all."  Only your real point would be stronger
without the distraction.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Trolling and unacceptable behaviour on the list

[mskala]

On Fri, 18 Nov 2016, Andrew Bernard wrote:
> when asked politely refuses to give his name, refuses to provide minimal

This "real name" business is completely irrelevant and the people trying
to make it a big deal lose credibility on the other, much more important,
points they make.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Skyfonts

[mskala]

On Mon, 7 Nov 2016, Simon Albrecht wrote:

> On 07.11.2016 12:31, msk...@ansuz.sooke.bc.ca wrote:
> You might even say it was unethical by the provider of the font to not provide
> for use in free software like LilyPond…

...or to put encrypted files in a hidden location on someone's machine.
That's what malware does, and things that do it, are quacking like
malware.  But my ethics aren't the question here.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user