Re: Merging dynamics with music
msk...@ansuz.sooke.bc.ca writes:
> 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?
Yes, and yes.
\midi {
\context {
\Voice
\remove Dynamic_performer
}
\context {
\Staff
\consists Dynamic_performer
}
}
--
David Kastrup
Re: Merging dynamics with music
msk...@ansuz.sooke.bc.ca writes:
> 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 { }
> }
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.
--
David Kastrup
Re: Merging dynamics with music
msk...@ansuz.sooke.bc.ca writes:
> 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.
Try
\new Staff << \MyMusic \MyDynamics >>
since otherwise the variables will end up in separate Staff contexts.
--
David Kastrup
Re: automatic accidentals in subsequent measure(s) of *a different staff* in a PianoStaff context
Kieren MacMillan writes: > Hi all, > >>> Haven't you been dreaming about your First Patch™ for quite a while? > > Why, yes… yes I have! > >> You mean, in a dozen years? > > My immediate reactions was “wait wut i actually made three commits at > some point?” LOL Graham was really good at getting people involved and matching their capabilities to tasks. It's a good sign that you seem to be getting there again. -- David Kastrup
Re: automatic accidentals in subsequent measure(s) of *a different staff* in a PianoStaff context
Jean Abou Samra writes: >> > > Nice! Shall we add this to LilyPond proper? >> > I have no opinion. >> >> I do (surprise surprise): >> Yes. >> Though possibly with a different name (?). >> Regardless, seems like a useful LSR item. > > > Haven't you been dreaming about your First Patch™ for quite a while? You mean, in a dozen years? Because I have commit 03cb2f1ebc5ba2ca8ef2a7d05954a33babae5ac3 Author: Kieren MacMillan Date: Thu May 27 09:48:37 2010 -0600 Add independent control of thickness and offset for underline markup commit 5795203d3821ceaa5cd0e024350682fcfaf90691 Author: Kieren MacMillan Date: Fri Mar 13 11:12:29 2009 -0400 Add docstrings to functions in music-functions-init.ly; from Kieren. commit 17ab05d3eb28ffc7112c3a4af47116dd8dd7207c Author: Kieren MacMillan Date: Tue Sep 30 11:36:46 2008 +0100 Docs: Templates: piano centered dynamics > I mean, this would just be a matter of adding the style to the > accidental-styles alist in scm/music-functions.scm (plus updating the > documentation and regtests). Just saying... Indeed that sounds like a job for an uncautious "Yes" sayer. -- David Kastrup
Re: custom replace/map of one set of pitches to another
Lukas-Fabian Moser writes: > Hi Valentin, > > Am 01.09.23 um 00:41 schrieb Valentin Petzel: >> I don’t think this is a particularly good idea. Lilypond conceptually first >> creates data for the sementic meaning of the music (or the actual content) >> and >> have engravers turn this into graphical content. >> >> Mapping pitches to other pitches is not a layout option, but a musical >> transformation and should thus be done on the music level, not the layout >> level. Using an engraver will mean it is hard to combine this with other >> musical transformations, and it will also cause order issues as soon as you >> have an engraver that depends on the pitch property. > > I agree about the possible problems, and to be honest, I wasn't aware > that a music function solution like yours can deal with \transpose and > \relative gracefully (since the assignment of actual pitches is > complete when the music function is applied on the outside). Iff the music function is applied on the outside. -- David Kastrup
Re: Newbie questions
Mats-Olof Liljegren writes: > Hello! > > I'm a beginner with Lilypond but have decent programming > knowledge. Something I haven't managed to figure out is how to best > organize my projects. It becomes a very long file if everything is in > the same one, so I've tried splitting it into separate `.ly` files for > lyrics, soprano, alto, tenor, bass, and so on. It works, but I'm > guessing there are smarter ways to organize scores and lyrics. > > I've heard about `.ily` files, and if anyone could provide me with > links where I can learn and understand more, I would be grateful. .ily is just an arbitrary extension to indicate "included LilyPond file". The only actual difference to LilyPond is that if you call lilypond somefilename and somefilename does not exist, somefilename.ly will be tried instead. So .ily is not more than a convention. Enough so that editors and other utilities making decisions (like syntax highlighting) based on the file name will tend to know what to do with .ily. -- David Kastrup
Re: Automatic annotation of slide positions/fingerings for brass instruments.
samarutuk via LilyPond user discussion writes: > Hi, > I am not sure if I understand "iterated music" correctly? Is it about > the internal order of processing to get to the PDF score? "Iteration" is the main processing pass of music in musical time order. There are several processing stages for music: out of my head: Entry, scorification, iteration (several different internal phases for that as well), page breaking and output. Iteration is done separately for typesetting and MIDI and of course page breaking is just done for typesetting. -- David Kastrup
Re: Automatic beam behavior for 16th note triplets in 6/8 time
Joseph Srednicki writes: > Hi David: > Thanks for answering my inquiry about beaming 16th-note triplets. > However, it looks provided an example in a file called "js.ly" that > was scrubbed as indicated below. > If the example is not too long and it's not too much trouble, can you > reply pasting the content of "js.ly" in the body of the message? For one, I sent you a direct reply which should contain the example file. For two, it is present in the mailing list archive: <https://lists.gnu.org/archive/html/lilypond-user/2023-08/msg00240.html> The mailing list _digests_ may omit attachments, but why would you be referring to them when you have a copy of the mail? -- David Kastrup
Re: Automatic beam behavior for 16th note triplets in 6/8 time
Joseph Srednicki writes:
> Hello:
>
> The tiny example below contains a bar of sixteenth-note triplets in
> 6/8 time. In this example, I used the "[" and "]" characters to
> achieve the desired beaming manually.
>
> Instead of using the "[" and "]" characters, what is the correct code
> to set the automatic beam behavior for these sixteenth-note triplets?
>
> I tried to set the automatic beam behavior by using \set
> Timing.beamExceptions and \set Timing.beatStructure as described in
> section 3.5 of the Lilypond Notation Reference (LilyPond Notation
> Reference: 1.2.4 Beams), but I am not achieving the desired
> result. Most likely, I have misunderstood or missed something in the
> documentation or snippets.
>
> Thanks to anyone who is willing to provide an answer that will avoid the
> manual
> beaming of these triplets.
I have no idea what you tried, but the below works as expected for me.
\version "2.24.1"
\language "english"
global = {
\key e \minor
\time 6/8
}
melody = \relative c' {
\global
\tuplet 3/2 8 { e16 [ g e ] g [ e g ] a [ e a ] b [ d b ] c [ g c ] b g b} |
\tuplet 3/2 8 { e16 g e g e g a e a b d b c g c b g b} |
}
\score {
<<
\new Staff \melody
\new Staff \with {
beamExceptions = \beamExceptions { \tuplet 3/2 {
16 [ 16 16 ] 16 [ 16 16 ] 16 [ 16 16 ] 16 [ 16 16 ] 16 [ 16 16 ] 16 [ 16 16 ] } } }
\melody
>>
}
--
David Kastrup
Re: rall. autocalculation function in Scheme
Pierre-Luc Gauthier writes: > And what do you know : > > git diff to the rescue. > - > +\include "articulate.ly" > -<< > + \articulate << > > I tried different avenues and \articulate seems to have creeped its > way in in this floating point exception core dump… > > 'No idea why though nor do I need \articulate anyway. closing. Well, it certainly expands the problem space. But my own uses also employ articulate.ly . So it will still require something more special to trigger problems. -- David Kastrup
Re: rall. autocalculation function in Scheme
Pierre-Luc Gauthier writes:
> I'm not quite sure how to use it correctly yet but I suppose a typical
> usage would be :
>
> \time 6/8 % btw
>
> \tempoChange 8 1/2 0 {
> \skip 2.*4 |
> }
>
> ^ I.e. : To slow down every 8th during 2.*4 to reach (and keep (0)) a
> tempo half the speed it was.
>
> I get inconsistent results either :
> - working correctly
> - Hanging forever after [8][16][24][32][40][48][56]…
> - Or (with 2.25.8) :
> MIDI output to `output.mid'...[1]1213296 floating point
> exception (core dumped)
>
>> it has worked for at least a year or so here.
>
> No MWE for now but will provide if needed.
Can you think of a case where it wouldn't be needed?
--
David Kastrup
Re: changing clefs in transposed variable
juiceDéLemon writes:
> hello list,
>
> new here,
>
> i have the following simplified snippets:
>
> music = \relative c' {
> c8 d e g, a b c4
> }
>
> \score
> \relative c' {
> \transpose c f, \music
> }
>
> is it possible to change clef in the middle of the transposed music
Please check your examples to actually run. In this case, simply
music = \relative c' {
c8 d e g, a b c4
}
\score {
\after 8*3 \clef "alto"
\transpose c f, \music
}
works. In more complex cases it might be easier to use simultaneous
music constructs (namely << ... >> ) to enter the clefs into the current
Staff .
--
David Kastrup
Re: Where did the \header number go?
Jean Abou Samra writes:
> Le dimanche 20 août 2023 à 10:54 -0400, Rik Kabel a écrit :
>>
>> Hello list,
>>
>> I have a few pieces that have been engraved for my choir with 2.18.10 that
>> include catalog numbers entered as
>>
>> >
>> > \header {
>> > ...
>> > number = \markup { \fontsize #4 \sans \ellipse 11B }
>> > ...
>> > }
>> >
>>
>> The number variable seems to be gone with current versions, and I can find no
>> mention of the change.
>>
>> Has another feature taken its place?
>>
>
>
> I could not see any effect of adding number = "foo" to a \header block
> in 2.18.0, and I did not find any trace of this in the source code of
> that version either?
git log -S header:number
turns up empty, and that is the usual way to access such a variable. So
it is unlikely that this ever had been a part of LilyPond.
> Maybe you redefined a title using one of the xxxTitleMarkup variables, and you
> used \fromproperty #'header:number there?
>
> Or maybe you're just confusing this with the 'opus' variable?
I guess the latter.
--
David Kastrup
Re: Question about condensed score
Rip _Mus writes: > Hello, > does anyone happen to have an answer? > I just can't understand this behavior... > > Thank you > > Il mer 16 ago 2023, 08:18 Rip _Mus ha > scritto: > >> Good morning everyone, >> going back to the solution written by David, I found that simply adding >> the Duration_line_engraver causes the example to fail to compile. >> Can anyone tell me why this happens? This is just the Duration_line_engraver unable to deal with frenched scores (basically, it needs to check that a grob is still live before doing certain operations on it). This is easy to get wrong since frenched scores are not typically specifically tested for. Putting its original author in Cc. -- David Kastrup
Re: Changing the size of the TabStaff clef
Jean Abou Samra writes:
> Le vendredi 18 août 2023 à 16:34 +0100, Richard Shann a écrit :
>> Is it possible to reduce the size of the TabStaff clef?
>> this doesn't work:
>> \version "2.24.1"
>> <<
>> \new TabStaff \with {
>> \override TabStaff.Clef.font-size = #-1
>^
>
> You should remove this, you're already in a \with { ... } for TabStaff.
>
> (There is an issue for this quirk:
> https://gitlab.com/lilypond/lilypond/-/issues/1254#note_594663257 )
I am not sure there is a reasonable fix for this since \with does double
duty for passing named arguments to functions. You may want to argue
that \override/\revert should not be used in that fashion, but
assignments/\set have sort of the same problem (though admittedly
different syntax anyway).
--
David Kastrup
Re: RepeatSlash size is changed when StaffSymbol.staff-space is overriden in 2.24
Viktor Mastoridis writes:
>>
>> \layout {
>> \shrink Staff.PercentRepeat
>> \shrink Staff.RepeatSlash
>> \shrink Staff.DoubleRepeatSlash
>> }
>
>
> Thank you for this, David. It's a handy little shortcut.
It's actually several shortcuts playing relay without dropping the
baton.
--
David Kastrup
Re: RepeatSlash size is changed when StaffSymbol.staff-space is overriden in 2.24
Viktor Mastoridis writes:
> On Tue, 15 Aug 2023 at 10:59, Jean Abou Samra wrote:
>
>> Le mardi 15 août 2023 à 01:37 +0100, Viktor Mastoridis a écrit :
>> > The previous code (shrink =...) doesn't work for tabs...
>>
>>
>> It works here:
>
> Ah, it's TabStaff (not Staff), of course!
> \layout {
> \context {
> *\TabStaff...*
>
> Thank you so much for your help, Jean!
If you want to cover _all_ Staff-like contexts, you can do
\version "2.24.2"
shrink =
\propertyTweak stencil
#(grob-transformer 'stencil (lambda (grob orig) (ly:stencil-scale orig 0.7
0.7)))
\etc
\layout {
\shrink Staff.PercentRepeat
\shrink Staff.RepeatSlash
\shrink Staff.DoubleRepeatSlash
}
\new TabStaff \with {
stringTunings = #ukulele-tuning
}
\relative c {
\tabFullNotation
\repeat percent 2 { c'4 d e g}
\repeat percent 2 { c,16 d16 e8}
\repeat percent 2 { c8 d8}
}
--
David Kastrup
Re: Question about condensed score
Rip _Mus writes: > wow!! > Now I understand Knute's answer too. > Unfortunately, opening the page in the Italian version, the documentation > relating to the Keep_alive_together_engraver is not there. Its internals are documented, but its remove-layer settings are not really documented as a user-level feature. Part of the reason is that there should actually be a user-level layer of commands around the core settings, and _that_ should then get user-level documentation. But the skeleton of the feature can be made to walk without being fleshed out. > Thank you very much for the solution, thank you very much! Well, it is more embarrassing than anything. But occasionally I do catch questions for that functionality. -- David Kastrup
Re: Question about condensed score
Rip _Mus writes:
> Hello,
> please consider the following example:
>
> %%%
> \version "2.24.1"
>
> global = {
> s1\break
> s1\break
> s1
> }
>
> flOne = \relative c' {
> e1
> r1
> e1
> }
>
> flTwo = \relative c' {
> c1
> r1
> c1
> }
>
> \new StaffGroup \with { shortInstrumentName = "Fl. 1-2" } <<
> \new Staff \with {
> instrumentName = "Flute 1"
> shortInstrumentName = "Fl. 1"
> } <<\global \flOne>>
> \new Staff \with {
> instrumentName = "Flute 2"
> shortInstrumentName = "Fl. 2"
> } <<\global \flTwo>>
>>>
> %%%
>
> I would like to have a condensation at the second bar (that is at the
> second system, where both instruments have a rest), showing only one staff.
> Regarding the names of the staves, when the two flutes are split, I would
> like to show the single names, while during the condensation I would like
> to show the name of the staffGroup
Sounds somewhat like
%%%
\version "2.24.1"
global = {
s1\break
s1\break
s1
}
flOne = \relative c' {
e1
r1
e1
}
flTwo = \relative c' {
c1
r1
c1
}
\new StaffGroup \with { \consists "Keep_alive_together_engraver" }
<<
\new Staff \with {
\RemoveAllEmptyStaves
\override VerticalAxisGroup.remove-layer = 1
instrumentName = "Flute 1"
shortInstrumentName = "Fl. 1"
} <<\global \flOne>>
\new Staff \with {
\RemoveAllEmptyStaves
\override VerticalAxisGroup.remove-layer = 1
instrumentName = "Flute 2"
shortInstrumentName = "Fl. 2"
} <<\global \flTwo>>
\new Staff \with {
instrumentName = "Flutes"
shortInstrumentName = "Fl. 1-2"
\override VerticalAxisGroup.remove-layer = 2
} \partCombine \flOne \flTwo
>>
--
David Kastrup
Re: Question about condensed score
Rip _Mus writes: > Good morning everyone! > I would like to ask if you know a strategy to achieve the following result. > > I'm working on an orchestral score. I'd like the two flute staves to be > shown separate when they play, while condensed when both are silent > (perhaps with a staff name showing the indication "fl. 1-2"). > > Could you help me get this result? I am not going to compose a whole example. Please provide sufficient material for showcasing your problem. -- David Kastrup
Re: multiple transpositions
Stefan Thomas writes:
> Dear community,
> is it possible to transpose a sequence of notes with only one motif several
> times at once?
> I'have in mind something like this:
> motiv = { c'4 d' e' c' }
> \multitranspose d e fis gis \motiv
> % result: d'4 e' fis' d' e' fis' gis' e'e' fis' gis' e' gis'
> ais' bis' gis'
> Or maybee something like recursive transposition could be done?
> For example, as in the snippet above, a motif is to be transposed several
> times by a certain interval.
Try
multitranspose =
#(define-music-function (seq motiv) (ly:music? ly:music?)
(music-clone seq 'elements
(map (lambda (p) #{ \transpose c #(ly:music-property p 'pitch ) $motiv #})
(ly:music-property seq 'elements
motiv = { c'4 d' e' c' }
\multitranspose { d e fis gis } \motiv
--
David Kastrup
Re: Polyphonic piano writing - beam directions
Lukas-Fabian Moser writes:
> \new Staff = down \with { \clef bass } {
That sentiment was part of why I chose to switch from tenor to male alto
instead of bass. An easier change for sight-reading.
--
David Kastrup
Re: A query about tablature
Jean Abou Samra writes: > Le mardi 08 août 2023 à 19:53 +0200, Lukas-Fabian Moser a écrit : >> Yes, sure, that's what I did in my code for Alasdair. But I was more >> wondering whether or not RhythmicStaves (RhythmicStaff's?) should do >> this automatically. >> >> By the way, I didn't know about music-clone. What's its advantage over >> ly:music-deep-copy? > > As far as I understand the docstring, > > (music-clone mus 'elements new-elts) > > is more efficient than > > (let ((new-mus (ly:music-deep-copy mus))) > (ly:music-set-property! new-mus 'elements new-elts) > new-mus) > > because it will avoid deeply copying the elements list and > all its elements, by noticing that it will be overridden > by new-elts anyway. Given that ly:music-deep-copy is written in C++, I doubt better efficiency. > Without extra arguments, (music-clone m) should be strictly > equivalent to (ly:music-deep-copy m). The extra arguments are different, and, well, it is shorter to write. -- David Kastrup
Re: A query about tablature
Lukas-Fabian Moser writes:
> As a side remark: In order to put music into a RhythmicStaff, one
> doesn't even have to remove the pitches, they will just be
> ignored. But I noticed yesterday that LilyPond does not behave very
> well with chords in that situation:
>
> \version "2.24.0"
>
> mus = { c' d' 4. f'8 }
>
> <<
> \new RhythmicStaff \mus
> \new Staff \mus
>>>
>
> I'm not sure whether that should be called a bug: one would have to
> think a bit about the most natural way to deal with chords here.
\new RhythmicStaff #(event-chord-reduce (music-clone mus))
--
David Kastrup
Re: A query about tablature
Alasdair McAndrew writes: >> On Mon, 7 Aug 2023 at 00:11, David Kastrup wrote: >> >>> Alasdair McAndrew writes: >>> >>> > Thank you very much indeed for your offer. I'll try to put something >>> > together: currently my files are split up, so that all common >>> > definitions are in one file, all music in another, and the layout in a >>> > third file (which imports the others). I'll aim to make a simple >>> > representative file which includes the lot! >>> > >>> > But as I said earlier the music is split into two definitions: one >>> > contains the pitch information, and the other the rhythm. These are >>> > then put together as I described in my first post. >>> >>> Why? > > I'm not quite sure what the "why" refers to: It refers to splitting the music input into rhythm and pitch information rather than entering rhythm and pitch in concert as LilyPond is designed to do. > but I'm attempting to typeset some material from a 1607 publication, > which in the original has two tablature parts and one score part for > each piece. I'm aiming to do several things here: transcribe the > publication so that it's easy to read (so with tablature); create an > edition entirely in modern score; and also allow for playing by > instruments at different pitches. The title page announces that each > piece could be "plaied 8, severall waies upon sundry Instruments", and > so I'm trying to make that facility available to the modern player. > > Alasdair -- David Kastrup
Re: Need help displaying note names in 2.22
Silvain Dupertuis writes:
> Strange...
> I tried a few things, but did not find a way to make it work.
>
> I noticed 2 things :
>
> 1. In this association table :
> chimenames =
> #`(
> ("c" . "C")
> ("cis" . "C♯")
> ("d" . "D")
> ("es" . "E♭")
> )
> It only takes into account notes of names with one single character as
> the default-name, but it does print the new-note if it has more
> characters. I do not understand why...
Note names have changed to use ♯ and ♭ characters, so you need to look
up "c♯" instead of "cis".
> 2. In my version (2.24), I get a warning of a deprecated syntax for
> the expression
> {\override NoteName #'stencil = #ChimeNoteNames }
> saying it should be written with a dot notation
> {\override NoteName.#'stencil = #ChimeNoteNames }
> and the warning disappear with this notation
Ugh. Please just write NoteName.stencil here. This is 2.18+ syntax.
--
David Kastrup
Re: A query about tablature
Alasdair McAndrew writes: > Thank you very much indeed for your offer. I'll try to put something > together: currently my files are split up, so that all common > definitions are in one file, all music in another, and the layout in a > third file (which imports the others). I'll aim to make a simple > representative file which includes the lot! > > But as I said earlier the music is split into two definitions: one > contains the pitch information, and the other the rhythm. These are > then put together as I described in my first post. Why? -- David Kastrup
Re: Is there a Scheme macro(?) to use fretboards to generate a generic guitar strum?
Lukas-Fabian Moser writes: > Hi Kevin, > >> But right now, >> there's nothing other than constructing it by hand each time, for >> every chord. I think something would be better than nothing. > The problem has two parts: 1) Generate a sensible voicing for a given > chord; 2) create the arpeggio. (Maybe you intended to do 1) manually > anyway?) > > Here is a possible approach for 2) using LilyPond's (not ideal) > automatic voicings for 1): > > \version "2.24.0" > > arpeggiateChord = # > (define-music-function (chord) (ly:music?) Just a warning: inventing unconventional formattings like this (putting # on a different line as the opening paren) carries the danger of keeping convert-ly (and syntax highlighters and syntax-sensitive editors) from recognizing the construct. -- David Kastrup
Re: note collision - shift voiceOne to left
Carolyn Beeton writes: > I have read that section again and I am still a bit confused at what I > am seeing in this attempt at a MWE. In bar 2 the voiceTwo notes are > shifted right, but in bar 5 the voiceOne note, a dotted note, is being > shifted to the right. I have tried using the > Staff.NoteCollision.prefer-dotted-right override but that doesn’t seem > to help. In bar 7 there is a different construct with temporary > voices and there the shifting looks like what I want. I am trying to > get the dotted stemUp note in bar 5 to be shifted left. I am having trouble envisioning where you'd want the dot to go. Maybe LilyPond is having similar trouble? -- David Kastrup
Re: Are hyphens no longer required to prefix postevent tweaks?
Jean Abou Samra writes: > Le vendredi 21 juillet 2023 à 23:38 +0200, David Kastrup a écrit : >> > As of 2.25.6, the difference between the two forms of \tweak no longer >> > appears necessary: globally replacing thousands of "- \tweak ..." with >> > just "\tweak ..." now seems to work perfectly. >> >> Don't. > > > > If the syntax was changed, it seems a bit odd to advertise that the > new syntax shouldn't be used. The syntax hasn't changed. There is a crude fallback that catches common errors but you cannot depend on it outside of simple cases. -- David Kastrup
Re: Are hyphens no longer required to prefix postevent tweaks?
Trevor Bača writes:
> Are hyphens no longer required to prefix postevent tweaks?
They are still required.
> For years I've been writing a hyphen ...
>
> - \tweak color #red
> \startTextSpan
>
> ... to tweak text spanners but no hyphen ...
>
> \tweak color #red
> d'
> b'>4
>
> ... to tweak note heads.
>
> As of 2.25.6, the difference between the two forms of \tweak no longer
> appears necessary: globally replacing thousands of "- \tweak ..." with
> just "\tweak ..." now seems to work perfectly.
Don't.
> This change is really great! Trying to divine (and then remember)
> which of dozens of grobs are postevents (versus events?) was a
> pain. And the effort now appears no longer necessary.
Post events from music functions (like \tweak) are now accepted into
music lists (though not necessarily elsewhere). When a music list is
completed, there is a clean-up sweep attaching lone post events to the
preceding music. This may be too late and/or the preceding music may be
too complex to attach a post-event to it. Check for example
{
\magnifyMusic 2 c'2-\tweak color #red \p
\magnifyMusic 2 c'2 \tweak color #red \p
}
> Is the change intentional? I must have missed it in CHANGES,
It's a 2.22 change (2.21.0 actually). You are right that it doesn't
appear in "Changes" in 2.22. Part of the reason is that it is a patch
more intended to silence the user than LilyPond by attempting a "do what
I mean" on a superset of valid input with a reasonably straightforward
patchup attempt. The above at least gives off a warning. But if you,
for example, do
{
\displayLilyMusic c'2-\tweak color #red \p
\displayLilyMusic c'2 \tweak color #red \p
}
you get differing results and not even a warning. Overall, it is an
improvement, but relying on it is a bad idea.
> and the NR entry for \tweak
> <https://lilypond.org/doc/v2.25/Documentation/notation/the-tweak-command#index-_005ctweak-1>
> still shows ...
>
> \relative { c'-\tweak thickness #5 ( d e f) } % hyphen
>
> ... even though ...
>
> \relative { c' \tweak thickness #5 ( d e f) } % no hyphen
>
> ... works under 2.25.6.
As long as you cannot rely on it working outside of simple cases, it is
not a good idea to advertise it.
> Thanks so much for this!
If you want to check the discussion, this was issue 5181. It's a
Pyrrhic horse, really.
--
David Kastrup
Re: How to return markup conditionally?
Trevor Bača writes:
> %%% BEGIN %%%
>
> \version "2.25.6"
> \paper { indent = 0 tagline = ##f }
>
> \markuplist \column-lines {
> "TextSpanner.bound-details.text.left = \"red\" when spanner color is
> red;"
> "TextSpanner.bound-details.text.left = \"other\" when spanner color is
> not red:"
> " "
> }
>
> {
> \override TextSpanner.bound-details =
> #(grob-transformer
> 'bound-details
> (lambda (grob orig)
> (assoc-set! (alist-copy orig)
> 'left
> (assoc-set! (alist-copy (assoc-ref orig 'left))
> 'text
> (if (equal? red (ly:grob-property grob
> 'color))
> "red" "other")
> c'1
> - \tweak color #red
> \startTextSpan
> d'1
> e'1
> \stopTextSpan
> f'1
> - \tweak color #blue
> \startTextSpan
> g'1
> a'1
> \stopTextSpan
> }
>
> %%% END %%%
>
> But because successive calls to grob-transformer effectively overwrite
> earlier calls to grob-transformer, we can't use this pattern to (say)
> override bound-details.left.text and bound-details.left-broken.text at the
> same time:
Your analysis is wrong. Successive calls to grob-transformer work just
fine. Your problem is that successive \override incantations revert
previous incantations in the same context _unless_ you use \temporary
\override .
If you do your second grob-transformer invocation (or both) with a
\temporary \override, it will leave the first call in place. Of course
you'll need a double \revert then if you want to get rid of both calls.
--
David Kastrup
Re: How to return markup conditionally?
Jean Abou Samra writes: > Lol, now I understand. > > `module/language/cps/lower-primcalls.scm`: > > ``` > ;; precondition: pair is mutable pair > (define-primcall-lowerer (set-car! cps k src #f (pair val)) > (with-cps cps > (build-term > ($continue k src > ($primcall 'scm-set!/immediate '(pair . 0) (pair val)) > ``` > > > One of these lovely “optimizations” that the Guile developers are so > fond of. Frankly, one of the most annoying "optimisation" fights I had was with GCC's standard library because the then-head-honcho insisted on keeping "abort ()" marked as "no-return". Because it does not return. What it does, however, is create a core dump with a stack trace, and that stack trace is comparatively useless if the compiler gets to assume that the stack can be treated as outdated trash anyway. I debugged for half an eternity on a failed assertion because the failed assertion pinpointed a call site that was not actually being used other than some unrelated code jumping to its abort () call in order to save a byte of instruction. So why would one tell the compiler that it does not need to retain a useful stack when generating a stack trace? Because the option is not called "invalidate stack" but "no return". In contrast, I find the optimisation that assumes that constants will not be modified comparatively understandable. Without that assumption, you'll never be able to fold multiple constants. -- David Kastrup
Re: How to return markup conditionally?
Trevor Bača writes:
> Hi,
>
> I'd like the left text of red text spanners to be set to "foo", and to set
> the left text of all other text spanners to "bar".
>
> But I misunderstand how to return markup:
>
> %%% BEGIN %%%
>
> \version "2.25.3"
>
> % no left text set
> {
> \once \override TextSpanner.bound-details.left.text =
> #(lambda (grob) (if (equal? red (ly:grob-property grob 'color)) "foo"
> "bar"))
> c'1
> - \tweak color #red
> \startTextSpan
> c'1
> \stopTextSpan
> }
>
> % no left text set
> {
> \once \override TextSpanner.bound-details.left.text =
> #(lambda (grob) (if (equal? red (ly:grob-property grob 'color))
> (markup "foo")
> (markup "bar")))
> c'1
> - \tweak color #red
> \startTextSpan
> c'1
> \stopTextSpan
> }
>
> %%% END %%%
>
> What's the right way to return markup from a Scheme function?
You are doing fine in that regard, but subproperties don't have callback
evaluation.
--
David Kastrup
Re: Using functions "parenthesize" in lilypond 2.24.1
Виноградов Юрий writes: > 12:51, 11 июля 2023 г., David Kastrup : >> >> Please never, never, never, ever quote an entire week's digest to the >> list with any new post to the list. The entirety of your mail, >> including the last week's digest, will clog up the next week's digest. >> And so the digests will keep piling up. > > How will be correct. Tell. You don't quote what isn't relevant. It just clogs up the list unnecessarily. Since you did not refer to anything at all from the digest, you don't quote the digest _at_ _all_. Instead you write a _new_ message and send it to the list address. You don't "reply" to some old message, let alone a whole digest. -- David Kastrup
Re: Using functions "parenthesize" in lilypond 2.24.1
Виноградов Юрий writes: > Hello. I'm typing an accordion part. And in my left hand I need to put > a note in the \parenthesize function. But since this note takes up > space in the measure. Example: beat 2/4 and note 1/8 - it turns out to > be 5/8 in a beat. To make everything look good in the other hand, I > either put the size of 5/8 in this tact and add an invisible pause > (s8). Or I type in these bars with the \cadenzaOn function. Can you > tell me how to leave the measure in the normal 2/4 size and have this > note with the \parenthesize function not be counted in the measure. > > Thank you all in advance. Please never, never, never, ever quote an entire week's digest to the list with any new post to the list. The entirety of your mail, including the last week's digest, will clog up the next week's digest. And so the digests will keep piling up. -- David Kastrup
Re: Engraving a triple-stop for violin
Valentin Petzel writes: > Am Sonntag, 9. Juli 2023, 09:42:52 CEST schrieb David Kastrup: >> The latter is definitely the _natural_ way to enter this construct >> (single voice simultaneity) but I do seem to remember that LilyPond did >> not deal well with it? > > The thing is that if we combine Simultaneous Music with implicit context > creation Lilypond will create a context for each simultaneous music > expression. So doing No, there were also typesetting problems, like head attachments/dimensions for differently shaped heads, and consistent duration (and beaming) depending on head order. I don't remember the details but do remember that this did not generally work reliably. -- David Kastrup
Re: squeezing a page
Tom Sgouros writes:
> Hello all:
>
> I have a piece that spans seven printed pages, and I wish it was six. There
> are just four meagre measures on that last page and I wish I could persuade
> Lilypond to squeeze one more line onto the sixth page, as it did on the
> fifth page. I've looked at some of the vertical spacing controls, and so
> far my attempts to use them seem to make things look worse. Can anyone
> share some general tips for the order of things to try to do some gentle
> squeezing?
How about just telling LilyPond you want 6 pages?
\paper {
page-count = 6
}
--
David Kastrup
Re: Doubling a note makes MIDI output louder
Knute Snortum writes: > On Sun, Jul 9, 2023 at 6:57 AM wrote: > >> 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. >> > > 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. Frankly, a player who does not differentiate overlapping identical notes in momentarily converging voices from single notes is not doing the listener a favor. -- David Kastrup
Re: Doubling a note makes MIDI output louder
Michael Gerdau writes: > AFAICT the note is not played louder. However it is played twice and > then depending on your sound device that may or may not result in that > note being louder. When my sound device is a violin, I can testify that playing the same note simultaneously on two different strings makes the result louder than playing it on a single string. -- David Kastrup
Re: Engraving a triple-stop for violin
Valentin Petzel writes:
> Hello Pierre,
>
> I think this should rather be
>
> { <\tweak duration-log #2 g \tweak duration-log #2 e' e''>2^. }
>
> Alternatively one can simply do
>
> \new Voice << g4 e' e''2^. >>
>
> (the \new Voice is necessary as there has been no music before this, so there
> does not exist a voice, and Lilypond will then create one Voice for each
> parallel music).
The latter is definitely the _natural_ way to enter this construct
(single voice simultaneity) but I do seem to remember that LilyPond did
not deal well with it?
--
David Kastrup
Re: spacing
Werner LEMBERG writes: >> are you sure "theology" should go "the - ol - o - gy"? Shouln’t it >> be "The - o - lo - gy"? > > It depends on the hyphenation rules (i.e., either UK or US english). > Have a look at > > https://www.merriam-webster.com/dictionary/theology > > to see the former as used in the US. Hyphenation rules or not, for _singing_ purposes it tends to lead to better perfomances to put consonant groups at the start of the next syllable rather than the end of the current one. Admittedly this works better with non-English languages where vowels aren't pronounced in dozens of different ways depending on how a word completes. -- David Kastrup
Re: for-each?
Jean Abou Samra writes:
> Le lundi 03 juillet 2023 à 22:08 +0200, David Kastrup a écrit :
>> Ugh, that's a can of worms. #xxx will only accept a context-dependent
>> set of values and reject values not fitting the context. But the
>> context includes whether or not, for example, we are in lyrics mode.
>> For that reason \new ... accepts only a rather limited set of
>> expressions, mostly delimited expressions where the mode-switching
>> happens at the delimiters.
>>
>> So it's more the $... that is problematic, but $... always comes with a
>> warning tag with possibly untimely mode switching because of how parser
>> lookahead works.
>>
>> So all in all, I'm queasy about touching anything here. It's not like
>> you cannot just use one level of { } to get a context where #... will be
>> well-defined.
>
>
> On a related note, \new XXX is the only syntactic context I know
> where XXX = \xxx is accepted if xxx was defined with define-music-function,
> but not if it was defined with define-scheme-function, even if
> the function returns music.
Pretty sure there are more.
> I dunno whether that's expected, or improvable. At any rate, it is the
> only case where I am aware of an advantage of define-music-function
> over define-scheme-function.
>
> (And yes, I should really look into the parser code myself, but I
> don't have the time right now.)
If you want to work on consistency and reducing quirks like syntactic
define-xxx-function differentiation, "having the time" sort of requires
a sabbatical. Certainly beyond GSoC level.
--
David Kastrup
Re: for-each?
David Kastrup writes:
> Lukas-Fabian Moser writes:
>
>> Or maybe even:
>>
>> \version "2.25.6"
>>
>> parts = {
>> { c' }
>> { d' }
>> { e' }
>> { f' }
>> }
>>
>> group = #
>> (define-music-function (parts) (ly:music?)
>> #{
>> \new StaffGroup
>> $(make-music 'SimultaneousMusic parts)
>> #})
>>
>> \group \parts
>>
>> ? But I'm surprised (a bit) that I need $ here - the \new commands
>> still puzzle me sometimes.
>
> Huh. I would not have thought so either. Maybe worth looking at.
Ugh, that's a can of worms. #xxx will only accept a context-dependent
set of values and reject values not fitting the context. But the
context includes whether or not, for example, we are in lyrics mode.
For that reason \new ... accepts only a rather limited set of
expressions, mostly delimited expressions where the mode-switching
happens at the delimiters.
So it's more the $... that is problematic, but $... always comes with a
warning tag with possibly untimely mode switching because of how parser
lookahead works.
So all in all, I'm queasy about touching anything here. It's not like
you cannot just use one level of { } to get a context where #... will be
well-defined.
--
David Kastrup
Re: for-each?
Lukas-Fabian Moser writes:
> Or maybe even:
>
> \version "2.25.6"
>
> parts = {
> { c' }
> { d' }
> { e' }
> { f' }
> }
>
> group = #
> (define-music-function (parts) (ly:music?)
> #{
> \new StaffGroup
> $(make-music 'SimultaneousMusic parts)
> #})
>
> \group \parts
>
> ? But I'm surprised (a bit) that I need $ here - the \new commands
> still puzzle me sometimes.
Huh. I would not have thought so either. Maybe worth looking at.
I had been considering this approach, but it requires knowing the
magical word "SimultaneousMusic". Admittedly, my approach required
knowing the magical word "elements".
--
David Kastrup
Re: for-each?
Jean Abou Samra writes:
> Le dimanche 02 juillet 2023 à 15:05 -0400, Pierre-Luc Gauthier a écrit :
>
>> How can I go about using for-each in this example for the group function to
>> accept an arbitrary number of parts ?
>
>
> You can't — for-each is not the right tool for this. for-each is a purely
> imperative tool: it runs the same operation on each element of a list, and
> discards the result. What you actually want is called list splicing:
>
>
> ```
> \version "2.25.6"
>
> parts = #(list
> #{ {c'} #}
> #{ {d'} #}
> #{ {e'} #}
> #{ {f'} #} )
>
> group =
> #(define-music-function
> (parts) (list?)
> #{\new StaffGroup << #@parts >>#})
>
> \group \parts
> ```
That has an awkward look. I'd rather use
```
\version "2.25.6"
parts = {
{c'}
{d'}
{e'}
{f'}
}
group =
#(define-music-function
(parts) (ly:music?)
#{\new StaffGroup << #@(ly:music-property parts 'elements) >>#})
\group \parts
```
--
David Kastrup
Re: Music function to manage a moment and beat for the Staff and the Voice
Valentin Petzel writes: > Am Samstag, 1. Juli 2023, 18:48:31 CEST schrieb David Kastrup: >> The funny thing is that I suspect Han-Wen might still be surprised to >> hear what Staff.property "actually means". >> >> It's been around for quite longer than its "actual meaning". But of >> course I should be the last person to complain about my retconning >> making headcanon. > > Hello David, > > It is not my intention to confuse Han-Wen, when I say "actual meaning" > I mean it in the sense "how Lilypond handles this expression > internally", not "this is the official reading of this expression and > has been this way since the beginning". This wasn't a critique at all, more a musing about how the input syntax of LilyPond changed rather little compared to the changes of its _meaning_. Staff.property did not have any inherent meaning. It was part of the hardwired syntax of \set and \override (in the form of, say, \override Staff.TimeSignature #'stencil = ##f ) but there was no user-accessible representation of it outside of the commands. Music functions like \overrideProperty used syntax such as \overrideProperty NonMusicalPaperColumn which actually was equivalent to \overrideProperty #"NonMusicalPaperColumn" or \overrideProperty #"Score.NonMusicalPaperColumn" and picked apart their string argument, converting it into symbols. > I’m not even qualified to talk about such things becaus I have not > been around that long, my first version of Lilypond I used was 2.18, > and at that point I had absolutely no understanding of how Lilypond > works ... Well, my (admittedly badly made) point was that significantly before 2.18, there was not a lot to understand about the correspondence of LilyPond's input syntax and Scheme because the input syntax was ad-hoc. At that time, the Bison syntax diagram gave a pretty good impression about the content of a typical LilyPond input file. Nowadays, the vast majority of what was ad-hoc syntax at one point of time has become reflected by music functions and commands like \time are no longer to be found in the syntax. In 2.14, syntactic expressions in the parser were a large variety of different C++ types, so even in the syntax tree itself, partial productions might not have had a Scheme equivalent. Since 2.17.3, every syntax production in the parser is represented by a Scheme expression. But on the surface, LilyPond input syntax changed very little, so someone who _knows_ all of the old syntax (like Han-Wen who made up the majority of it) has less benefit from "understanding" it than comparable newcomers have. That's what I called "retconning": tweaking an existing "story" about LilyPond and Scheme in a manner that makes more sense than it was designed to start with, and see how it helps people understanding and teaching about LilyPond. Yes, I probably was being smug. It wasn't supposed to be at the expense of anyone. Sorry if it came across as such. -- David Kastrup
Re: Music function to manage a moment and beat for the Staff and the Voice
Valentin Petzel writes:
> Hello Vlad,
>
> in addition to Jean’s answer it might be helpful to understand what
>
> Staff.property
>
> actually means. This get’s parsed to a list of the symbols 'Staff and
> 'property. So you can in fact simply remain with scheme, and directly enter
> #(list scope 'property) like this
>
> %
> \version "2.24.1"
>
> momentBeat =
> #(define-music-function (scope moment beat) ((symbol? 'Staff) fraction? list?)
>#{
> \set #(list scope 'beamExceptions) = #'()
> \set #(list scope 'baseMoment) = #(ly:make-moment (/ (car moment) (cdr
> moment)))
> \set #(list scope 'beatStructure) = #beat
>#})
>
> {
> \momentBeat Voice 1/8 3,3,2
> c'8 8 8 8 8 8 8 8
> }
> %
>
> or if you enjoy abusing (quasi)quoting by doing #`(,scope property) like this
[...]
The funny thing is that I suspect Han-Wen might still be surprised to
hear what Staff.property "actually means".
It's been around for quite longer than its "actual meaning". But of
course I should be the last person to complain about my retconning
making headcanon.
--
David Kastrup
Re: overriding digit-names
Jean Abou Samra writes: > Le jeudi 29 juin 2023 à 17:56 +0200, David Kastrup a écrit : > >> No, none of the "standards" say anything like that. #(...) is a >> self-quoting form, like #t and #f and numbers and strings and some other >> things. Quoting them doesn't change a thing. >> >> And to be honest, I don't know of any _convention_ that would recommend >> explicitly quoting them or other self-quoting forms, either. > > > > R5RS 6.3.6 page 31 < > https://conservatory.scheme.org/schemers/Documents/Standards/R5RS/r5rs.pdf > > > Vectors are written using the notation #(obj ...). For > example, a vector of length 3 containing the number zero > in element 0, the list (2 2 2 2) in element 1, and the > string "Anna" in element 2 can be written as following: > > #(0 (2 2 2 2) "Anna") > > Note that this is the external representation of a vector, not > an expression evaluating to a vector. Like list constants, > vector constants must be quoted: > > '#(0 (2 2 2 2) "Anna") >⇒ #(0 (2 2 2 2) "Anna") Ok, but at the same time R5RS states: #( This introduces a vector constant (section *note Vectors::). Vector constants are terminated by ) . and it does not make sense to _evaluate_ something that is supposed to be the entry syntax for a constant. So this does not even make sense. I rescind the claim that no standard calls for explicit quoting and replace it with a "what were they even thinking here?" exclamation. > Of course, Guile has always implemented the R7RS-small behavior as an > extension to R5RS and R6RS. Are there any Scheme interpreters/versions that didn't at any point of time? Just curious. -- David Kastrup
Re: overriding digit-names
Jean Abou Samra writes: > Le mercredi 28 juin 2023 à 21:35 -0400, William Rehwinkel via LilyPond user > discussion a écrit : >> Dear John, >> >> You need to add another pound sign before the list. StrokeFinger.digit-names >> is a vector, with is a guile-specific construct not a standard list. > > > Just FYI in passing, vectors are standard Scheme just like lists. (However, > confusingly, some of the Scheme standards say #(...) should work while others > say you should quote them as '#(...) like lists.) No, none of the "standards" say anything like that. #(...) is a self-quoting form, like #t and #f and numbers and strings and some other things. Quoting them doesn't change a thing. And to be honest, I don't know of any _convention_ that would recommend explicitly quoting them or other self-quoting forms, either. -- David Kastrup
Re: Define an alias to a parametrized command
Simon Albrecht writes: > On 28.06.23 00:54, Valentin Petzel wrote: >> If you want a real alias (that is a second binding to the same function) you >> can do >> >> #(define acc acciaccatura) >> >> This will create another binding to the same object > AFAIK, > acc = #acciaccatura > and likewise > af = #after > will have the same effect. True. The actual value of \etc is when you want to supply some initial fixed arguments while keeping the rest variable. For just creating an alias taking the same number of arguments, the above way is at least conceptually simpler. -- David Kastrup
Re: Define an alias to a parametrized command
Leo Correia de Verdier writes:
>> 27 juni 2023 kl. 21:57 skrev Volodymyr Prokopyuk
>> :
>>
>> I'd like to define a shorter alias to a parametrized command. My two
>> specific use cases are
>> • Define \acc { c='8 d e } to be translated into \acciaccatura
>> { c='8 d e }
>> • Define \af 4. to be translated into \after 4.\!
>> I've tried the \set command, but it seems that the \set command does
>> not handle parameters. I have an intuitive understanding that this
>> type of aliases can be done with Scheme, but I do not know how
>> exactly.
> You can write:
> %
> acc = \acciaccatura \etc
> af = \after \etc
> %
>
> \set in lilypond is something completely else.
This definition of \af does not have the specified semantics. Instead
you need to write
af = #(define-music-function (dur mus) (ly:duration?) (ly:music?)
#{ \after #dur \! #mus #})
--
David Kastrup
Re: O Canada with Ukrainian lyrics
ericmcint...@mac.com writes: > This gets me SO much closer!! Thank you so very much Jean and the rest > of the Lilypond community. I have been at this for hours now and I > think I might even be getting the hang of it. > > I’ll work with someone who speaks Ukrainian to help split the words > properly for singing — this will be a real treat to be able to teach > these newcomers our anthem this weekend. In case "newcomers" does not directly mean "slated to be naturalised", you might be scoring a hit by also creating French/English versions of the Ukrainian anthem. Just a suggestion for possibly low-hanging fruit. -- David Kastrup
Re: Using \after 8 \turn with beamed notes when stem is up produces a turn under the beam
Kieren MacMillan writes: > Hi David, > >> whether the one-dimensional outside-staff-priority system >> is even well-suited for expressing the desired rules/constraints > > Are you able to say a little more about what you’re thinking there? > (The meaning I infer is that a two-dimensional system could allow for > a L/R priority, which is a long-standing feature wish of mine — > somewhere in the list archives are examples of me asking whether, > e.g., tempo markings and rehearsal marks could automatically “slide” > left or right instead of just up and down.) I was not thinking in spatial dimensions. Maybe "linear" or "well-ordered" would have been a better expression. The priority system essentially states the order of type X and type Y independent of whether a grob of type Z needs to be accommodated as well. -- David Kastrup
Re: Using \after 8 \turn with beamed notes when stem is up produces a turn under the beam
Jean Abou Samra writes:
> Le samedi 24 juin 2023 à 16:54 -0700, Knute Snortum a écrit :
>> Hi, community.
>>
>> I was using \after 8 \turn to produce a delayed turn with beamed eighth-notes
>> in voice one and the turn renders under the beam. Here is an MWE:
>>
>> \version "2.25.6"
>>
>> \relative e'' { \voiceOne e4 \after 8 \turn e8. f16 e2 }
>>
>> This doesn't seem correct, but I may have missed something.
>
>
> Not sure if it's really a bug, but try
>
> \version "2.25.6"
>
> \relative e'' { \voiceOne e4 \after 8 \tweak outside-staff-priority 0 \turn
> e8.
> f16 e2 }
Bad defaults can be a bug like bad code. Of course that begs the
questions of whether there are better defaults, or whether the
one-dimensional outside-staff-priority system is even well-suited for
expressing the desired rules/constraints.
--
David Kastrup
Re: Wanting to leave list
"Andy Bradford" writes: > Thus said David Kastrup on Sat, 17 Jun 2023 18:44:54 +0200: > >> Some mail clients may, for that reason, even have a dedicated >> "Unsubscribe" button. But you can always look in the headers. > > It's a shame that something like mailing list headers isn't made easy by > Gmail to Gmail's users. They seem pretty adamant in their crusade to > force everyone to use SPF and DKIM (without having giving their users a > voice in the matter), but won't help their users figure out how to use > mailing lists by giving them a nice easy button to use. Well, one should imagine that an "unsubscribe" button would rather help their cause... But it would probably break the pretense. -- David Kastrup
Re: Wanting to leave list
Christopher Bartlett writes: > Please forgive the intrusion, but as I've begun using MuseScore, I'd like > to leave this list, and cannot find the unsubscription directions. Like usual with mailing lists, looking at the full headers of every single mail gives you information like List-Unsubscribe: <https://lists.gnu.org/mailman/options/lilypond-user>, <mailto:lilypond-user-requ...@gnu.org?subject=unsubscribe> List-Archive: <https://lists.gnu.org/archive/html/lilypond-user> List-Post: <mailto:lilypond-user@gnu.org> List-Help: <mailto:lilypond-user-requ...@gnu.org?subject=help> List-Subscribe: <https://lists.gnu.org/mailman/listinfo/lilypond-user>, <mailto:lilypond-user-requ...@gnu.org?subject=subscribe> Some mail clients may, for that reason, even have a dedicated "Unsubscribe" button. But you can always look in the headers. -- David Kastrup
Re: Harp Pedal Spanners
Alexandre Loomis writes: > Your code is much more readable, but I'm not sure I understand the > difference between first and second take? If LilyPond finds that its first attempt of parsing a longer end up with post-events (those normally attached to a note or rest) in isolation, it makes a second attempt of attaching them to what happens to precede them. Sometimes (like in the \displayMusic example I gave) this comes too late to result in the "expected" reading. The differences end up more subtle, and while we had a number of complaints while this second pass has not been implemented, I don't remember anybody writing up an error report about the more subtle semantics when LilyPond now tries to clean up its parsing after the fact. -- David Kastrup
Re: Harp Pedal Spanners
Alexandre Loomis writes:
> Thanks, that was very helpful! Adding \tweak padding 1 to the original
> function and defining a continue function by
> nextPed =
> #(define-music-function (end-text) (markup?)
>#{
> \tweak bound-details.left.padding -3
> \startPed "" #end-text
>#})
> makes many cases work or almost work by default. It still requires some
> tweaking, but far less.
That looks like it could instead be defined as
nextPed = -\tweak bound-details.left.padding -3
\startPed "" \etc
Note that this creates an "event function" instead of a "music function"
since that is more appropriate for a \startTextSpan command which can
only be applied attached to some rhythmic event. That way you can write
c'\nextPed
instead of
c'-\nextPad
and have LilyPond recognize this in the first take (there has been a
"second take" around for a few version that obscurs the distinction, but
it will still show in the output of
\displayLilyMusic c'\nextPad
and similar constructs).
--
David Kastrup
Re: Error in scheme-sandbox, LilyPond 2.24.1
Knute Snortum writes:
> While going through Jean's Extending LilyPond tutorial...
>
> https://extending-lilypond.gitlab.io/en/scheme/expressions.html
>
> ...I came upon instructions to type this expression into the scheme-sandbox:
>
> (skip-of-length #{ { c'8 d' e' f' e' d' } #})
>
> However, it produced this error:
>
> $1 = # . #))((display-methods #) (name .
> SkipEvent) (iterator-ctor . # ly:rhythmic-music-iterator::constructor ()>) (types event rhythmic-event
> skip-event)) >
> ))((display-methods # # (expr)> # #
> # #) (name .
> EventChord) (iterator-ctor . # ly:event-chord-iterator::constructor ()>) (length-callback . # ly:music-sequence::event-chord-length-callback (_)>) (to-relative-callback
> . #)
> (types event-chord simultaneous-music)) >
>
> Is this a bug or something I have done?
It is not an error but the standard print-form of the resulting Music
expression. You might want to call displayMusic on it for a better
looking result.
--
David Kastrup
Re: chord.ly to extract notes from chords breaks with new Guile
msk...@ansuz.sooke.bc.ca writes:
> 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
Your way of "getting chord.ly from the 2015 discussion" is broken. To
wit, it contains a line
((null? res) (let ((note (list-ref notes (1- len ; last note
(make-music 'RestEvent 'duration (ly:music-property note
'duration
which contains a delirious number of unbreakable spaces, code \xa0
instead of \x20 as for a normal, breakable space.
Both Guile and LilyPond treat the unbreakable space as a normal
character instead of a space character. Please fix your input file to
stop containing unbreakable space characters and also make sure that the
comment
; last note
is not continued with unbreakable space characters into further code
which turns it into a no-show for Guile.
Once you fix your unbreakable space as well as missing linebreak after
comment problems, things will likely look more normal.
--
David Kastrup
Re: Using Variables
Johannes Roeßler writes:
> Hi Group,
>
> I try to define this:
>
> neo = {\once \override NoteHead.style = #'neomensural}
>
> but it leads to errors in the following parts (no error message
> regarding the variable definition though...)
>
> What am I doing wrong?
You are not posting your actual code and your actual error messages.
The above will fail because of a missing space after neomensural alone.
Please try to come up with a complete small example exhibiting your
problem.
--
David Kastrup
Re: How to unsubscribe?
"Samuel Sloniker" writes: > Hello! > > How can I unsubscribe from this list? Like with most bonafide mailing lists, looking at the full headers of any mail from the list will contain the necessary info for unsubscribing. -- David Kastrup
Re: How to tie into a bar with split voices
John McWilliam writes:
> I’m trying to get a tie to cross the barline into a split voice
> measure. I have tried with and without the \voiceOne command but
> cannot get this to work. Can any one help me?
First let's point out everything you get "cargo-cult" wrong, having it
resemble working constructs without actual being them. That does not in
itself solve your problem but may help you actually try out suggestions
and ideas.
LilyPond is a way of talking to a computer, and computers are masters at
not just playing but actually being dumb.
>f2.~ | % 3
>
>
> <<
> { %\voiceOne % Voice = "1"
> \stemUp
> f4 g8 a4 bes8 | % 4
> c2.~| % 5
> c4
> }
>
> \\
> { \new Voice
> \voiceTwo % Voice = "2"
> \stemDown
> r4 r8 f,4 f8| % 4
> a2.~| % 5
> a4
> }
>
>>>
So here is the beef. Someone may have told you that you must not create
new voices but rather only create a new voice for the non-tied part.
That's why you have "\new Voice" in the second bunch. But for one
thing, this doesn't help at all since
<< ... \\ ... >>
_will_ for every part inside separated by \\ create a new voice, whether
you want it or not. The only way to avoid this (outside of using
\voices trickery, see below) is not to write \\ at all.
Then "\new Voice" applies to the next music expression, meaning that you
usually form that expression writing "{ ... }". But your "\new Voice"
is followed by "\voiceTwo", meaning that the _only_ thing placed into a
new voice here is "\voiceTwo", making it affect nothing at all.
Presumably this is why you readded "\stemDown" after (presumably)
someone told you you should be using \voiceOne/\voiceTwo instead.
So more likely than not, every advice you got has been incorporated by
you in a manner that doesn't actually work. Which will appear to you
like you got bad advice that you needed to patch up in order to make it
at least do what you already thought you accomplished yourself.
That's frustrating both for you as well as your advisers, and hopefully
I got to make you a bit more acquainted to LilyPond's manner of thinking
such that you have better odds of successfully incorporating advice the
next time round.
Now here is how I would do things personally:
\version "2.24.0"
\score {
\relative c'' {
\clef "treble" \key f \major \time 6/8
c4 r8 f,4. | % 2
f2.~ | % 3
\voices "", 2
<<
{ \voiceOne % Voice = ""
f4 g8 a4 bes8| % 4
c2.~ | % 5
c4
\oneVoice
}
\\
{% Voice = "2"
r4 r8 f,4 f8| % 4
a2.~ | % 5
a4
}
>>
a8 a4 a8
} %end relative
} %end score
Note that I _do_ use << ... \\ ... >> here, but I apply the \voices
construct to it which tells it to use \context Voice = "" for the first
part (and no voice-specific settings which is why I have to follow up
with \voiceOne/\oneVoice) and \context Voice = "2" for the second (with
\voiceTwo specific settings).
If your top Voice is not anonymous but an actually named Voice, instead
of writing \voices "", 2 ... you'd need to write
\voices "MyVoiceName", 2 ... in order to get LilyPond to continue your
voice with the given name, in this case "MyVoiceName".
--
David Kastrup
Re: Alternative beginnings
John Burt writes:
> I know how to use \repeat volta to produce alternative endings. I'm trying
> to set a song in which the music for verses 2 and 3 is different from the
> music for verse 1. Is there something like \repeat volta for alternative
> beginnings?
Would
{ Verse 1
\repeat volta 3 { chorus
\alternative { { verse 2 }
{ verse 3 }
{ final bar } } } }
do the trick for you?
--
David Kastrup
Re: temporarily overriding paper variables
Jean Abou Samra writes: > Le mercredi 29 mars 2023 à 10:58 +, Werner LEMBERG a écrit : >> ``` >> >> >> Alas, it *still* doesn't work as expected. Obviously, I have >> >> simplified the code example too much: adding a `ChordNames` context >> >> prevents alignment. Note that the top skyline of the chord symbol >> >> doesn't show anything suspicious. >> > >> > Okay, then I think we are hitting something else. >> >> It seems so, yes. Jean, do you have an idea? Shall I submit an >> issue? > > I am not yet sure if this is a bug or not. I'd call it more of an inconsistency with regard to behavior of something for which (ly:stencil-empty ... #X) returns #t (namely vertical spacing). The behavior inside of markup itself is to space and pad the adjacent vertical elements as if the vertical spacing weren't there, then add the spacing. -- David Kastrup
Re: Bar check for lead in notes?
John Whitmore writes:
> I'm not even sure that I have the correct terminology for why I'm trying to
> achieve. I've been trying to find info in the bar sections but so far
> haven't found what I'm looking for.
>
> I'm trying to write out a tune whose first bar is incomplete, whilst the
> piece is in 4/4 the first bar only contains a triplet:
>
> \tuplet 3/2 { a'8 b' cs'' } |
>
> There are no rests in the bar it's just that triplet, which would be
> equivalent to a 1/4 note, I think. So that bar is only a quarter the length
> that it should be for the bar check.
>
> The last bar of the piece is the mirror of that first bar and is only 3/4
> full:
>
> fs''8 g'' fs'' e'' d''8 r8 |
>
> Unfortunately the above will fail the first bar check and then rearrange
> all the bars to move the bar breaks making that first bar a complete bar.
>
> I've tried to remove all the bar checks from the piece and manually add the
> bars with '\bar "|"' But that gives me my manual bars plus where lilypond
> thinks the bars should go.
>
> \tuplet 3/2 { a'8 b' cs'' } \bar "|"
> d''4 fs''8 d'' g'' e'' fs'' e'' \bar "|"
>
> I end up with alternating bars which are 1/4 full and 3/4 full the whole
> way through the piece.
>
> Probably missed the section of the manual which I need for this. Any
> direction would be gratefully received.
<https://lilypond.org/doc/v2.24/Documentation/notation/displaying-rhythms#upbeats>
--
David Kastrup
Re: temporarily overriding paper variables
Werner LEMBERG writes:
>>> I tried
>>>
>>> ```
>>> \markup \with-dimensions #empty-interval #empty-interval {
>>> ... }
>>> ```
>>>
>>> and the padding to the next score gets still applied. I suspect
>>> that the 'empty interval' trick only works for stuff within a score
>>> but not on the top level.
>>
>> I'd be tempted to call that a bug: it runs contrary to the idea of
>> "only spacing" in markup. Of course, having implemented that
>> concept myself, you could consider me to blame, and also there would
>> be the question of just how to position a watermark when the spacing
>> specific to its own kind of vertical element is not being applied.
>> Probably just next to the preceding element.
>
> It would be cool if this worked some day. However, the next best
> thing would probably be to allow negative widths and heights for
> `\markup` boxes (if set with `\with-dimensions` and friends).
\vspace/\hspace can go backwards.
--
David Kastrup
Re: temporarily overriding paper variables
Werner LEMBERG writes:
>>>> If you don't want vertical padding, your horizontal dimensions
>>>> must be an empty interval, not a point interval.
>>>
>>> OK, but how do I do that for `\markup`?
>>
>> Maybe this: \markup \with-dimension #X #empty-interval ...
>>
>> (Assumes you are using 2.24 that supports the axis-specific
>> command.)
>
> Nope, doesn't work: I tried
>
> ```
> \markup \with-dimensions #empty-interval #empty-interval {
> ... }
> ```
>
> and the padding to the next score gets still applied. I suspect that
> the 'empty interval' trick only works for stuff within a score but not
> on the top level.
I'd be tempted to call that a bug: it runs contrary to the idea of "only
spacing" in markup. Of course, having implemented that concept myself,
you could consider me to blame, and also there would be the question of
just how to position a watermark when the spacing specific to its own
kind of vertical element is not being applied. Probably just next to
the preceding element.
--
David Kastrup
Re: temporarily overriding paper variables
Werner LEMBERG writes:
> OK, thanks.
>
>> However, you should be able to get your desired output using a
>> `\vspace` in the markup.
>
> Nope, this doesn't work, AFAICS. I have a paper setting
>
> ```
> \once \set markup-system-spacing.padding = 2.5
> ```
>
> and my code uses
>
> ```
> \markup \with-dimensions #'(0 . 0) #'(0 . 0) {
> ...
> }
>
> \score { ... }
> ```
>
> and there is apparently no way to make the markup really
> 'transparent', i.e., taking zero vertical space. The padding between
> markup and system is always inserted, and I wasn't able to find a
> solution to give the markup a 'negative height'.
If you don't want vertical padding, your horizontal dimensions must be
an empty interval, not a point interval.
--
David Kastrup
Re: Coda/Segno sign color override not working: LiliyPond 2.24.0
Jean Abou Samra writes:
> convert-ly only does text substitutions based on patterns that are
> likely to be old syntax that needs to be converted. It cannot
> understand the logic behind Scheme code. In this snippet, it can't
> determine that what is being looked up in the alist is an
> `articulation-type` value. (And it's not a lack of programming
> resources but a theoretical impossibility,
> cf.
> [https://en.wikipedia.org/wiki/Rice%27s_theorem](https://en.wikipedia.org/wiki/Rice%27s_theorem).)
> Therefore, it is to be expected that Scheme code can require manual
> conversion.
convert-ly uses heuristics. There is no point in talking about
"theoretical impossibilities" because convert-ly does not claim to be
doing a 100% job.
But that's no excuse for not trying to do a 90% job instead of a 0% job.
Patterns like
("flageolet" .
(acons "flageolet"
(assoc "flageolet"
have some chance at being candidates for conversion. How bad is the
chance for false positives? Considering all articulation types,
probably non-trivial. And false positives probably weigh heavier than
false negatives concerning conversion. So it may make sense to look for
those patterns only in expressions that also talk about
articulation-type or its associated data structures.
--
David Kastrup
Re: v2.25.2: D.S. al Coda
Jean Abou Samra writes: > Le mercredi 22 mars 2023 à 22:19 -0700, Paul Scott a écrit : > > >> D.S. followed by a segno sign is actually redundant since the S. stands >> for segno. > > > “Segno“ means “sign”. “Dal segno 턋” is not redundant, it just means > “go back to the sign 턋”. “Dal segno” means “go back to the sign”, > where which sign is being referred to is left implicit. This distinction becomes relevant if there are multiple dal segnos in one piece. I think I need to dig through my scores for a particularly brain-wrecking mixture of multiple dal segnos I remember. It would be interesting to see how much we are still lacking to represent that particular monstrosity (I don't think I have figured out with confidence how to actually play it as a human, either) to LilyPond. -- David Kastrup
Re: Benefits of Cairo backend over Ghostscript for PDF
Valentin Petzel writes: > Am Sonntag, 19. März 2023, 11:40:49 CET schrieb David Kastrup: >> The political system in the U.S. considers bribes by lobbyists a First >> Amendment protected variant of free speech. > > This deserves to be printed on calendars, t-shirts and mugs ... I have my own opion what this deserves to be... At any rate: any large-scale system converges to the loopholes without constant supervision, whether you are talking humans with religions and laws and morals, or rats and pest control, or antibiotic-resistant bacteria. -- David Kastrup
Re: Benefits of Cairo backend over Ghostscript for PDF
Andrew Bernard writes: >> On 18/03/2023 11:44 pm, Werner LEMBERG wrote: >>>> Hi Werner, With NBN in Australia, the speeds are amazing. [...] >>> Well, a great percentage of the world does not have such amazing >>> circumstances... > > Well as I said, I don't know. I thought America would be way ahead. The political system in the U.S. considers bribes by lobbyists a First Amendment protected variant of free speech. As a consequence, cable companies receiving government subsidies for implementing broadband coverage save a lot of money if instead of increasing broadband coverage they bribe the politicians responsible for implementing oversight or at least ensuring there is a reasonable chance for competitors to get access to the market. The FCC government agency responsible for regulating cable companies has currently spent more than a year headless, with lobbyists sabotaging an appointment for the leadership position after the last one had left. Sometimes it is not sufficient to be good at developing technology... -- David Kastrup
Re: Benefits of Cairo backend over Ghostscript for PDF
Paul Hodges writes: > From: Andrew Bernard > > In this day of gigabyte this an terabyte that, does a large PDF matter > very much? What is the issue of concern? > > Unnecessary waste of resources is always a poor idea, especially if it > is unexplained. > > > > My concern is more wondering that if the ordinary PDF is of the > required quality (defined how?), what is being changed to increase its > size so much? Different mostly redundant font subsets for thousands of images add up. -- David Kastrup
Re: LilyPond talk in German at Chemnitzer Linuxtage
Valentin Petzel writes: >> Am Sonntag, 12. März 2023, 13:24:01 CET schrieb: >>> Valentin Petzel writes: >>> > Regarding midi support: Personally I’d do this externally. Create an >>> > external program that records midi, either quantised real time or >>> > stepwise, and returns the output as Lilypond code. This then has the >>> > advantage that it is easier to maintain and can easily be used by >>> > whatever editor you want to use (as long as the editor in question >>> > allows you to call an external program and insert the output). >>> >>> An advantage of doing this in-editor is that you can reincorporate >>> manual duration corrections and bar checks into the quantisation. That >>> might significantly speed up the process of getting a good quantisation. >>> >>> Of course, Frescobaldi does not use timing at all yet, so that is a moot >>> point for now. > > > Yes, but an external program could do that too, without being tied to a > single > specific editor. How do you propose an external program to incorporate edits without being an editor? -- David Kastrup
Re: LilyPond talk in German at Chemnitzer Linuxtage
Valentin Petzel writes: > Regarding midi support: Personally I’d do this externally. Create an > external program that records midi, either quantised real time or > stepwise, and returns the output as Lilypond code. This then has the > advantage that it is easier to maintain and can easily be used by > whatever editor you want to use (as long as the editor in question > allows you to call an external program and insert the output). An advantage of doing this in-editor is that you can reincorporate manual duration corrections and bar checks into the quantisation. That might significantly speed up the process of getting a good quantisation. Of course, Frescobaldi does not use timing at all yet, so that is a moot point for now. -- David Kastrup
Re: LilyPond talk in German at Chemnitzer Linuxtage
Valentin Petzel writes: > Hi David, > > one important thing this talk has taught us is that you are not too > fluent with Frescobaldi :). You bet. But I still considered it a saner choice to showcase compared to Emacs (which is what I use). Maybe someone™ should just use all of the libraries Frescobaldi uses for parsing LilyPond stuff to bootstrap a first Emacs mode worth its salt. I also discovered that the Frescobaldi documentation talks about Rumor integration while in the actual editor Rumor support appears to have been replaced by native MIDI support with less functionality. The native MIDI support would require recording of timing information to facilitate better chord/note distinction and quantisation support. -- David Kastrup
Re: LilyPond talk in German at Chemnitzer Linuxtage
Aaron Hill writes: > On 2023-03-11 3:55 am, David Kastrup wrote: >> Hi, >> just a heads-up for a talk about LilyPond happening at 5pm MET >> (UTC+1). >> It's being streamed (and there will be a recording available a few >> weeks >> later). >> Essentially I will talk a bit about what LilyPond is and how to use >> it >> and will demonstrate Frescobaldi for entering a piece. If I am fast >> enough, also showing how to use MIDI. >> And, uh. Accommodation and transport (it's in Saxonia, deep East of >> Germany) do cut into my rather small pockets, so if you feel like >> offsetting this, there is a Paypal account associated with my Email >> address... >> Hope the streaming works out, and maybe see you later! > > Well, the three years of German I *barely* passed in high school will > not be enough for me to follow real, fluent speech without a written > transcript. So while I will not be able to join, I do hope everything > goes smoothly with your presentation. Thanks for those of you who actually did pick up my tab here with Paypal! I'll try adding an English sub once the recordings are available for download, as a "thank you" for the largest chunk of help. It probably helps that almost every time I do a talk in German, I forget to switch my locale to German, so the whole Frescobaldi interface is already in English in that talk... -- David Kastrup
Re: LilyPond talk in German at Chemnitzer Linuxtage
Jean Abou Samra writes: > Le samedi 11 mars 2023 à 12:55 +0100, David Kastrup a écrit : > > >> Hi, >> >> just a heads-up for a talk about LilyPond happening at 5pm MET (UTC+1). >> >> It's being streamed (and there will be a recording available a few weeks >> later). > > For those wondering, the link to the streaming appears to be “Zum > Stream” on > https://chemnitzer.linux-tage.de/2023/en/programm/beitrag/281 D'oh. I had the page open in my browser for referencing it. I just forgot to actually do so. Thanks! -- David Kastrup
LilyPond talk in German at Chemnitzer Linuxtage
Hi, just a heads-up for a talk about LilyPond happening at 5pm MET (UTC+1). It's being streamed (and there will be a recording available a few weeks later). Essentially I will talk a bit about what LilyPond is and how to use it and will demonstrate Frescobaldi for entering a piece. If I am fast enough, also showing how to use MIDI. And, uh. Accommodation and transport (it's in Saxonia, deep East of Germany) do cut into my rather small pockets, so if you feel like offsetting this, there is a Paypal account associated with my Email address... Hope the streaming works out, and maybe see you later! -- David Kastrup
Re: Discourse proposal status
Andrew Bernard writes: > Well you can dynamically increase CPU or RAM or both on Digitalocean > that I use. You can do it on a temporary basis - but I'm not sure if > you get charged for a month or on a strict time basis, it's hard to > find out!. It's not a matter of needing a separate system. My only > issue is that I am very financially constrained and I can't afford the > experiment. You could experiment with adding enough swap space to import if you are charged based on a fixed configuration rather than processing time. It may take tremendous amounts of time, depending on how non-local the memory accesses occur. -- David Kastrup
Re: Discourse proposal status
Andrew Bernard writes: > Well you can dynamically increase CPU or RAM or both on Digitalocean > that I use. You can do it on a temporary basis - but I'm not sure if > you get charged for a month or on a strict time basis, it's hard to > find out!. It's not a matter of needing a separate system. My only > issue is that I am very financially constrained and I can't afford the > experiment. > > But the bigger fish to fry is the issue with the irregularities in the > mbox archives. I need to study this in depth before trying a load. I > did have the same problem with similar erratic mbox archives quite > some years ago but I can't easily recall the solution. Probably just a > more refined regex to pick up the 'From:' delimiters. There isn't really much finesse involved. Messages start at the pattern "^From ". Any "From " inside of a message that would end up at the start of a line is changed to ">From ", so the pattern "^From " should be foolproof regarding splitting into messages. I don't remember what happens to "^>From " but consider it most likely that any "^>*From " inside of a message gets one ">" prepended when put into an mbox file, and one taken out again when displayed/processed. -- David Kastrup
Re: Discourse proposal status
Andrew Bernard writes: > I should add that a normal fresh install does not require large > RAM. It's only the mbox import script. I think it's poorly written and > does not constrain itself when it comes to memory. Is it necessary to run the import on the same machine that is going to run the server? -- David Kastrup
Re: Message size limit
Andrew Bernard writes: > Hello All, > > I can't help feeling a twinge of schadenfreude on hearing this. :-) > > Although one can impose such restrictions in Discourse, you don't have > to unless you are constrained by organisational problems as here with > GNU. Do you really think that the number of mailing lists supported by the GNU mailing list server could be supported on the same hardware by the same number of Discourse forums? I don't really see how "schadenfreude" scales to the problem space. -- David Kastrup
Re: Definition of repeats using segno and coda
Volodymyr Prokopyuk writes:
> Hi Jean,
>
> I've produced the minimal example reflecting my real use case. This example
> does not produce the desired result. The difference between the minimal
> working example and my real use case is that both section A and section B
> are \repeat volta 2 themselves. In this situation the minimal working
> example from above stops working.
>
>
> *Minimal example that does not produce the desired result*
>
> \version "2.24.0"
>
> \relative {
> \clef treble
> \key c \major
> \time 4/4
> \repeat segno 2 {
> \repeat volta 2 { a'1 1 1 1 }
> \alternative {
> \volta 1 {
> \repeat volta 2 { b1 1 1 1 }
> }
> \volta 2 { \section \sectionLabel "Coda" }
> }
> }
> c1 1 1 1
> }
Well, the old syntax compatibility sets in, drawing \alternative to the
inner \repeat volta. You could put { } before \alternative to block
that.
--
David Kastrup
Re: Discourse
Werner LEMBERG writes: > Andrew, > > > thanks for your long reponse. I have to correct two of your > statements: > >> But (contrary to a false statement I made about import into >> Discourse) you can't import mailbox format lists into Discourse >> simply, because, for example, the creation of users from 25 years >> ago who most probably no longer have the same email addresses is >> very problematic for various reasons. > > It's really a pity that such a conversion is not supported, since it > would be extremely helpful in the long run. However, e-mail addresses > shouldn't be exposed in the web interface (the already existing e-mail > list archive doesn't do that either). The construction of threads > rather relies on the 'In-Reply-To:' and 'References:' fields, AFAIK. All months in the archive are downloadable in mbox format, of course containing all the Email addresses. I don't think this would escape the notice of scraping tools though there may be some limits braking bulk downloads. >> Maybe the history of bugs from ten versions ago is not that >> important to have instantly online. > > It's not the 'history of bugs' that counts – we have a bug tracker for > that. It's rather the collected wisdom of tips and tricks, mainly > related to Scheme wizardry, that is so important to look up for both > users and developers. The indexing is lacklustre, to say the least. Nevertheless, I am occasionally surprised by people being able to find past utterings of mine to rub my nose in. -- David Kastrup
Re: Discourse
David Santamauro writes: > Since we’re airing grievances … > > The format of the response below is exactly what bothers me most about > email lists and why I favor forums. The etiquette is to quote what you > are responding to and remove everything else. Imagine 4 other people > quoted different parts of the original email, I now have 5 disjointed > emails going off, perhaps, in 4 different directions. With a forum, > topics can be split and merged retaining all parts of OP’s initial > post/email and I can ignore the tangents I’m not interested in. That seems more like a deficiency of your mail client than of the principle of mail. Mails include reference headers used for threading, and my mail reader (news) arranges mails just like it does nntp (Usenet et al) postings. > Secondly, a forum only notifies you when you are part of a thread > (either started or replied to one) which reduces the email traffic > tremendously. You aren’t poked with an email every time someone has a > thought or issue, rather, you instantiate the interaction with the > forum. Yes, I know digest option is available, but really, who wants > to wade through an entire month’s worth of emails in one shot. Again, this points more to a deficiency of your mail client than anything else. Automatically sorting list mail into corresponding folders should be easy enough. To be fair, I usually read the LilyPond lists via Gmane's nntp mirror. > Thirdly, from a practical workflow perspective, I would much rather > scroll through a thread that is on one page than to click n-number of > emails. Of course, having to click into multiple emails is due in > large part to my first point. > > … and I’ll probably get yelled at for top-posting as well ;-) >From a practical workflow perspective, I would much rather do all of my reading using a single keyboard driven interface and application than have to keep hopping through all-different web interfaces for everything I am interested in. -- David Kastrup
Re: Policy for posts from non-members
Jeff Kopmanis writes: > I'm with you, Kevin. "mass abandonment of critical thinking skills and > common sense", is right on target. > > I'm an IT professional, and I can completely sympathize and appreciate > all that Jean deals with. Thank You, ALL, for your largely thankless > efforts. You provide such a valuable service to the Lilypond > community in support of a very powerful and somewhat complex piece of > software. Think how much something of this quality would cost in a > commercial setting?! > > I think it'd be perfectly acceptable to auto-reply to non-members with > a polite "Subscribe to post to this list" type of message. If you > can't take the time to become a member of a list/community, then there > should be no expectation that the community will take the time to > respond to the request. I don't think that the LilyPond user base is of a size where elitist thinking is providing a good basis for keeping the user-poweruser-developer-magician pyramid stable. -- David Kastrup
Re: Policy for posts from non-members
Kevin Cole writes: > On Tue, Feb 21, 2023 at 6:21 PM Andrew Bernard > wrote: > >> Dear me, mailing lists have been around for half as century or more. If >> people do not understand that it is normal to subscribe to a list to >> participate there's something wrong. > > This was my reaction as well. I think I'm finally "old", as I > increasingly feel that society as a whole is encouraging and abetting > mass abandonment of critical thinking skills and common sense, and the > shortening of attention spans. To me it's one of efficiency to use one medium instead of a flurry of different websites with different interfaces. -- David Kastrup
Re: Policy for posts from non-members
Jean Abou Samra writes: > Hi, > > I've not been an admin of this list for very long, yet I'm already > weary of telling people who post without being subscribed to the list > that they should subscribe in order to avoid each of their messages > being manually approved. Maybe it's possible to prepare a stock message that you just need to checkmark? That would go a long way towards being less weary. A different tradeoff. -- David Kastrup
Re: I did not previously realize that Lilypond would automatically update pre-existing scores
Werner LEMBERG writes: >> What is expected to happen when Lilypond 2.24.1 encounters a score >> with a version of 2.22.2 in it? Well, I'll try to carefully reproduce >> (or not!) my experience! > > It prints a thick fat warning that the LilyPond version is too old to > handle this score. It proceeds, but it returns an non-zero error > code as a sign of protest :-) No, it doesn't. The warning and error is reserved for the case where the file requests a newer version than LilyPond provides, not the other way round. -- David Kastrup
Re: Moving breath mark horizontally
Michael Werner writes:
> Hi Joei.
>
> Checking the Internals Reference (
> http://lilypond.org/doc/v2.25/Documentation/internals/breathingsign )
> there's an alist for the BreathingSign that contains spacing. Looks like
> the next-note one is what you might be looking for. I gave it a whirl here
> with these results:
>
> music = \relative c'' {
> c c \breathe c c \break
> c c \once \override BreathingSign.space-alist = #'((next-note fixed-space
> . -3)
> (right-edge
> extra-space . 0.1)) \breathe c c
> }
>
> producing:
>
> [image: image.png]
>
> Is that kinda what you were looking to do?
>
> For some reason Lilypond complained if I left out the right-edge
> entry.
It is not that you left out the right-edge entry, it is that you removed
it. The way you have written your override, it removes all of
space-alist and only leaves the entries you state explicitly.
Instead, try overriding just the entry
BreathingSign.space-alist.next-note (and I prefer using a \tweak here)
such as
\relative c'' {
c c \breathe c c \break
c c
\tweak space-alist.next-note #'(fixed-space . -3) \breathe c c
}
--
David Kastrup
Re: `\afterGrace` and clef problem
Jean Abou Samra writes: > Le lundi 13 février 2023 à 18:08 +0100, David Kastrup a écrit : >> That begs the question whether it would make sense to restrict >> afterGrace scales to values below 1. But I think that making syntactic >> decisions based on values rather than types is really icky. It is >> probably a bad idea to make syntactic decisions that one would not >> expect a syntax highlighter to be able to figure out. > > > You are being self-consistent. > > [https://gitlab.com/lilypond/lilypond/-/merge_requests/951#note_696966050](https://gitlab.com/lilypond/lilypond/-/merge_requests/951#note_696966050) The worst in that respect on my conscience I remember right now is the difference between (ly:make-moment 1 1) and (ly:make-moment 1 -1) -- David Kastrup
Re: `\afterGrace` and clef problem
Lukas-Fabian Moser writes:
> Hi Werner,
>
>>> Alternatively you may try to use \afterGrace to insert the \clef
>>> before the bar line, although this would probably require some
>>> manual spacing too.
>> This doesn't work at all: `\afterGrace` doesn't accept a clef, as the
>> image shows.
>
> afterGrace is defined as
>
> #(define-music-function (fraction main grace) ((scale?) ly:music?
> ly:music?) ...)
>
> You write
>
> \afterGrace 1 { s8 \clef "bass" } | c,1
>
> but 1 is a valid scale? because of
>
> (define-public (scale? x)
> (or (and (rational? x) (exact? x) (not (negative? x)))
> (fraction? x)
> (and (ly:moment? x) (scale? (ly:moment-main x)
>
> in scm/c++.scm.
That begs the question whether it would make sense to restrict
afterGrace scales to values below 1. But I think that making syntactic
decisions based on values rather than types is really icky. It is
probably a bad idea to make syntactic decisions that one would not
expect a syntax highlighter to be able to figure out.
--
David Kastrup
Re: Slur below triplet spanner
Johannes Roeßler writes:
> Hi Group,
>
> I've got notes with a slur within a triplet and want to have the spanner and
> the slur above
> the notes, but the slur below the spanner.
>
> \tuplet 3/2 { b4(f) g }
>
> *
>
> How can I change the priority?
\new Staff \with
{ \override TupletBracket.outside-staff-priority = 100 }
\fixed c' { \tuplet 3/2 { b4(f) g } }
Don't ask me what's up with the vertical spacing.
--
David Kastrup
Re: Starting Piano music with acciaccatura on upper voice
Alberto Simões writes:
> Hi
>
> I am starting a piano music this way:
>
> upper = \relative c'' {
> \clef treble
> \key g \major
> \time 4/4
>
> \acciaccatura ais8 b8.
> }
>
> and the lower voice as
>
> lower = \relative c {
> \clef bass
> \key g \major
> \time 4/4
> fis8
> }
>
> but the lower staff starts with a treble clef followed by the bass clef
> with the key signature.
> This is quite weird
>
> What am I doing wrong?
> Thanks
<https://lilypond.org/doc/v2.24/Documentation/notation/special-rhythmic-concerns#index-grace-note_002c-synchronization>
--
David Kastrup
Re: Visible Barline in ChoirStaff
Leo Correia de Verdier writes:
> Your example doesn’t work because the bars between the staves are in fact not
> BarLine grobs, but SpanBar grobs, and they would live in the ChoirStaff
> context.
> The difference between a ChoirStaff and a StaffGroup is that the Choirstaff
> doesn’t contain the Span_Bar_Engraver, that creates them. You would need to
> include the engraver in the ChoirStaff (essentially making it a StaffGroup),
> \omit the SpanBars you don’t need (all the others) and make just the one you
> need visible, like:
>
>
> \new ChoirStaff \with {
> \consists Span_bar_engraver
> \omit SpanBar }
> <<
> \new Staff {
> c''1 b'
> \once \revert ChoirStaff.SpanBar.stencil
Probably nicer written as
\once \undo \omit ChoirStaff.SpanBar
because that does not require you to know what grob property is affected
by \omit .
> a' }
> \new Staff {
> \clef bass
> a1 g f }
>>>
>
>
>> 8 feb. 2023 kl. 16:12 skrev Johannes Roeßler :
>>
>> Hi Group,
>>
>> how can I add a visible (in the sense of connecting all staffs)
>> barline in a choirstaff?
>>
>> I tried \once \override Staff.BarLine.transparent = ##f \bar "|"
>>
>> but o course it doesn't work, for its just in a staff...
>>
>> Best regards
>> Johannes
>>
>>
>
>
>
--
David Kastrup
Re: rall. autocalculation function in Scheme
"Adam M. Griggs" writes: > Thank you David. Your code is well above my level for now, but it'll > be great study material. Is it for 2.25.x? I haven't quite got it > working yet, but that's probably my fault. No, it has worked for at least a year or so here. Probably the usage example is less than clear since it works with \keepWithTag for differentiating between layout and midi use. -- David Kastrup
