Re: top-level markup in Scheme
Werner LEMBERG writes: > What is the Scheme equivalent to a top-level markup like > > ``` > \markup \italic "foo" > ``` > > ? I can't find it in the documentation. \void \displayScheme \markup \italic "foo" outputs (markup #:italic "foo") I am not a fan of the markup macro, but of course (make-italic-markup "foo") will also work. It is not clear what you mean with "top-level" however. Of course at the top level of a LilyPond document, markup gets interpreted by calling an appropriate hook. -- David Kastrup
Re: openlilylib pull request
Simon Albrecht writes: > On 08/05/2022 20:37, Jean Abou Samra wrote: >> The case study of how OLL fell out of maintenance is one of the >> things leading me to think that a model where snippets providing >> significant functionality and becoming somewhat popular get >> upstreamed into the LilyPond core is a better fit for LilyPond >> than them letting them be provided through external packages. > > > In many cases, that may be true. In other cases, it really makes sense > to allow for a more flexible space of user code available to the > community. > > The TeX ecosystem may have some issues with maintaining packages and > especially with interoperability, but it provides an unbelievable > wealth of high-quality additions to the core software that could never > be provided otherwise. Due to the relative lack of adoption and the > small size of the community LilyPond can’t seem to take some threshold > toward creating a similarly stable ecosystem (so far?). The "TeX ecosystem" consists of plain TeX with fudge-ons (comparable to LilyPond and LSR snippets), of the monolithic Context (driven by a not-much-more-than-one-man company), and of the modular LaTeX. The only system that has exploded in number and functionality of extensions and styles is LaTeX. That suggests that the development potential is not as much dependent on the underlying technology but of readily available interfaces for integrating both functionality as well as document styles into a fixed framework. -- David Kastrup
Re: Getting voices to merge in a complex measure
Knute Snortum writes: > On Fri, May 6, 2022 at 4:22 PM Mark Stephen Mrotek > wrote: >> >> Knute, >> >> In an older version of Lilypond two merge commands were present: >> "different dotted" (that you used) and "different headed" (which >> might be helpful) > > Thanks Mark. I did try \mergeDifferentlyHeadedOn but it didn't seem > to affect anything. Well, they aren't differently headed... -- David Kastrup
Re: LilyPond 2.23.8 released
Freeman Gilmore writes: > On Wed, Apr 27, 2022 at 10:03 AM Carl Sorensen > wrote: >> >> LilyPond does *not* have one binary for all. It has one source code for >> all. >> > That helps > >> >> I think that there can be a bit of confusion here due to the fact that two >> elements in the list aren't binaries. There are three binaries: GNU/Linux >> x86_64, macOS x86_64, and Windows x86_64. Then there are two other >> links: Source code and instructions for building with MacPorts. Perhaps we >> could separate the binaries from the other links. That's what we do on the >> stable download page. >> > > So I was wrong from the start. I was looking for the program for > windows, Windows x86_64,. not realising that the program I was looking > for was a binary which is compiled from the source code. Sorry this > is all stuff from the past at one time i understood, just confused. If it's all stuff from the past at one time you understood, there are likely enough people around for whom this is all stuff from the future they are yet to understand and it would seem like a bad idea to turn this into a roadblock for using LilyPond for them. So you certainly did highlight that we may be relying on an overabundance of technobabble fluency on our download pages. There might be a point in trying to sort and rephrase our points of first contact pages in a manner where installing LilyPond is not going to be an uphill battle already because of language problems. -- David Kastrup
Re: LilyPond 2.23.8 released
Freeman Gilmore writes: > On Tue, Apr 26, 2022 at 7:58 PM David Kastrup wrote: > >> Freeman Gilmore writes: >> >> > Is there going to be a non binary version for windows coming soon? >> >> The source code is the same independent of operating system, so you >> apparently don't mean "source code" when you say "non binary". What >> would your expectations of a "non binary version for windows" be? >> > Ok i see it now, but this was my problem. I know that the source code > (binary) is usually the same for all but I have never worked with > source code for LilyPond so when I read this, "Documentation writers > and testers will generally want to download the latest binary:" with 5 > binaries listed below, *Note, the colon should be a period;* and make > it look like it is not the header for a listing. I may not b the only > dummy out there!. I don't understand what you are saying here and you write things like "source code (binary)" that make pretty clear that we are still talking about entirely different things. So I repeat my question: what would your expectations of a "non binary version for windows" be? -- David Kastrup
Re: LilyPond 2.23.8 released
Freeman Gilmore writes: > On Mon, Apr 25, 2022 at 3:50 PM David Kastrup wrote: > >> >> We are happy to announce the release of LilyPond 2.23.8. This is termed >> a development release, but these are usually reliable. If you want to >> use the current stable version of LilyPond, we recommend using the >> 2.22.2 version. >> >> In this release, dropping Guile 1.8 support has finally become possible >> also for our sources. We'd like to dedicate this release to Ian Hulin >> who was one of the first systematically working on our numerous >> roadblocks for Guile 2 migration after tackling a few other high-level >> problems. In the time spans where his health permitted it, he was able >> to significantly reduce the amount of remaining problems for the Guile 2 >> migration after having started working on them in 2010, making the goal >> that we finally reached now more tangible for others to work on after he >> left us in 2015. >> >> -- >> David Kastrup >> > > Is there going to be a non binary version for windows coming soon? The source code is the same independent of operating system, so you apparently don't mean "source code" when you say "non binary". What would your expectations of a "non binary version for windows" be? -- David Kastrup
Re: LilyPond 2.23.8 released
Kevin Cole writes: > On Mon, Apr 25, 2022 at 3:49 PM David Kastrup wrote: > >> >> We are happy to announce the release of LilyPond 2.23.8. This is termed >> a development release, but these are usually reliable. If you want to >> use the current stable version of LilyPond, we recommend using the >> 2.22.2 version. >> >> In this release, dropping Guile 1.8 support has finally become possible >> also for our sources. We'd like to dedicate this release to Ian Hulin >> who was one of the first systematically working on our numerous >> roadblocks for Guile 2 migration after tackling a few other high-level >> problems. In the time spans where his health permitted it, he was able >> to significantly reduce the amount of remaining problems for the Guile 2 >> migration after having started working on them in 2010, making the goal >> that we finally reached now more tangible for others to work on after he >> left us in 2015. >> > > Is there any plan to retire some -- not all -- of the documentation for > versions long dead? Or, at the very least, confine the searches to the > version of the documentation from which the search was initiated? I see in https://lilypond.org/robots.txt # avoid 404s -- so that we can take action if any occur in /stats # Comment from Phil 9 July 2013 to allow tracking file through build User-agent: * Disallow: /doc/v1.6/ Disallow: /doc/v1.8/ Disallow: /doc/v1.9/ Disallow: /doc/v2.0/ Disallow: /doc/v2.1/ Disallow: /doc/v2.2/ Disallow: /doc/v2.3/ Disallow: /doc/v2.4/ Disallow: /doc/v2.5/ Disallow: /doc/v2.6/ Disallow: /doc/v2.7/ Disallow: /doc/v2.8/ Disallow: /doc/v2.9/ Disallow: /doc/v2.10/ Disallow: /doc/v2.11/ Disallow: /doc/v2.12/ Disallow: /doc/v2.13/ Disallow: /doc/v2.14/ Disallow: /doc/v2.15/ Disallow: /doc/v2.16/ Disallow: /doc/v2.17/ Disallow: /doc/v2.18/ Disallow: /doc/v2.19/ Disallow: /doc/v2.20/ Disallow: /web/ Do you have an indication that this is not working for some search engines? -- David Kastrup
LilyPond 2.23.8 released
We are happy to announce the release of LilyPond 2.23.8. This is termed a development release, but these are usually reliable. If you want to use the current stable version of LilyPond, we recommend using the 2.22.2 version. In this release, dropping Guile 1.8 support has finally become possible also for our sources. We'd like to dedicate this release to Ian Hulin who was one of the first systematically working on our numerous roadblocks for Guile 2 migration after tackling a few other high-level problems. In the time spans where his health permitted it, he was able to significantly reduce the amount of remaining problems for the Guile 2 migration after having started working on them in 2010, making the goal that we finally reached now more tangible for others to work on after he left us in 2015. -- David Kastrup
Re: Problem with Repeats and Alternatives
John Helly writes: > Aloha. > > I've not used LP for a while but in coming back to it I've been > struggling with repeats and find that this 'preferred syntax' does not > seem to work in that it produces: > > Starting lilypond 2.20.0 [test2.ly]... Try matching the version of the documentation you consult with the version of LilyPond you run. -- David Kastrup
Re: Incipit alignment
Martin Baker writes:
> Ah, I thought I’d deleted everything unnecessary, but missed the
> “system-spacing = “ line. Code re-pasted below.
Well, I outcommented it. You could try doing it in this manner:
\version "2.22.2"
\language "english"
incipitwidth = 5
global =
{
\key g \major
}
SopranoOne =
\relative c''
{
e1 |
}
AltoOne =
\relative c''
{
R1 |
}
TenorOne =
\relative c'
{
R1 |
}
BassOne =
\relative c'
{
R1 |
}
incipitCantus = \markup {
\score
{
{
\set Staff.instrumentName = "Cantus"
\override NoteHead.style = #'neomensural
\override Rest.style = #'neomensural
\override Staff.TimeSignature.style = #'neomensural
\clef "petrucci-c1"
\key f \major
\time 4/4
d''1
}
\layout {
line-width=\incipitwidth
indent = 0
}
}
}
incipitAltus = \markup {
\score
{
{
\set Staff.instrumentName = "Altus"
\override NoteHead.style = #'neomensural
\override Rest.style = #'neomensural
\override Staff.TimeSignature.style = #'neomensural
\clef "petrucci-c3"
\key f \major
\time 4/4
g'1
}
\layout {
line-width=\incipitwidth
indent = 0
}
}
}
incipitTenor = \markup {
\score
{
{
\set Staff.instrumentName = "Tenor"
\override NoteHead.style = #'neomensural
\override Rest.style = #'neomensural
\override Staff.TimeSignature.style = #'neomensural
\clef "petrucci-c4"
\key f \major
\time 4/4
d'1
}
\layout {
line-width=\incipitwidth
indent = 0
}
}
}
incipitBassus = \markup {
\score
{
{
\set Staff.instrumentName = "Bassus"
\override NoteHead.style = #'neomensural
\override Rest.style = #'neomensural
\override Staff.TimeSignature.style = #'neomensural
\clef "petrucci-f4"
\key f \major
\time 4/4
g1
}
\layout {
line-width=\incipitwidth
indent = 0
}
}
}
incipitWith = \with
{
\override InstrumentName.self-alignment-X = #RIGHT
\override InstrumentName.self-alignment-Y = ##f
}
\score {
<<
\new ChoirStaff
<<
\new Staff \with \incipitWith <<
\global
\set Staff.instrumentName = \incipitCantus
\clef "G"
\new Voice="v1" {
\SopranoOne
}
>>
\new Staff \with \incipitWith <<
\global
\set Staff.instrumentName = \incipitAltus
\clef "G"
\new Voice="v2" {
\AltoOne
}
>>
\new Staff \with \incipitWith <<
\global
\set Staff.instrumentName = \incipitTenor
\clef "G_8"
\new Voice="v3" {
\TenorOne
}
>>
\new Staff \with \incipitWith <<
\global
\set Staff.instrumentName = \incipitBassus
\clef "F"
\new Voice="v4" {
\BassOne
}
>>
>>
>>
}
\paper{
indent = 3.5\cm
% system-system-spacing =
}
Not fond of that indentation but not willing to invest time fixing it,
either.
I think there is an \incipit command that can help with the task but I
am too lazy to read up on it right now. But it should be documented
somewhere. At any rate, your code just needs working with the
self-alignment-X and self-alignment-Y settings of the outer
InstrumentName .
--
David Kastrup
Re: Incipit alignment
Martin Baker writes:
> Hi David. Thanks so much for your quick response. Does the attached code
> help? M
>
> \paper{
> indent = 3.5\cm
> system-system-spacing =
> }
Quite better, but what was intended above? That's not valid syntax.
--
David Kastrup
Re: Incipit alignment
Martin Baker writes:
> Hello. Does anyone have a solution to the ugly alignment of the part
> names / incipit in the attached screenshot?
> incipitCantus = \markup {
> \score
> {
> {
> \set Staff.instrumentName = "Cantus"
> \override NoteHead.style = #'neomensural
> \override Rest.style = #'neomensural
> \override Staff.TimeSignature.style = #'neomensural
> \cadenzaOn
> \clef "petrucci-c1"
> \key f \major
> \time 4/4
> d''1
> }
> \layout {
> line-width=\incipitwidth
> indent = 0
> }
> }
> }
>
> In the score block
> \set Staff.instrumentName = \incipitCantus
>
> In the paper block
> indent = 3.5\cm
>
I am not going to spend the 10 minutes it takes to secondguess how to
fudge a compilable example from those sketches. It's possible others
will. However you definitely increase your chances of getting good
quality answers by doing everything except the part you are having
problems with yourself rather than force every single person wanting to
answer you to first doing the same gruntwork for your sake and probably
running out of steam before even getting to your actual problem.
That process of creating everything key-ready for supplying the answer
is supposed to be described in <https://lilypond.org/tiny-examples>. It
probably is not clear enough.
--
David Kastrup
Re: changing lyrics font-style to italics
Stefan Thomas writes: > Dear community, > for certain reasons I would like to change the font-style of a Lyrics > context to italic. > I tried it with > \override LyricText #'font-style = #'italic > but without success. > Does someone know how to do it? You could start by not ignoring LilyPond's warnings. There is no such property as font-style . You probably want font-shape instead. Also you could try to update to 2.18 syntax and use \override LyricText.font-shape ... -- David Kastrup
Re: Removing all dynamics from MIDI
Simon Albrecht writes: > Hi David, > > On 16/04/2022 18:11, David Santamauro wrote: >> Hi, it seems removing the Dynamic_performer doesn’t actually remove >> performance of articulations. > > > Articulations are Script grobs, not Dynamics. Maybe removing > Script_engraver as well would do the trick? I don’t work with MIDI > much, so I don’t know whether it will. Removing _engravers_ will not have any impact on MIDI generation. Only performers and translators make a difference here. In this case, I don't think there is a separate performer to remove: this is handled by the Note_performer . -- David Kastrup
Re: Unwanted font ligature
Jean Abou Samra writes:
> Le 15/04/2022 à 22:01, Paul Hodges a écrit :
>> I am trying to write the dynamic "sfffz". But when I write
>> \markup\dynamic"sfffz" the first sf is made a ligature, then the
>> last two are made another ligature - the difference in spacing of
>> the f's is ugly, as in the attached image - is there anything I can
>> do about it?
>>
>> Paul
>
>
>
> \markup \concat { \dynamic s \dynamic f \dynamic f \dynamic f \dynamic z }
>
> ?
Easier to write as
\markup \concat \dynamic { s f f f z }
and should be perfectly equivalent.
> See
> http://lilypond.org/doc/v2.23/Documentation/notation/formatting-text.html
>
> Best,
> Jean
>
>
>
--
David Kastrup
Re: how to change extents of a grob?
Werner LEMBERG writes: > Dear LilyPonders, > > > I can get the extents of a grob with `ly:grob-extent`. What is the > corresponding Scheme function to set the extents? > > Or to ask in a different way: At the time when properties are > processed and you have to manipulate stencils, changing the stencil of > a grob doesn't change the extents of this grob, AFAICS. You are not supposed to change stencils at all. They are not entities with identity. It's like asking how to change the exponent of a floating point number. Whatever ability on the machine level exists for that, it does not make sense to export an interface. > How can I adjust the extents at this stage to fit the dimensions of > the stencil (even if LilyPond no longer needs and/or uses the values > for positioning)? Create a new stencil with different dimensions and use that. -- David Kastrup
Re: How do I merge a quarter-note with the second eighth-note of a pair?
Kevin Cole writes:
> I think an example will make the question clearer: How do I merge the
> B quarter-note with the B eighth-note following the D eighth-note
> below?
>
> %%%
> \version "2.20.0"
> \language "english"
>
> \layout {
> \autoBeamOff
> }
>
> global = {
> \time 4/4
> \mergeDifferentlyHeadedOn
> }
>
> melody = {
> \relative {
> \global
>
> <<
> { \voiceOne b'4 }
> \new Voice
> { \voiceTwo d,8[( b'8]) }
> >>
> \oneVoice
> a8. g16 g4 r8 g8 |
> \bar "|."
> }
> }
>
> \score {
> \new Staff { \melody }
> }
> %%%
WHY would you merge the B quarter-note with the B eighth-note? They are
not even in the same time-step.
--
David Kastrup
Re: Question on multiple markups
Evan Driscoll writes:
> Great, thanks! I tried something like that, but never had the space between
> the offset amount and following _, which in retrospect makes sense but I
> didn't think of at the time. I also agree in that context just the X-offset
> version looks better and now I'm using that in one of the two places it
> appears, though at the other some additional "collisions".
>
> I've got hopefully just one more question for my current project before I
> declare it good enough -- I can't get positioning tweaks to apply to either
> \tempo indications or rehearsal \marks.
>
> http://lilybin.com/vhf35h/15 shows that problem -- this one isn't really
> well-motived by the example and I just chose a random offset to show it not
> working (here I'm using X-offset but in context I probably want Y as well),
> but the output is the same whether the overrides are commented out or not.
Well, you need to apply such overrides at the context level where the
engraver sits. Without any specification, the Bottom context is used
which usually is Voice (or TabVoice or similar) which is suitable for
things like beams, stems, noteheads, slurs. However, tempo and
metronome marks usually sit at the Score level (namely are engraved only
once per multi-staff system) so you need to adapt the override
accordingly:
\relative c' {
\once\override Score.RehearsalMark.X-offset=#10
\mark\default
\tempo "Allegro"
\once\override Score.MetronomeMark.X-offset=#10
c4
_"marc."
^"arco"
\f
c
c
c
}
--
David Kastrup
Re: installing lilypond-mode for emacs on Linux
Paul Scott writes: > On 4/7/22 15:08, David Kastrup wrote: >> Paul Scott writes: >> >>> On 4/7/22 14:15, David Kastrup wrote: >>>> Paul Scott writes: >>>> >>>>> On 4/7/22 13:02, David Kastrup wrote: >>>>>> Paul Scott writes: >>>>>> >>>>>>> Greetings, >>>>>>> >>>>>>> I've forgotten too much. I see the instructions for activating >>>>>>> lilypond-mode and am not remembering enough to get it to work. >>>>>>> >>>>>>> TIA for any help, >>>>>> cd elisp >>>>>> make >>>>>> sudo make install >>>>> I'm not finding a makefile. >>>> Have you tried? >>> Yes. I've looked for many files like elisp and lilypond-mode in my >>> attempts. >>>>There is GNUmakefile which will get picked up by, well, >>>> GNU Make. >>> I hadn't thought of GNUmakefile but according to updatedb and locate >>> there are only two clearly unrelated GNUmakefiles on this computer. >> Which begs the question: just what have you installed where and how with >> regard to LilyPond? > > > I have Lily 2.22-2 and 2.23.6 installed. Where and how? -- David Kastrup
Re: installing lilypond-mode for emacs on Linux
Paul Scott writes: > On 4/7/22 14:15, David Kastrup wrote: >> Paul Scott writes: >> >>> On 4/7/22 13:02, David Kastrup wrote: >>>> Paul Scott writes: >>>> >>>>> Greetings, >>>>> >>>>> I've forgotten too much. I see the instructions for activating >>>>> lilypond-mode and am not remembering enough to get it to work. >>>>> >>>>> TIA for any help, >>>> cd elisp >>>> make >>>> sudo make install >>> I'm not finding a makefile. >> Have you tried? > Yes. I've looked for many files like elisp and lilypond-mode in my > attempts. >> There is GNUmakefile which will get picked up by, well, >> GNU Make. > > I hadn't thought of GNUmakefile but according to updatedb and locate > there are only two clearly unrelated GNUmakefiles on this computer. Which begs the question: just what have you installed where and how with regard to LilyPond? -- David Kastrup
Re: installing lilypond-mode for emacs on Linux
Paul Scott writes: > On 4/7/22 13:02, David Kastrup wrote: >> Paul Scott writes: >> >>> Greetings, >>> >>> I've forgotten too much. I see the instructions for activating >>> lilypond-mode and am not remembering enough to get it to work. >>> >>> TIA for any help, >> cd elisp >> make >> sudo make install > > I'm not finding a makefile. Have you tried? There is GNUmakefile which will get picked up by, well, GNU Make. -- David Kastrup
Re: installing lilypond-mode for emacs on Linux
Paul Scott writes: > Greetings, > > I've forgotten too much. I see the instructions for activating > lilypond-mode and am not remembering enough to get it to work. > > TIA for any help, cd elisp make sudo make install probably. -- David Kastrup
Re: Unable to use repeat volta
Omer Katzir writes: >> On 7 Apr 2022, at 18:03, David Kastrup wrote: >> >> Omer Katzir writes: >> >>> Using on macOS Monterey, compiled from macports >>> >>> Taken the snippet from >>> https://lilypond.org/doc/v2.23/Documentation/notation/long-repeats >>> <https://lilypond.org/doc/v2.23/Documentation/notation/long-repeats> >> >> You see the v2.23 in that URL? >> >>> Starting lilypond 2.22.2 [Untitled]... >> >> There is no guarantee that future extensions of LilyPond will be >> undocumented, so if you use documentation for future versions of >> LilyPond (compared to the version you use), you might run into problems >> occasionally. > > Thank you everyone for your answers, Google wasn’t the best choice > when I was looking for this. Thank you for guiding me for the right > place! It usually works reasonably well when finding a page like that to replace just the version number in the URL to get suitable information. Occasionally you will hit a chapter that does not exist for v2.22 while it does for v2.23, but the vast majority will be a modification of what was there before and named identically apart from the version number. -- David Kastrup
Re: German chords with uppercase bass
Henning Hraban Ramm writes: > As is shown e.g. in > https://lilypond.org/doc/v2.22/Documentation/snippets-big-page.de.html > “Changing the chord names to German or semi-German notation”, > \germanChords changes bass notes of chords like a:m/c to lowercase. > > While I don’t believe that this is common in Germany, I really would > like to get German chords (i.e. H instead of B) with uppercase bass > notes – as I know it from all my (German) songbooks. Any accordion music uses uppercase for bass notes and lowercase for chords. -- David Kastrup
Re: Unable to use repeat volta
Omer Katzir writes: > Using on macOS Monterey, compiled from macports > > Taken the snippet from > https://lilypond.org/doc/v2.23/Documentation/notation/long-repeats > <https://lilypond.org/doc/v2.23/Documentation/notation/long-repeats> You see the v2.23 in that URL? > Starting lilypond 2.22.2 [Untitled]... There is no guarantee that future extensions of LilyPond will be undocumented, so if you use documentation for future versions of LilyPond (compared to the version you use), you might run into problems occasionally. -- David Kastrup
Re: Mutopia?
Paul Hodges writes: > The variation in content of these mirror sites is sufficiently explained by > this quote from the top of the ca one: > > > All the functionality of the original Mutopia site has been restored, and the > piece count will continue to increase as projects are restored from the > Wayback Archive. Full restoration (~2200 pieces) is anticipated to be > completed in April. New developments will be posted here in this space. Given that the scores' GitHub project is still fully accessible at https://github.com/chrissawer/The-Mutopia-Project.git one has to wonder what they need the Wayback Archive for. -- David Kastrup
Re: Mutopia?
Calvin Ransom writes: > Does anyone know what's going on with the mutopia project servers? I > haven't been able to access the website recently. I just get a server > error message. > https://www.mutopiaproject.org > > Calvin Ransom GitHub page is still there, last commit Oct 31, 2019. <https://github.com/MutopiaProject/MutopiaProject> The last activity of Chris Sawer on GitHub overall was in 2020. His Twitter account at https://twitter.com/cjsawer however appears still active. Maybe try contacting him via GitHub? -- David Kastrup
Re: missing something obvious about creating hairpins above the staff
Kenneth Wolcott writes:
> Hi;
>
> I'm obviously missing something trivially simple.
>
> I see how to display dynamics above the staff, but I do not see how
> to display hairpins above the staff.
Same way?
{
c'1^\< c'1\!
}
works just fine here.
--
David Kastrup
Re: Feature request: Fix cascading error messages
Martín Rincón Botero writes: > >> Since TeX is predominantly employed for compiling LaTeX sources, that >> speaks more about the LaTeX implementation than TeX itself. > > Because I'm under the impression that Lilypond is more similar to > LaTeX than to TeX, It totally isn't, neither in concept nor in execution. In my book, it would benefit from a layer trying to abstract content and design in a manner like LaTeX does, but LilyPond in common use does not have any such layer or architecture as it stands. It's essentially employed like plain TeX, explicitly cranking out stuff with thin individual user-convenience layers on top. We don't have the equivalence of document classes, and no coherent system of what amounts to LaTeX's package system. -- David Kastrup
Re: Feature request: Fix cascading error messages
Werner LEMBERG writes: >> Why make the user wait so long to make him fix a misspelled word or >> make him put a curly brace? A first pass should be done without >> \score blocks and abort (or at least ask if you want to continue!) >> if this first pass produces errors. > > This sounds sensible; maybe this suppression of processing `\score` > blocks can be implemented in Scheme so that LilyPond with a special > command line option acts as a syntax checker. Have you actually tried? Apart from scores placed in explicit books and bookparts, LilyPond already delegates the typesetting until after the whole input file has been parsed. -- David Kastrup
Re: Feature request: Fix cascading error messages
Martín Rincón Botero writes: > I'm lucky to be able to work using Lilypond through Python. I never > compile the whole score I'm working on, but only the current "segment" > (around 2 pages) and the corresponding pages get updated in the > PDF. Compiling the whole thing is something I do only at the end of a > project because it's so slow (I believe TeX suffers from similar > problems, so mentioning TeX doesn't really improve the situation). TeX was written to make efficient use of computers with a power that would be considered absolutely ridiculously impaired by today's standards, so it tends to be amazingly blazingly fast. Any differing impression most likely due is to abusing TeX as a Turing machine for solving more or less generic programming purposes rather than as a typesetting engine with a basic macro layer. Since TeX is predominantly employed for compiling LaTeX sources, that speaks more about the LaTeX implementation than TeX itself. To wit: in ancient times, using \tracingall for looking at how a document got compiled tended to deliver useful information; nowadays it just puts out indecipherable riffraff, like using gdb for tracing the progress of a Scheme interpreter does. A Texinfo rather than LaTeX compilation is probably more in line with the expected performance (at least for input not transcending the ASCII input plane of Unicode) but no promises: the old adage "any improvements in hardware performance will get eaten up by more waste in programming" is a universal phenomenon. -- David Kastrup
Re: Feature request: Fix cascading error messages
Christopher Heckman writes: > I have a request concerning Lilypond that has bothered me for a while, > but which I haven't seen any one else complain about. It is the > cascade of error messages you get when you leave out a right-brace or > some other symbol. > > Maybe this could be added as an option to lilypond? > > lilypond --cascade-level=N file.ly > > which, for any given line, prints the first N error messages, and > after that a message saying that further error messages have been > suppressed. A default value for N might be 3 or 4. > > What does everyone think? The problems from followup errors do not magically disappear because they are not reported. The only thing that would make sense is better error recovery (which is pretty hard but can partly be achieved by inserting "error" productions matching typical error scenarios into the grammar: that causes a more targeted recovery and is arguably underutilised in LilyPond's grammar) but not pretending to be fine. The problem with the followup errors is that there is no way that LilyPond can actually be sure that they are followup errors. Good heuristics for error recovery productions in the grammar are tricky to do, and since they are only relevant for erroneous input, they tend not to be assigned a high priority. On the other hand, I found excellent error recovery to be of high importance when the normal workflow was sucking a stack of punch cards through the reader and then checking your output shelf hours later for a stack of line printer paper with the results of your compilation (and hopefully execution, possibly accompanied by a post mortem dump listing the COMPASS assembly instructions running into problems). I rarely find myself working an error log off sequentially these days rather than just restarting compilation after fixing a limited set of problems. -- David Kastrup
Re: Should \partial accept music instead of duration?
Jean Abou Samra writes:
> Le 27/03/2022 à 16:23, David Kastrup a écrit :
>> It doesn't share the same music objects for different notes since $(...)
>> makes a ly:music-deep-copy anyway that will deduplicate the elements of
>> SequentialMusic while copying them. The intermediate expression is
>> indeed not fit for every use, but the final deep copy fixes that.
>
>
> Ah, yes, correct. I always forget about that twist of $ as I
> only use it for more immediate (lexer) evaluation and not for
> copies. Thanks for the reminder.
Well, it makes $xxx and \xxx behave identically. And \xxx needs to copy
since music functions are allowed to change their arguments.
The meaning of $ was actually introduced after a pretty thorough
redesign where I think the bulk might have happened with
commit fecc5999e224304e9d54e48bc7a92cdbb123cd35
Author: David Kastrup
Date: Sun Nov 6 19:15:27 2011 +0100
Let #{ ... #} pass its $ handling to environment cloning
Includes convertrules.py rules for dealing with #{ ... #} and for
removing uses of ly:export
in version 2.15.18. You don't really want to know (or explain) what
meaning $ had before that change. Or #{ ... #}. Or the
interdependency.
--
David Kastrup
Re: Should \partial accept music instead of duration?
Jean Abou Samra writes:
> Le 26/03/2022 à 03:23, Kieren MacMillan a écrit :
>> Hope that makes it clearer?
>
>
> Yes, I understand better, thanks. I'd just suggest changing your
> snippet to
>
> \version "2.23.7"
>
> $(let ((notes (ly:music-property #{ d'> #} 'elements)))
> (make-sequential-music
> (map (lambda (x) (ly:music-deep-copy (list-ref notes (random
> (length notes)
> (iota 400
>
>
> with the essential change being the insertion of a
> ly:music-deep-copy so it does not share the same music
> objects for different notes, which could go wrong with
> the application of some music functions.
It doesn't share the same music objects for different notes since $(...)
makes a ly:music-deep-copy anyway that will deduplicate the elements of
SequentialMusic while copying them. The intermediate expression is
indeed not fit for every use, but the final deep copy fixes that.
--
David Kastrup
Re: LilyPond 2.23.7 released
Jonas Hahnfeld via LilyPond user discussion writes: > Am Sonntag, dem 27.03.2022 um 13:31 +0200 schrieb Michael Gerdau: >> %% start >> \version "2.23.7" >> >> date = #(strftime "%d.%m.%Y" (localtime (current-time))) >> %% end >> >> gives me: >> 3:9: Fehler: GUILE signalisierte einen Fehler für den hier beginnenden >> Ausdruck >> date = # >> (strftime "%d.%m.%Y" (localtime (current-time))) >> >> Invalid argument >> >> Shouldn't this work or has the syntax changed? > > This example works completely fine for me (on Linux). Where are you > testing this, on Linux, macOS, or Windows? This is very likely also quite locale-dependent. -- David Kastrup
Re: Help with ties and accidentals
KEITH LYNN writes: > Mark, > I'm trying to reproduce the following sheet music > > Original http://69.246.129.36/002.jpg > > I'm using this code to try to produce it > > Lilypond file http://69.246.129.36/002.jpg > > And it's producing this result > > Output http://69.246.129.36/002.jpg > That's the same link 3 times in a row, not really helpful. However, if we assume that this is the original, it is clear that you are making the mistake I already told you about: there is not a single b in those measures: all of them are bes. Your input notenames apparently try to tell LilyPond how the notes are to be _printed_ rather than how they are to _sound_. This is not how LilyPond's pitch entry works. Please read the Learning Manual section about pitches in <https://lilypond.org/doc/v2.22/Documentation/learning/pitches-and-key-signatures#warning-key-signatures-and-pitches>. -- David Kastrup
Re: Help with ties and accidentals
KEITH LYNN writes: > I am having trouble trying to produce a tie between a flat note and a > non flat note of the same pitch. That sounds like a misunderstanding of what "tie" means. Ties are used for connecting several notes of the same pitch into a single note of the combined duration. However, your problem might be a different terminology/concept problem: > For example, I want to tie a bes to a b, but instead of producing the > tie symbol, it places a natural symbol in front of the second note. > > How do I stop that? Thanks. This sounds like you are confused about LilyPond's input note language. Notes of equal pitch have equal input note names. A bes is not something at the notation height of b with a flat before it. A bes is something that sounds a half note lower than a natural b. Regardless of how it gets printed. So you probably want to write bes ~ bes here. You might want to read the LilyPond tutorial: it is intended to be comparatively compact sequential reading introducing the main LilyPond concepts and get you started. -- David Kastrup
Re: 'baroque' time signatures
Leo Correia de Verdier writes: > I added necessary supporting code like Michael (and a voice filled > with repeated half notes, so I could hear the tempo) and got it to > compile compile correctly with tempo changes (at least alternating > fast and slow sections) on Lilypond 2.19.82 Frescobaldi 3.1.3, so I > wouldn't think that is the root of your problem. It may simply be the MIDI device he is using. My own Solton expanders refuse to go above something like 256 quarters per minute (which is a nuisance if you have \time 2/2 \tempo 2=136) and generally have a dim view against beat moments other than 4 or possibly 8. Which means that you have to juggle with \scaleDurations and its ilk when generating MIDI. If we don't get to see actual compilable code and/or the generated MIDI files, I doubt we will be able to help him. -- David Kastrup
Re: Should \partial accept music instead of duration?
Tim's Bitstream writes: >> On Mar 20, 2022, at 2:24 AM, Werner LEMBERG wrote: >> >> What about providing a new command `\upbeat` and moving `\partial` >> into oblivion? Compare this to `\tuplet` vs. `\times`. > > Perhaps this is an American jazzism, but we would refer to those as > \pickup notes. \pickup has a reasonable ring to it, fitting it in a reasonable subset of applications for \partial . The problem I have is figuring out its role, though. With \times/\tuplet we clearly phased out \times for \tuplet consistently in the documentation. I am not really on-board with the same regarding \partial/\pickup : the overlap in semantics is different in character. -- David Kastrup
Re: can someone point me to complete documentation for the partial command argument syntax?
Wols Lists writes: > On 19/03/2022 20:01, David Kastrup wrote: >> Sam Roberts writes: >> >>> I tried so hard to be accurate, but I missed something: >>> >>> On Sat, Mar 19, 2022 at 12:38 PM Sam Roberts wrote: >>>> After experimentation, I found this worked: >>>> >>>> \time 3/4 \partial 1 c4 | >>> >>> It "works" in that pdf output looks ok, c4 is in the pickup bar, but >>> still warns about the bar checks, as it should. >> Please don't just dump partial code that does not compile: this >> makes it >> impossible to accurately see what you are doing. > > David, you're expecting too much! By his own admission he's a newbie. > > And in this particular instance it is quite clear that > (a) he does not understand what the problem IS, > and > (b) if he did understand, he wouldn't have a problem! > > So, in this particular instance you are asking him to go away and > solve his problem by himself. NOT good. No, I am asking him to actually post the code he is having problems with rather than something else. -- David Kastrup
Re: Should \partial accept music instead of duration?
Aaron Hill writes:
> On 2022-03-19 7:53 pm, Dan Eble wrote:
>> On Mar 19, 2022, at 20:53, Aaron Hill wrote:
>> ...
>>>>> A convert-ly rule would probably not be possible given the
>>>>> limited power
>>>>> of regular expressions. As such, \partial might need to support
>>>>> both
>>>>> duration and music arguments. Initially I thought this might not be
>>>>> possible, given that a naked duration can be treated as music;
>>>>> but the
>>>>> following does seem to work:
>> ...
>> I wouldn't want to have to explain to users why these turn out
>> different.
>> \score {
>> \fixed c' {
>> \partial 4. 4.
>> }
>> }
>> \score {
>> \fixed c' {
>> \partial c4. c4.
>> }
>> }
>>
>
> Fair point, though the intention here would be that backwards
> compatibility would only need to exist for a time.
I strongly disagree since \partial with a duration is the natural and
proper expression when writing a separate timing track.
> A warning could be issued whenever a user applies the older syntax;
> this would inform the user of the impending breaking change while
> still allowing existing code to compile. When it is convenient, a
> future release would only support music as the argument.
4. _is_ valid music.
--
David Kastrup
Re: can someone point me to complete documentation for the partial command argument syntax?
Sam Roberts writes: > I tried so hard to be accurate, but I missed something: > > On Sat, Mar 19, 2022 at 12:38 PM Sam Roberts wrote: >> After experimentation, I found this worked: >> >> \time 3/4 \partial 1 c4 | > > It "works" in that pdf output looks ok, c4 is in the pickup bar, but > still warns about the bar checks, as it should. Please don't just dump partial code that does not compile: this makes it impossible to accurately see what you are doing. You probably are using \partial wrong: its argument does not specify how long it is _since_ a full bar but how long it is _to_ a full bar. As such, you'd usually see ... \time 3/4 \partial 4 c4 | ... in typical contexts. -- David Kastrup
Re: Opposite of Laissez Vibrer?
Jean Abou Samra writes: > Le 11/03/2022 à 12:38, Paul Hodges a écrit : >> Perfect - Thank you! I'd never have thought of looking there > > Where did you look? As this question comes up fairly frequently, I'd > like to know if there is a better structure we can give to the manual > on this topic to help people find their way. I am not sure this is entirely a manual problem. Left and right semities are really close relatives while \laissezVibrer and \repeatTie are completely different concepts and contexts and are essentially prime examples of the use of semities, but not really fundamentally defining what they actually are, and if you have need for both, their utterly different naming and manual location essentially doubles the search work to figure out how to use them. -- David Kastrup
Re: How to change appearance of multimeasure rest?
Francesco Napoleoni writes:
> Hello everyone
>
> Given this fragment:
>
> {
> \time 4/2
>
> R\breve |
> }
>
> I would like the multimeasure rest printed like a semibreve rest.
>
> The following code brings me near to my goal, but...
>
> {
> \time 4/2
> \override MultiMeasureRest.stencil = #ly:text-interface::print
> \override MultiMeasureRest.text = \markup \musicglyph #"rests.0"
> \override MultiMeasureRest.staff-position = #2
> R\breve |
> }
>
> ... the rest is slammed to the left of the measure. What am I missing?
>
> Or is there a better way to obtain what I want?
\override MultiMeasureRest.usable-duration-logs = #'(0)
--
David Kastrup
Re: [HELP] Change notehead font-size depending on note duration
Robert Mengual writes:
> Hello everyone,
>
> I am facing a challenge in which I have been stuck already 7 days. I
> am sending this email as my last hope to get this done or at least
> receive any assistance that allows me to move forward. I really hope
> you can help me.
>
> Find attached a Tiny.ly, I did the same for changing things like
> NoteHead.text and NoteHead.Y-offset and everything worked
> perfectly. However, it looks like I cannot use the grob when changing
> the NoteHead.font-size
>
> I would really appreciate any help. Am I doing something wrong? Is
> there a better way to achieve what I want?
Well, font properties are not callback material. And you should not
have mentioned NoteHead.text as being relevant and cause me extra work.
Here is one way:
#(define resized-stencil (grob-transformer 'stencil
(lambda (grob default)
(let ((scale (magstep (- 2
(ly:duration-log
(ly:event-property
(event-cause grob) 'duration))
(ly:stencil-scale default scale scale)
\relative c' {
\temporary \override NoteHead.stencil = #resized-stencil
c1 | c2 d4 e8 f16 g32 a64 b128 c
}
--
David Kastrup
Re: My Tuba+Piano engravings: during midi playback, the Piano dominates the Tuba; why?
How did this end up in unsent drafts? Sorry for the late reply.
Kenneth Wolcott writes:
> Hi;
>
> My Tuba+Piano engravings: during midi playback, the Piano dominates
> the Tuba; why?
>
> I know that this is really a midi versus live performance question...
>
> I can change the dynamics of the Tuba to be "fff" and both the left
> hand and right hand of the Piano to be "ppp", and yet the Piano
> dominates the Tuba during midi playback.
>
> I'm not expecting a midi playback to sound as good as a live
> performance, but this seems...odd.
>
> Is there anything I can do with Lilypond to generate a midi playback
> of Tuba+Piano pieces that sound more realistic?
You can fix unbalances in your MIDI-interpreter by extending the
following from ly/midi-init.ly:
instrument-equalizer-alist = #'(
("flute" . (0 . 0.7))
("oboe" . (0 . 0.7))
("clarinet" . (0 . 0.7))
("bassoon" . (0 . 0.6))
("french horn" . (0.1 . 0.7))
("trumpet" . (0.1 . 0.8))
("timpani" . (0.2 . 0.9))
("violin" . (0.2 . 1.0))
("viola" . (0.1 . 0.7))
("cello" . (0.2 . 0.8))
("contrabass" . (0.2 . 0.8))
)
I don't know what MIDI-expander those values were intended for, to be honest.
--
David Kastrup
Re: Alternative to \parallelMusic?
Kevin Cole writes:
> Hi,
>
> I have a score with a lot of sections as shown in the attached PNG. I
> see something like what I want to achieve at the end of the section on
> \parallelMusic:
>
> https://lilypond.org/doc/v2.20/Documentation/notation/multiple-voices#writing-music-in-parallel
>
> My first thought, to avoid inserting rests, was simply to have the
> same notes appearing in both voices except for where they deviate.
> However, that resulted in sometimes placing the notes consecutively
> rather than concurrently. For example, I ended up with two whole notes
> in one measure.
>
> But as has been mentioned on this list before, there are often
> multiple ways to tackle problems. So, I'm wondering if there's
> something a bit more intuitive, simpler, etc. to get the first of the
> four beamed eighth notes in the second measure to line up with the
> half notes.
Maybe something like this?
\new Voice = "main"
{
\key d \major
fis8 g b e'
fis g b b'~ |
4.
8
\voices 1,"main"
<< { a' a' g' fis'~ | 4. } \\
{ \voiceTwo 2 \oneVoice }
>>
}
--
David Kastrup
Re: Failure to properly display appoggiatura inside a repeat volta
m75
s2. | % m76
}
}
}
lh_one = {
\global
\clef bass
r4 | % m0
2. | % m1
2._> | % m2
2_> 4_> | % m3
4| % m4
2. | % m5
2. | % m6
d2. ~| % m7
%\break
d4 s2 | % m8
\repeat volta 2 {
\grace s8.
4 r r | % m9
4 r r| % m10
}
\repeat volta 2 {
2\mp 4 | % m11
2 4 | % m12
2 4 | % m13
2 4 | % m14
%\break
2 4 | % m15
2 4| % m16
2 4 | % m17
2 4| % m18
4 q| % m19
a,4 q| % m20
r4 e' d' | % m21
%\break
cs'4() a | % m22
a,4 q | % m23
a,4 q| % m24
d4 q| % m25
d4 b,(a,) | % m26
2 4 | % m27
2 4 | % m28
%\break
2 4| % m29
2 4 | % m30
2 4| % m31
2 4 | % m32
2 4| % m33
2 r4 | % m34
4 e e, ~ | % m35
%\break
4 fs gs | % m36
a2 e4 | % m37
4 q | % m38
4 q | % m39
4 q | % m40
4 a,_> as,_> | % m41
b,4_> c_> cs_> | % m42
%\break
\appoggiatura { a,16 b, cs } d4^> q | % m43
4 q | % m44
4 q | % m45
a,4 g a,| % m46
\appoggiatura { a,16 b, cs } d4^> q | % m47
a,4 q | % m48
e,4 q | % m49
%\break
4 | % m50
fs | % m51
4 q | % m52
4 q | % m53
b,4 q | % m54
4 q | % m55
4| % m56
%\break
4| % m57
4 fs^> e^> | % m58
\appoggiatura { a,16 b, cs } d4^> q | % m59
4 q | % m60
4 q | % m61
a,4 g a,| % m62
4 q| % m63
%\break
4| % m64
4 q | % m65
4 q | % m66
2. | % m67
2. | % m68
2^> 4_> | % m69
%\break
4_> _> _> | % m70
2. | % m71
2. | % m72
}
\alternative {
{
4 ^> ^> | % m73
4^> ^> ^>| % m74
}
{
4| % m75
4_> r r| % m76
}
}
}
lh_two = {
\global
\clef bass
s4 | % m0
s2. | % m1
s2. | % m2
s2. | % m3
s2. | % m4
s2. | % m5
s2. | % m6
d,4 a, fs, | % m7
%\break
d,4 r r | % m8
\repeat volta 2 {
\grace s8.
s2.| % m9
s2.| % m10
}
\repeat volta 2 {
s2. | % m11
s2. | % m12
s2. | % m13
s2. | % m14
%\break
s2. | % m15
s2. | % m16
s2. | % m17
s2. | % m18
s2. | % m19
s2. | % m20
e2. | % m21
%\break
s2. | % m22
s2. | % m23
s2. | % m24
s2. | % m25
s2. | % m26
s2. | % m27
s2. | % m28
%\break
s2. | % m29
s2. | % m30
s2. | % m31
s2. | % m32
s2. | % m33
s2. | % m34
s2. | % m35
%\break
s2. | % m36
s2. | % m37
s2. | % m38
s2. | % m39
s2. | % m40
s2. | % m41
s2. | % m42
%\break
s2. | % m43
s2. | % m44
s2. | % m45
s2. | % m46
s2. | % m47
s2. | % m48
s2. | % m49
%\break
s2. | % m50
s2. | % m51
s2. | % m52
s2. | % m53
s2. | % m54
s2. | % m55
s2. | % m56
%\break
s2. | % m57
s2. | % m58
s2. | % m59
s2. | % m60
s2. | % m61
s2. | % m62
s2. | % m63
%\break
s2. | % m64
s2. | % m65
s2. | % m66
s2. | % m67
s2. | % m68
s2. | % m69
%\break
s2.| % m70
s2.| % m71
s2.| % m72
}
\alternative {
{
s2. | % m73
s2. | % m74
}
{
s2. | % m75
s2. | % m76
}
}
}
\score {
<<
\new Staff \with { instrumentName = "Trumpet" } \trumpet
\new PianoStaff \with { instrumentName = "Piano" }
<<
\new Staff << { \rh_one } \\ { \rh_two } >>
\new Staff << { \lh_one } \\ { \lh_two } >>
>>
>>
\layout {}
}
\score {
\unfoldRepeats {
<<
\new Staff {
\set Staff.midiInstrument = "trumpet"
\trumpet
}
\new Staff {
\set Staff.midiInstrument = "acoustic grand"
<< { \rh_one } \\ { \rh_two } >>
}
\new Staff {
\set Staff.midiInstrument = "acoustic grand"
<< { \lh_one } \\ { \lh_two } >>
}
>>
}
\midi {}
}
--
David Kastrup
Re: Possible bug: Grace note at the beginning makes instrumentName disappear?
Thomas Scharkowski writes:
> Grace note at the beginning makes instrumentName disappear:
> macOs 12.1
> LilyPond 2.23.6
>
> --
> \version "2.23.6"
>
> GraceVoice = \new Voice
> {
> \grace
> c'8 b4
> }
>
> GraceStaff = \new Staff
> <<
> \set Staff.instrumentName = "Grace"
> \GraceVoice
>>>
>
> \score {
> \GraceStaff
> }
>
> NoGraceVoice = \new Voice
> {
> b4
> }
>
> NoGraceStaff = \new Staff
> <<
> \set Staff.instrumentName = "NoGrace"
> \NoGraceVoice
>>>
>
> \score {
> \NoGraceStaff
> }
>
No, it doesn't. \grace c'8 occurs before the beat, \set
Staff.instrumentName occurs on the beat and consequently has no effect
on the already created Staff.
You probably want to write
\new Staff \with { instrumentName = ... } ...
in order to have instrumentName exist from the beginning of the
context's life-time rather than from its first beat (which may be later
in the case of grace notes).
--
David Kastrup
Re: Lilypond and Windows XP 32 bits
Jean Abou Samra writes: > I'm sorry to say this, but nobody will be able to help you. > Compiling and packaging LilyPond is an extremely involved process, > builds take hours with the current infrastructure, and the > new infrastructure we are currently replacing it with creates > 64-bit binaries, so they won't run on XP. Please understand that > LilyPond is developed and maintained by a small group of volunteers > who do this in their free time. Testing OSes and fixing OS-specific > problems takes a lot of time, especially with Windows, and XP has > been unsupported since 2014, meaning that there will most likely > be numerous obstacles on the way to getting it to work, related > to other software that has also long dropped XP support. I > doubt anyone will make this their priority. By all means prefer > upgrading your OS if you can, as it is also very insecure > by now. If you cannot, the only solution I can imagine > will be to run an outdated version of LilyPond like 2.18. Well, wouldn't it be reasonable then if our download page ceased declaring Windows 2000 and Windows XP as supported by our installers? -- David Kastrup
Re: More about stencil
Rip _Mus writes: > Good morning, > thank you, thank you very much! > The level of customization of lilypond seems incredible to me: I will have > to deepen a lot, especially as regards the definition of new > engravers. Not all of it really deserves the name "customization" but rather is more or less a consequence of the proverbial hood not being welded shut. Being able to touch everything does not imply that there are driver-level controls for everything, so getting competent help for some task here does not imply that LilyPond is well-prepared to do this task. Though it can be the first step of getting it there. -- David Kastrup
Re: Markup problem
porttitor vel odio vel, ullamcorper tincidunt dolor. Vestibulum a porta orci. Donec iaculis velit vehicula mi sagittis convallis.
Nullam at ex dapibus, molestie nulla eget, rutrum lectus. Ut cursus eu elit in semper. Duis fringilla leo metus, eget pharetra urna tempus sit amet. Aenean ac lectus maximus, tristique nisl quis, convallis tellus. Donec laoreet sem sit amet vehicula sodales. In a risus lacinia, dapibus odio sed, pellentesque quam. Ut eget nibh eu lacus consectetur egestas. Fusce sed maximus odio. Morbi posuere eu ante ut cursus. Morbi tempor leo sed elit elementum congue. Donec porttitor orci vitae nibh commodo, id elementum erat facilisis.
Vestibulum a viverra mauris, eget pellentesque risus. Nulla eu sapien elit. Sed pharetra turpis at eros volutpat, nec consequat tortor convallis. Proin nec cursus dolor. Donec consequat efficitur felis eu placerat. Vestibulum congue, velit id rutrum posuere, nunc velit sagittis dolor, at suscipit neque arcu quis tellus. Donec leo tellus, fringilla sed condimentum ac, sodales a nibh. Praesent eu tellus vestibulum, finibus nunc fringilla, semper odio. Sed ultricies at erat ac ornare. Duis a facilisis lacus, eu elementum quam.
Vivamus id enim gravida, auctor elit a, viverra nisi. Aliquam imperdiet ornare felis a molestie. Maecenas rhoncus lobortis tellus, quis cursus ipsum posuere eu. Cras vel mi sed nisl vulputate facilisis. Proin aliquam lacus at sagittis fermentum. Donec ut rhoncus enim, id finibus tortor. Phasellus porttitor, nisl quis cursus interdum, orci justo condimentum risus, quis pulvinar dui enim eu metus. Aliquam congue mollis dui, pretium commodo leo. Aliquam tincidunt tellus et ligula tristique fermentum. Aliquam auctor velit condimentum velit rutrum sodales."
}
}
\paper {
#(define fonts
(set-global-fonts
#:music "emmentaler"
#:brace "emmentaler"
#:roman "TeXGyre Schola"
#:factor (/ staff-height pt 20)
))
top-margin = 2 \cm
left-margin = 2 \cm
bottom-margin = 2\cm
right-margin = 2\cm
}
and yes, that's a stupid interface for achieving that purpose.
--
David Kastrup
Re: inconsistent \RemoveEmptyStaves action
jh writes:
> From one project to the next sometimes 'Frenching' a score works and
> sometimes it doesn't
> This is the shortest example I could figure out how to make
> the second system should be just two staves (and using the same
> context etc 5 days ago worked as expected on a different score so this
> was copy pasted)
> \version "2.22.1"
> \header {
> title = "Caucasus"
>composer = "Jay Hamilton"
> copyright = \markup { \tiny \override #'(baseline-skip . 0.5)
> \center-column
> { "CC lic 2.5 some rights reserved Jay Hamilton 2022"
> "see http://creativecommons.org/licenses/by-nd/2.5/;
>} }
>}
> #(ly:set-option 'delete-intermediate-files #t)
> #(set-default-paper-size "letter" )
> #(set-global-staff-size 20)
>
>
> upper = \relative c' {
> \clef treble
> \key c \major
> \time 4/4
> \tempo "andante" 4 = 72
> \numericTimeSignature
> \accidentalStyle forget
> \times 2/3 {g'8 d bes'}\times 2/3 {g d bes'}
>\times 2/3 {g d bes'}\times 2/3 {g d bes'}
>\times 2/3 {a d, c'} \times 2/3 {a d, c'}
>\times 2/3 {a d, c'} \times 2/3 {a d, c'}\break
>\times 2/3 {bes g d'} \times 2/3 {bes g d'}
>\times 2/3 {bes g d'} \times 2/3 {bes g d'}
>es16 bes ges bes es bes ges bes es bes ges bes es bes ges bes\break
>
> }
>
> lower = \relative c {
> \clef bass
> \key c \major
> \numericTimeSignature
> \accidentalStyle forget
> bes'4 c d g,
> \times 2/3 {a8 g fis} d4 \times 2/3 {c8 a c}\times 2/3 {fis g a}
> \times 2/3 {bes8 a g}\times 2/3 {d bes d}\times 2/3 {fis g a} d4
> es4 ges8 [d] c [bes] ges a ~
> }
> three = \relative c {
> \clef bass
> \key c \major
> \numericTimeSignature
> \accidentalStyle forget
>R1*4
>
> }
> four = \relative c {
> \clef "bass_8"
> \key c \major
> \numericTimeSignature
> \accidentalStyle forget
>R1*4
> }
>
>
> \score {
> \context PianoStaff
> <<
> \context Staff = upper \upper
> \context Staff = lower \lower
> \context Staff = three \three
> \context Staff = four \four
> >>
> \layout {
> \context {
> \Staff
>\RemoveEmptyStaves
> }
> }
> \midi { }
> }
> Please point to my stupid errors.
> thanks
> J
File: lilypond-internals.info, Node: PianoStaff, Next: RhythmicStaff, Prev:
PetrucciVoice, Up: Contexts
2.1.24 ‘PianoStaff’
---
Just like ‘GrandStaff’, but the staves are only removed together, never
separately.
--
David Kastrup
Re: LilyPond 2.23.6 released
Jonas Hahnfeld via LilyPond user discussion writes: > Am Mittwoch, dem 09.02.2022 um 09:23 +0100 schrieb Mats Bengtsson: > >> On the other hand, the previous installers can't be installed without >> admin rights either, so the new Zip distribution is at least a step >> in the right direction for Win users without admin rights > > Yes, this is one of the motivations *not* to use an installer. It also > makes having multiple versions and removal of old versions no-brainers > One of the selling points of Frescobaldi is that it can entertain multiple installed versions of LilyPond. -- David Kastrup
Re: Setting relative pitch as a global declaration?
David Wright writes:
> On Wed 09 Feb 2022 at 14:24:14 (+), Valentin Petzel wrote:
>>
>> I think Alasdair does not want to specify relative at toplevel, but
>> he has his voices in multiple consecutive parts, and he wants the
>> whole voice to be relative, instead of each part being separately
>> relative. This can of course simply be done using \relative pitch
>> {\partA \partB ...}.
>
> I think you've misinterpreted "part" as part of a movement, rather
> than part being an instrumental part.
>
> The OP will want to set the music as:
>
> movement1_part1 = { notes, notes, and more notes }
> movement2_part1 = { notes, notes, and more notes }
> movement3_part1 = { notes, notes, and more notes }
>
> to do what they posted, ie,
>
> \relative c { \movement1_part1 \movement2_part1 \movement3_part1 }
>
> This will enable them to set part2 for a high- or low-pitched
> instrument with one modification, and without changing the
> pitch of part1:
>
> \relative c' { \movement1_part2 \movement2_part2 \movement3_part2 }
>
> or
>
> \relative c, { \movement1_part2 \movement2_part2 \movement3_part2 }
I find that a pretty bad idea since changes in \movement1_part1 can
shift the octave of movement2_part1 around. I think it makes more sense
to do octave shifts via \transpose rather than tieing the internals of
one passage to the next passage at a completely different place in the
source.
--
David Kastrup
Re: Setting relative pitch as a global declaration?
Jean Abou Samra writes:
>> Le 09/02/2022 14:43, David Kastrup a écrit :
>>
>> > Though this might not be considered very clean.
>> The word "atrocity" readily suggests itself.
>>
>> I don't think I have thought of using #{ ... \etc #} as kind of a lambda
>> function created with LilyPond before and/or connecting this to
>> toplevel-music-functions now that the functions in there don't need a
>> "parser" argument anymore. So that is a quite appealing piece of code,
>> just that one would wanted to see its power applied for good.
>
>
> Oh, but I have good inspiration for that trick.
>
> https://lists.gnu.org/archive/html/lilypond-user/2021-07/msg00135.html
I am getting old. \transpose is probably not quite as atrocious to use
as \relative, but on the other hand \relative is idempotent so its
effect is limited to things that haven't already been turned into
absolute music explicitly.
We'll call it even.
--
David Kastrup
Re: Setting relative pitch as a global declaration?
Jean Abou Samra writes:
>> Le 09/02/2022 09:23, Lukas-Fabian Moser a écrit :
>>
>> - There's no way to globally declare your input mode to be relative
>
>
> Well ...
>
>
> \version "2.22.1"
>
> #(set! toplevel-music-functions (cons #{ \relative c' \etc #}
> toplevel-music-functions))
>
> { d e f }
>
>
> Though this might not be considered very clean.
The word "atrocity" readily suggests itself.
I don't think I have thought of using #{ ... \etc #} as kind of a lambda
function created with LilyPond before and/or connecting this to
toplevel-music-functions now that the functions in there don't need a
"parser" argument anymore. So that is a quite appealing piece of code,
just that one would wanted to see its power applied for good.
--
David Kastrup
Re: LilyPond 2.23.6 released
Guy Stalnaker writes:
> I can report a change in what I see. This code does not produce an error in
> 2.20 but does in 2.23.6:
>
>
> startParenthesis = {
> \once \override ParenthesesItem.stencils = #(lambda (grob)
> (let ((par-list
> (parentheses-item::calc-parenthesis-stencils grob)))
> (list (car par-list)
> point-stencil )))
> }
>
> endParenthesis = {
> \once \override ParenthesesItem.stencils = #(lambda (grob)
> (let ((par-list
> (parentheses-item::calc-parenthesis-stencils grob)))
> (list point-stencil (cadr
> par-list
> }
>
>
> Error is:
>
> /home/guyst/Dropbox/Documents/Compositions/ResonetInLaudibus/../nak_standard_header.ly:79:19
> <0>: error: bad grob property path
>
> \once \override
>
> ParenthesesItem.stencils = #(lambda (grob)
>
> /home/guyst/Dropbox/Documents/Compositions/ResonetInLaudibus/../nak_standard_header.ly:85:19
> <1>: error: bad grob property path
>
> \once \override
>
> ParenthesesItem.stencils = #(lambda (grob)
>
>
> I've had this in my standard include file for quite some time. What might I
> need to change to remove the error?
You could try running convert-ly on the file to find out.
--
David Kastrup
Re: Font kerning
Valentin Petzel writes:
>> Am Montag, 7. Februar 2022, 22:47:30 CET schrieb:
>>> Valentin Petzel writes:
>>> >> Am Montag, 7. Februar 2022, 21:30:21 CET schrieb:
>>> >>> Thanks to all for your answers. The trick suggested by Valentin
>>> >>> works for me.
>>> >>>
>>> >>> Anyway it looks like there’s no option to directly adjust letter
>>> >>> spacing, something like \kern macro in LaTeX, right?
>>> >
>>> > No. As Lilypond is a music typesetter, not a text typesetter, the text
>>> > typesetting options in Lilypond are quite rudimentary. This means that
>>> > Lilypond has no interface for these things. So kerning in Lilypond markup
>>> > usually means taking two markups and putting them next to each other with
>>> > some (potentially negative) distance.
>>>
>>> Which is pretty much what \kern does in TeX. The difference between
>>> a \kern and \hspace in TeX is that \hspace indicates a possible
>>> breakpoint (and when a break happens there, it will get removed),
>>> and \hspace can take flexible glue specifications. And I am not
>>> sure but \kern may be transparent to hyphenation.
>>>
>>> LilyPond's \hspace takes no flexible glue specifications and cannot
>>> become a breakpoint either, and hyphenation is not a thing. So I
>>> have no idea what your "No." is supposed to mean.
>
> Hello David.
>
> TeX takes care of text output entirely by itself, while Lilypond delegates
> this to Pango. This makes handling certain things quite a bit more awkward in
> Lilypond. So while \hspace does work similarly to \kern it does not really
> have the same function.
>
> In TeX we could for example do
> This is a Test\kern0.2pt word
> for what Lilypond would need
> { This is a \concat { Test \hspace #0.1 word } }
That has nothing to do with how \hspace works but rather how \line
breaks things into pieces. The equivalent to
\markup { This is a Test \hspace #0.1 word }
would be
This is a Test \kern0.2pt\relax word
\concat is LilyPond's way of omitting spaces.
You'll also find that TeX's way of grouping kernable material is rather
awkward, making something like shelf{}full omit the ff ligature only
somewhat reliably: if there is a hyphenation pass over the paragraph in
question, TeX will create the ff ligature in the "reconstitution pass".
> Thus my "no" means to say that there is in fact not such a direct way
> to adjust letter spacing in Lilypond.
--
David Kastrup
Re: Font kerning
Valentin Petzel writes: >> Am Montag, 7. Februar 2022, 21:30:21 CET schrieb: >>> Thanks to all for your answers. The trick suggested by Valentin works for >>> me. >>> >>> Anyway it looks like there’s no option to directly adjust letter spacing, >>> something like \kern macro in LaTeX, right? > > No. As Lilypond is a music typesetter, not a text typesetter, the text > typesetting options in Lilypond are quite rudimentary. This means that > Lilypond has no interface for these things. So kerning in Lilypond markup > usually means taking two markups and putting them next to each other with > some > (potentially negative) distance. Which is pretty much what \kern does in TeX. The difference between a \kern and \hspace in TeX is that \hspace indicates a possible breakpoint (and when a break happens there, it will get removed), and \hspace can take flexible glue specifications. And I am not sure but \kern may be transparent to hyphenation. LilyPond's \hspace takes no flexible glue specifications and cannot become a breakpoint either, and hyphenation is not a thing. So I have no idea what your "No." is supposed to mean. -- David Kastrup
Re: Font kerning
Francesco Napoleoni writes: > In data lunedì 7 febbraio 2022 21:40:05 CET, David Kastrup ha scritto: >> Have you tried negative \hspace ? > > Yes, that’s what Valentin suggested, and indeed it does the trick. So how would you characterise this being any different from \kern ? -- David Kastrup
Re: Font kerning
Francesco Napoleoni writes: > Thanks to all for your answers. The trick suggested by Valentin works for me. > > Anyway it looks like there’s no option to directly adjust letter spacing, > something like \kern macro in LaTeX, right? Have you tried negative \hspace ? -- David Kastrup
Re: How to catch post-events inside chords in an event listener?
Lukas-Fabian Moser writes:
> Folks,
>
> probably I'm being stupid:
>
> \version "2.22"
>
> #(define (test_engraver ctx)
> (make-engraver
> (listeners
> ((tie-event engraver event)
> (format #t "Tie encountered at ~a.\n" (ly:context-current-moment
> ctx))
>
> \layout {
> \context {
> \Voice
> \consists #test_engraver
> }
> }
>
> {
> a4~
> % this one is not seen by the engraver
> a~
> a
> }
>
> What do I have to do to make my custom engraver also see post-events
> (here, a tie, but in my context it's a custom event type) used inside
> chords?
There is no such thing as an event inside chords. Events are broadcast
specific to a timestep and have no association with individual notes.
You'll find the tie event in the 'articulations property of the a~ in
the chord.
Members of 'articulations are broadcast from non-chord notes
(from which they are then removed) iff there is a listener for them,
otherwise they just stay put on the broadcast notes.
Members of 'articulations from chord notes are never broadcast. They
always stay on the notes.
--
David Kastrup
Re: Delay for list posts to arrive
Jean Abou Samra writes: > Hi, > > Lately I've found myself a couple times duplicating answers > already provided on this list by others up to almost three > hours earlier because I had not received these replies yet. > Now the little delay for posts to get in inboxes is a quirk > inherent to mailing lists, but three hours seems a bit much. > I'm wondering: are others experiencing this as well? Well, my mail account is on fencepost.gnu.org and fencepost has been down at least several hours recently, presumably due to updates. I would not be surprised if that has been similar with either the mailing list servers and/or the mail transport server itself for gnu.org. -- David Kastrup
Re: \include inside function
David Wright writes:
> On Tue 01 Feb 2022 at 16:09:01 (+0100), Leo Correia de Verdier wrote:
>>
>> Is there a way to have an \include inside a function?
>> In the attached file includeinfunction.ly the commented out line
>> doesn’t work (probably for some very logical reason, but still
>> unknown to me). Is there a way to work around that and have includes
>> inside functions?
>
> NR § 3.1.5 File structure
>
> At any point in a file, any of the following /lexical/ instructions can be
> entered:
> • \version
> • \include
> [ … ]
>
> (my emphasis)
>
> So it's not going to work, because you can't "call" it.
> It just inserts the contents of the file at that point.
The point of calling \include was between #{ ... #} and nothing in there
inherently gets "called". But you cannot place assignments in there.
--
David Kastrup
Re: \include inside function
Valentin Petzel writes: >> And it still breaks down because at the top level, LilyPond input does >> not reflect a static structure but directs actions, actions that have >> immediate consequences _while_ still reading ahead. > > I do not understand why this matters here? Doesn’t this only matter > while we are parsing the file? You won't get far without parsing the file. > I understand that delayed scheme calls to variables defined in the > subfile poses some challenge, but such things should be rather > uncommon. Feel free to create an implementation. That will apparently be easier than to prove viability to me. -- David Kastrup
Re: \include inside function
Valentin Petzel writes:
> Hello David,
>
> An assignment basically adds a pair (symbol, value) to some assignment table.
> So shouldn’t it be possible to parse a file with a new assignment table and
> then convert this assignment table into a scheme accessible structure?
That's just wild handwaving. Something like
bing = cis'
bing = { $bing 2-2 }
\score {
\bing
}
does not resolve in such a manner since the _structure_ of the
expression containing $bing cannot be resolved without knowing the type
of bing at the time $bing is encountered. You cannot postpone
assignments when parsing at the top level file level.
> I do not mean to say that assignments should not be performed, but
> that they should be performed in a different scope, which we then make
> accessible from the original scope.
That has nothing whatsoever to do with parsing and parsing structures.
> This could also enable some sort of name-spacing. Let’s say we have different
> Ly files that were not written with name-spacing in mind and then we want to
> do
> a project to combine these. Then instead of needing to rename assignment in
> one file we could do something like
>
> fileA = \include "fileA.ly"
> \fileA.score
>
> or something, whatever.
Indeed, whatever all over.
--
David Kastrup
Re: \include inside function
Valentin Petzel writes: >> Since you removed every single bit of context, it's not even possible to >> say anymore what you want to be talking about. > > But I’ve been saying this since the beginning. The idea would be to have a > way > to parse a ly file (or a string) within a different scope, and then make the > scope accessible from the root document as scheme structure. It might not be > viable, but surely not impossible. And it still breaks down because at the top level, LilyPond input does not reflect a static structure but directs actions, actions that have immediate consequences _while_ still reading ahead. -- David Kastrup
Re: \include inside function
Valentin Petzel writes:
>> That's just wild handwaving. Something like
>>
>> bing = cis'
>> bing = { $bing 2-2 }
>> \score {
>> \bing
>> }
>>
>> does not resolve in such a manner since the _structure_ of the
>> expression containing $bing cannot be resolved without knowing the type
>> of bing at the time $bing is encountered. You cannot postpone
>> assignments when parsing at the top level file level.
>
> Yes, but I do not understand how this would be a problem? I’m not at all
> talking about postponing assignment.
Since you removed every single bit of context, it's not even possible to
say anymore what you want to be talking about.
--
David Kastrup
Re: \include inside function
Valentin Petzel writes: > Hi David! > > I suppose it might be useful to have something like a parsing function > that does parse a file internally, but returns a scheme structure > containing all variables, functions, scores, books, whatever defined > in that file. This would make using stuff in a different file much > more clean than the current include method. That's not possible because things like assignments aren't structure but action, and the subsequent interpretation of the file may well depend on those assignments being executed. -- David Kastrup
Re: \include inside function
Leo Correia de Verdier writes:
> Dear list!
>
> Is there a way to have an \include inside a function?
> In the attached file includeinfunction.ly the commented out line
> doesn’t work (probably for some very logical reason, but still unknown
> to me).
Uh, if you write the content of the included file _exactly_ where
\include #filename now is, you get _exactly_ the same error. Your
inclusion works perfectly fine. It's just that the syntax in the file
is not valid syntax inside of #{ ... #}.
If you want to include the file instead at the _top_ level, try
includeFunction = #(define-void-function (filename) (string?)
(ly:parser-include-string (format "\\include ~s"
filename)))
However, depending on the context you use this in, you might get
surprised by just _when_ the inclusion happens.
> Is there a way to work around that and have includes inside functions?
>
> (The function in this case is indeed meaningless, in my real use case
> the function will hopefully construct midi files from the variables in
> the included files combined in different ways)
>
> Thanks a lot!
>
> /Leo
>
> \version "2.23.3"
>
> includeFunction = #(define-void-function (filename) (string?)
> #{ \include #filename #} )
>
> \include "includetest.ily"
>
> % \includeFunction "includetest.ily"
>
> \score { \music }
>
>
--
David Kastrup
Re: Remove My Address from Your Email List
Jean Abou Samra writes: > Le 31/01/2022 à 17:33, David Niles a écrit : >> Good Morning, >> Please remove my email address from ALL OF YOUR MAILINGS. I am not >> interested and do not want to receive them. >> Thank you, >> David Niles >> ekj...@gmail.com > > > > That is not up to the administrator but up to yourself. > Please go to > > https://lists.gnu.org/mailman/listinfo/lilypond-user > > and use the form at the bottom of the page. Alternatively, every single mail from the mailing list contains basic mailing list instructions in the header (if you tell your mail reader to show them). In this case, the relevant line would be: List-Unsubscribe: <https://lists.gnu.org/mailman/options/lilypond-user>, <mailto:lilypond-user-requ...@gnu.org?subject=unsubscribe> In particular clicking on the second link here should in most mail readers set up a message that, if sent, will unsubscribe the sending mailing address from the list. -- David Kastrup
Re: tagGroup question
Simon Albrecht writes: > Thanks, David and Jean, for your replies. I have no intention to > reopen a can of worms here, and I didn’t remember that discussion > (IIRC, that was at a time when I more regularly kept up with all > LilyPond issues). > > Using \keepWithTag a \keepWithTag b \music is very reasonable, > especially considering that I almost exclusively use them either as > toplevelMusicFunctions or wrapping an entire score’s music. On the other hand I am not sure that an interface that I designed myself and still fail to correctly work with is worth keeping. I'll take a look, hopefully not affecting too many scores. -- David Kastrup
Re: tagGroup question
David Kastrup writes:
> Simon Albrecht writes:
>
>> Dear list,
>>
>> I have encountered some unexpected behaviour with tags and
>> tagGroups. In the following example, I thought the two staffs should
>> look the same, even without the \removeWithTag command, but they
>> don’t:
>>
>>
>> \version "2.23.5"
>> % tested with 2.23.5 (guile2-build) and 2.22.0
>>
>> \tagGroup sol,mi
>> \tagGroup withCClefs,noCClefs
>>
>> \keepWithTag mi,noCClefs
>> %\removeWithTag withCClefs
>> <<
>> {
>> \tag mi,withCClefs \clef alto
>> 1
>> \tag mi,noCClefs \clef bass
>> 1
>> }
>> {
>> \tag withCClefs \clef alto
>> 1
>> \tag noCClefs \clef bass
>> 1
>> }
>>>>
>> %%
>>
>>
>> How come the other tagGroup interferes? Is this a bug?
>
> ‘\keepWithTag’ [music] - TAGS (symbol list or symbol) MUSIC (music)
> Include only elements of MUSIC that are tagged with one of the tags
> in TAGS. TAGS may be either a single symbol or a list of symbols.
>
> Each tag may be declared as a member of at most one tag group
> (defined with ‘\tagGroup’). If none of a MUSIC element’s tags
> share a tag group with one of the specified TAGS, the element is
> retained.
>
> Essentially, \keepWithTag #'a \keepWithTag #'b is not the same as
> the more inclusive \keepWithTag #'(a b) even when a and b are from
> different tag groups. That is in line with this documentation that is
> close to the implementation. Whether this is in line with sensible
> expectations of what \tagGroup should achieve, I am not sure.
>
> I do think that I have at times described the effect of \tagGroup as
> making \keepWithTag #'(a b) equivalent to
> \keepWithTag #'a \keepWithTag #'b when a and b belong to different tag
> groups: that would point to even my expectations being more in line with
> yours than with what the implementation does.
Interesting: in the original issue in the bug tracker, the proposed
commit message is a lot more verbose than what ended up eventually in
the repository:
Issue 4083: Implement \tagGroup command
After mulling this over and figuring out that declaring a \tagGroup
will not just keep \keepWithTag of some package unaffected by any tags
otherwise in use but will _also_ hide the use of tags internal to the
package from any outside use of \keepWithTag, I decided to go forward
on this approach.
The given implementation does "nothing special" for \keepWithTag and
\removeWithTag when given tags from different tag groups, or when
defining the same tag group several times (possibly by loading some
code twice). It is arguable that either could warrant a warning.
However, the functionality of \keepWithTag #'(fromgroupI fromgroupII)
cannot easily be provided by anything else.
While I currently cannot imagine a useful application for it myself,
the implemented behavior is logically consistent.
Also contains:
Basic documentation for \tagGroup command
That would imply that I was very much aware at the time of writing this
of the implications. The question is whether
However, the functionality of \keepWithTag #'(fromgroupI fromgroupII)
cannot easily be provided by anything else.
While I currently cannot imagine a useful application for it myself,
the implemented behavior is logically consistent.
really keeps options open that anybody would use, making this behavior
(that cannot be achieved in reasonably simple other ways) desirable.
Problem is that few uses of \keepWithTag #'(fromgroupI fromgroupII) are
likely to intentionally invoke that behavior. Indeed, in my most recent
score under work I find
\keepWithTag layout,pizz %pause %,dingding
With layout and pizz being in different tag groups and the intent being
exactly to be equivalent to \keepWithTag layout \keepWithTag pizz .
So the question is whether retaining this subtle feature (not otherwise
available) is worth its price when not even the author of it is able to
remember how it applies in case anyone would ever need it.
--
David Kastrup
Re: tagGroup question
Simon Albrecht writes:
> Dear list,
>
> I have encountered some unexpected behaviour with tags and
> tagGroups. In the following example, I thought the two staffs should
> look the same, even without the \removeWithTag command, but they
> don’t:
>
>
> \version "2.23.5"
> % tested with 2.23.5 (guile2-build) and 2.22.0
>
> \tagGroup sol,mi
> \tagGroup withCClefs,noCClefs
>
> \keepWithTag mi,noCClefs
> %\removeWithTag withCClefs
> <<
> {
> \tag mi,withCClefs \clef alto
> 1
> \tag mi,noCClefs \clef bass
> 1
> }
> {
> \tag withCClefs \clef alto
> 1
> \tag noCClefs \clef bass
> 1
> }
>>>
> %%
>
>
> How come the other tagGroup interferes? Is this a bug?
‘\keepWithTag’ [music] - TAGS (symbol list or symbol) MUSIC (music)
Include only elements of MUSIC that are tagged with one of the tags
in TAGS. TAGS may be either a single symbol or a list of symbols.
Each tag may be declared as a member of at most one tag group
(defined with ‘\tagGroup’). If none of a MUSIC element’s tags
share a tag group with one of the specified TAGS, the element is
retained.
Essentially, \keepWithTag #'a \keepWithTag #'b is not the same as
the more inclusive \keepWithTag #'(a b) even when a and b are from
different tag groups. That is in line with this documentation that is
close to the implementation. Whether this is in line with sensible
expectations of what \tagGroup should achieve, I am not sure.
I do think that I have at times described the effect of \tagGroup as
making \keepWithTag #'(a b) equivalent to
\keepWithTag #'a \keepWithTag #'b when a and b belong to different tag
groups: that would point to even my expectations being more in line with
yours than with what the implementation does.
--
David Kastrup
Re: Extracting a "score diff" from two [or more] Lilypond sources
Kieren MacMillan writes: >> So? I can assure you my kitchen table is perfectly useful for me even >> though the carpenter did not constrain themselves to use only the kind >> of tools that I myself have in the house. >> >> And frankly, I would not think of paying them for the additional effort >> taken by hobbling themselves in that manner. > > Um… wut? That makes zero sense. An analogy that actually fits what > we're talking about would be a chef who gave you a recipe which is > impossible to execute without an appliance to which you have no > access. > > — Kieren Kieren, just who is the target for which you are planning to keep your tools for extracting version change information for your musicians confined to some set of persons without access to version control and presumably also not to versions other than some marked printed copies? The last commit in the LilyPond codebase from you has been in 2010, and using OpenLilyLib takes installing and updating it via Git, doesn't it? So how are you planning to give those tools not requiring version control to people, and how are they going to get access to versioned compositions to apply them to? I just have problems figuring out the rationale behind that constraint. -- David Kastrup
Re: Extracting a "score diff" from two [or more] Lilypond sources
Kieren MacMillan writes: > Hi Elaine, > >> You're probably not going to appreciate this suggestion, >> because it does not aspire to the auto-magic you desire. >> However, it is clear to me that the best practice for all software >> dev is to use commit messages. > > I do appreciate the detailed and considered response. > > That being said… ;) > > As with most of the programming I do — in Lilypond and otherwise — a > primary goal of mine is to create things that are useful *for the > largest number of people* (not just me). I think it's fair to state > that the vast majority of people using Lilypond don't use version > control. So? I can assure you my kitchen table is perfectly useful for me even though the carpenter did not constrain themselves to use only the kind of tools that I myself have in the house. And frankly, I would not think of paying them for the additional effort taken by hobbling themselves in that manner. -- David Kastrup
Re: Extracting a "score diff" from two [or more] Lilypond sources
Kieren MacMillan writes: > p.s. Motivating use case: > > I'm cranking out scores for my newest musical > (https://www.ccpacanada.com/the-quest/). Rehearsals started on > Tuesday, and changes always come fast and furious during the > workshopping of a brand new piece. Every time I send the Musical > Director an updated score, I would love to not have to list all the > changes (I'm not yet rich or famous enough to have a music assistant > to do that kind of grunt work!), so I'd love to just pass two scores > through a "Music AI" and include that output with the new score. What version control system are you using for your score? It will probably easiest to look at the source code diffs and do a manual summary from those. -- David Kastrup
Re: learning (names of) markup commands in scheme: documentation
Jean Abou Samra writes: > Le 21/01/2022 à 08:57, Bernhard Fisseni a écrit : >> Good morning, >> >> Consequence: There is no collision between an auxiliary function >> CMD and a homonymous markup command \CMD, as they are (CMD ...) and >> (make-CMD-markup ...), respectively, in scheme. > > > Yes, and not only make-CMD-markup, but more importantly > CMD-markup CMD-markup-function > which is the function into which your definition gets turned into, in > charge of doing the markup interpretation. -- David Kastrup
Re: Lilypond's English Horn MIDI instrument is non-transposing?
"James B. Wilkinson" writes: >> On Jan 14, 2022, at 6:37 PM, Valentin Petzel wrote: >> >> ... >> Lilypond uses these GM names, which makes Lilypond a somewhat GM compatible >> source. This means that as long as we use a GM compatible synth everything >> should have the right sound. > > > I was using VLC to play it. Does this mean that VLC is not GM compatible? I > was having to compile it with the tenor voice not transposed in order to get > the MIDI file to play the correct notes. I had to compile again with the > tenor voice transposed to get the notes to print correctly on the page. > > David pointed me to the \transposition keyword, and adding "\transposition f" > to the "\with" clause of the English horn staff fixed the problem. Now I get > correct printed output and a correct MICI file from a single compilation. But > now I have another question making two questions in this post: > 1) why do I need "\transpose f c \tenor" instead of "\transpose f c' > \tenor"? If I use c' it goes an octave too high. \transpose f c means what you write as f gets printed as c . \transpose f c' means what you write as f gets printed as c' . > 2) Is VLC GM compatible. VLC does not play MIDI. You probably have some plugin active that diverts to another synth. Pretty much all of them, given suitable sound fonts, are GM2 compatible since we are talking about a standard more than 20 years old. -- David Kastrup
Re: Lilypond's English Horn MIDI instrument is non-transposing?
"James B. Wilkinson" writes:
> I'm working on an arrangement fordable-reed quartet. Here's the score block:
>
> \score
> {
> \new StaffGroup
><<
> \new Staff = "oboe1" \with { instrumentName = "oboe1" midiInstrument =
> "oboe" }
>{ \clef "treble" \soprano }
> \new Staff = "oboe2" \with { instrumentName = "oboe2" midiInstrument =
> "oboe" }
>{ \clef "treble" \alto }
> \new Staff = "EngHrn" \with { instrumentName = "enghrn" midiInstrument =
> "english horn" } %"english horn"
>{ \clef "treble" \transpose f c \tenor } %the correct
> transposition for EH sounds terrible
> % { \clef "treble" \transpose c c, \tenor } % temporarily down one
> octave; sounds fine
> \new Staff = "bassoon" \with { instrumentName = "bassoon" midiInstrument
> = "bassoon" }
>{ \clef "bass" \bass }
>>>
> \layout { \context { \Staff \consists "Ambitus_engraver" } }
> \midi { \tempo 4 = 80 }
> }
>
>
> If I make it with the English horn part correctly transposed, the MIDI
> sounds terrible. If I make it with the English horn part untransposed,
> it sounds fine. My conclusion is that the midiInstrument "english
> horn" reads its part in C rather than in F. Shouldn't it play the
> notes that a real English horn would?
<https://lilypond.org/doc/v2.22/Documentation/notation/displaying-pitches#instrument-transpositions>
Instrument transpositions
.
When typesetting scores that involve transposing instruments, some parts
can be typeset in a different pitch than the concert pitch. In these
cases, the key of the transposing instrument should be specified;
otherwise the MIDI output and cues in other parts will produce incorrect
pitches. For more information about quotations, see *note Quoting other
voices::.
\transposition PITCH
The pitch to use for ‘\transposition’ should correspond to the real
sound heard when a ‘c'’ written on the staff is played by the
transposing instrument. This pitch is entered in absolute mode, so an
instrument that produces a real sound which is one tone higher than the
printed music should use ‘\transposition d'’. ‘\transposition’ should
_only_ be used if the pitches are _not_ being entered in concert pitch.
Here are a few notes for violin and B-flat clarinet where the parts
have been entered using the notes and key as they appear in each part of
the conductor’s score. The two instruments are playing in unison.
\new GrandStaff <<
\new Staff = "violin" \with {
instrumentName = "Vln"
midiInstrument = "violin"
}
\relative c'' {
% not strictly necessary, but a good reminder
\transposition c'
\key c \major
g4( c8) r c r c4
}
\new Staff = "clarinet" \with {
instrumentName = \markup { Cl (B\flat) }
midiInstrument = "clarinet"
}
\relative c'' {
\transposition bes
\key d \major
a4( d8) r d r d4
}
>>
--
David Kastrup
Re: Transposing pitches in the lilypond file itself?
Alasdair McAndrew writes: >> On Thursday 13 January 2022 01:02:17 (+11:00), David Kastrup wrote: >> >>> Emacs' LilyPond-mode is an abomination in desperate need of >>> maintenance or possibly rewriting from scratch. There is no reason >>> to use it unless you are one of those people who use Emacs for >>> everything (in contrast, the mail/news client I am writing this in >>> would be a reason to switch to Emacs rather than vice versa. As are >>> the LaTeX modes). However, it probably has the only useable MIDI >>> pitch recognition for polyphonic entry like those of accordions. >>> >>> If I needed to batch-convert some input regarding relative/absolute >>> or transpose, I'd likely start up Frescobaldi. Never mind that it >>> isn't the one editor to bring them all and in the darkness bind >>> them. > > Thanks, David - for the heads up about Emacs Lilypond mode! I don't > use Emacs for everything, but I do use it for a lot of things; and > certainly for anything involving text (like Lilypond) it's my standard > go-to. But what is it about the Lilypond mode which is so abominable? It has comparatively fragile indentation that gets thrown off for indiscernible reasons, it does not indent Scheme fragments well, it does not allow for more than a single process under its control (which frequently kills its viewer since it does not start it in the background), it cannot do any manipulation interpreting pitches or lengths (transposing, augmenting, relative/absolute conversion), it doesn't offer support for writing mixed LaTeX/LilyPond stuff (like lilypond-book), it does not offer contextual help even if you have the Info files installed (which nevertheless beat the HTML docs hollow in terms of usability). > I just use it really for note-entering, and for each new piece I start > off with one of my templates. The font-lock minor mode (coloring) is > very helpful. (Also, I'm curious - which Emacs mail system are you > using? I've tried several, but none of them really appealed to me. Gnus. > I'm now using the inbuilt mail system which is part of the Vivaldi > browser. I also agree about LaTeX: I've installed Emacs on my Windows > machine as well because Emacs+auctex works for me better than any > other editor or LaTeX IDE.) Particularly when using preview-latex... -- David Kastrup
Re: Transposing pitches in the lilypond file itself?
Paul Scott writes: > On 1/12/22 11:59, David Kastrup wrote: >> Paul Scott writes: >> >>> On 1/12/22 11:00, David Kastrup wrote: >>>> Paul Scott writes: >>>> >>>>> On 1/12/22 08:33, David Kastrup wrote: >>> (snip) >>>>> Even with the infrequent alignment problem I am quite happy with >>>>> lilypond-mode. >>>> Well, I use it. Just wouldn't call my satisfaction level "quite happy". >>>> Another frequent nuisance is that you cannot recompile without killing >>>> the viewer. >>> That's where I use multiple open windows and alt-tab. One window for >>> emacs, one for xTerm for make commands, etc. and more and one or more >>> for the PDF viewers. >> That doesn't help at all with LilyPond-mode killing the viewers you >> started in LilyPond-mode when you recompile in LilyPond-mode. > Ahh. I start the viewers (currently Zathura) from the command line. > I don't use the lilypond-mode commands for that. The equivalent of "just don't use LilyPond-mode for this, you dork" is not exactly a great endorsement of LilyPond-mode. > Zathura updates when the files get compiled. So do most viewers available for GNU/Linux. But if I have to manage my project-related executables manually from a separate shell anyway, I might as well be using vim. -- David Kastrup
Re: Transposing pitches in the lilypond file itself?
Paul Scott writes: > On 1/12/22 11:00, David Kastrup wrote: >> Paul Scott writes: >> >>> On 1/12/22 08:33, David Kastrup wrote: > (snip) >>> Even with the infrequent alignment problem I am quite happy with >>> lilypond-mode. >> Well, I use it. Just wouldn't call my satisfaction level "quite happy". >> Another frequent nuisance is that you cannot recompile without killing >> the viewer. > > That's where I use multiple open windows and alt-tab. One window for > emacs, one for xTerm for make commands, etc. and more and one or more > for the PDF viewers. That doesn't help at all with LilyPond-mode killing the viewers you started in LilyPond-mode when you recompile in LilyPond-mode. > A reasonably big screen helps. Quite contrary. The complaint was _exactly_ that if you have the necessary screen real estate for keeping tabs on more than one thing that LilyPond-mode still kills off any task it is in control of before starting another. -- David Kastrup
Re: Transposing pitches in the lilypond file itself?
Paul Scott writes:
> On 1/12/22 08:33, David Kastrup wrote:
>> Paul Scott writes:
>>
>>>> On 1/12/22 07:02, David Kastrup wrote:
>>>>> Alasdair McAndrew writes:
>>>>>
>>>>> Emacs' LilyPond-mode is an abomination in desperate need of maintenance
>>>>> or possibly rewriting from scratch. There is no reason to use it unless
>>>>> you are one of those people who use Emacs for everything (in contrast,
>>>>> the mail/news client I am writing this in would be a reason to switch to
>>>>> Emacs rather than vice versa. As are the LaTeX modes). However, it
>>>>> probably has the only useable MIDI pitch recognition for polyphonic
>>>>> entry like those of accordions.
>>>>>
>>>>> If I needed to batch-convert some input regarding relative/absolute or
>>>>> transpose, I'd likely start up Frescobaldi. Never mind that it isn't
>>>>> the one editor to bring them all and in the darkness bind them.
>>>
>>> Can you give examples of what you don't like about Emacs? I've been
>>> happy with it for 20 years. I only use it for editing.
>> There are lots of people who repeatedly tried using Emacs and ditched
>> it, even for some kind of vi clone. I am sympathetic to them (and I can
>> work vi and its clones perfectly well) but I am not one of them.
>>
>> But the LilyPond-mode sucks. Once it has decided on a wrong indentation
>> (and it does not indent embedded Scheme well, and it's one of those
>> things that may throw off its indentation altogether), it steadfastly
>> refuses to revert to the user-given indentation even if what throws it
>> off (wrongly) is pages above.
> I sometimes spend a few minutes fixing the indent problems but that is
> my only complaint which could probably be fixed.
>> Writing chords is one of those things which often throws it off;
>> you need to write < x x x > instead. That's just BS.
> I write and it works.
bop = \drummode {
<< { 4 r \tuplet 3/2 { sn8 8 8 } | } \\
{ bd2\f r4 | }
>>
<< { 4 r \tuplet 3/2 { sn8 8 8 } | } \\
{ bd2\f r4 | }
>>
}
bopII = \drummode {
<< { 4 r \tuplet 3/2 { sn8 8 8 } | } \\
{ bd2\f r4 | }
>>
<< { 4 r \tuplet 3/2 { sn8 8 8 } | } \\
{ bd2\f r4 | }
>>
}
bopIII = \drummode {
<< { 4 r \tuplet 3/2 { sn8 8 8 } | } \\
{ bd2\f r4 | }
>>
<< { 4 r \tuplet 3/2 { sn8 8 8 } | } \\
{ bd2\f r4 | }
>>
}
Seriously?
>> As I said: nothing wrong with Emacs (except for lots of general things
>> that make people go elsewhere, with differing amounts of being relevant
>> in the long run), but LilyPond-mode is an abomination.
>
> Even with the infrequent alignment problem I am quite happy with
> lilypond-mode.
Well, I use it. Just wouldn't call my satisfaction level "quite happy".
Another frequent nuisance is that you cannot recompile without killing
the viewer. AUCTeX (probably some inspiration for LilyPond-mode ages
ago) long ago has fixed that kind of nuisance.
--
David Kastrup
Re: Transposing pitches in the lilypond file itself?
Alasdair McAndrew writes: > Thanks, Guy. > > > I use the Linux Emacs editor (which has a lilypond mode), and there > might be something there, but I was just after a little advice - I > have used Frescobaldi, but for me Emacs is faster and more efficient. Emacs' LilyPond-mode is an abomination in desperate need of maintenance or possibly rewriting from scratch. There is no reason to use it unless you are one of those people who use Emacs for everything (in contrast, the mail/news client I am writing this in would be a reason to switch to Emacs rather than vice versa. As are the LaTeX modes). However, it probably has the only useable MIDI pitch recognition for polyphonic entry like those of accordions. If I needed to batch-convert some input regarding relative/absolute or transpose, I'd likely start up Frescobaldi. Never mind that it isn't the one editor to bring them all and in the darkness bind them. -- David Kastrup
Re: Chemnitzer Linuxtage 2022 Call for Presentations/Participation/Lectures
Jonas Hahnfeld writes: > Am Montag, dem 10.01.2022 um 15:57 +0100 schrieb David Kastrup: >> Jonas Hahnfeld via Discussions on LilyPond development >> writes: >> >> > Am Mittwoch, dem 15.12.2021 um 23:44 +0100 schrieb David Kastrup: >> > > Hi, >> > > >> > > after the "big" Linuxtag event folded, the Chemnitzer Linuxtage are the >> > > largest such event in Germany, typically drawing about 2500-3000 >> > > visitors each year. In 2020, they were forced to fold with something >> > > like a week of advance notice. In 2021, the event was virtual. In >> > > 2022, this will again be the case. >> > > >> > > They have turned the floor plan of the lecture hall building normally >> > > used (the "Orangerie") into a walk-through game that opens up Jitsi >> > > sessions at stands and meeting points and connects to Big Blue Button >> > > sessions in the various lecture rooms. The hallways are, as it was with >> > > the in-person conference, set with project stands where vendors or free >> > > software projects can present their projects and help users and other >> > > interested people with their problems or their questions. >> > > >> > > This would be an opportunity to set up a LilyPond stand, along with >> > > posters, presentations and people manning the stand, without actually >> > > involving traveling to Chemnitz. Video conference capable hardware is >> > > all that is required, as is a typical web browser. >> > >> > sorry for the late reply; I'd be willing to participate in the event >> > and be present at the LilyPond stand. Let me know if you need >> > something for the submission, if you haven't done so already. >> >> Ok, I messed this one up. Entry deadline is today. > > Not sure, the submission form says 16th, while the latest newsletter > and Twitter says 10th. Maybe they silently extended the deadline? I got an Email today: they extended the deadline for talks/workshops. Looking at the website it would seem that the deadline for presentations _also_ has been extended to the 16th. So yes, it's not quite the last minute. >> The problem with the stand is that it's sort of like a real stand: >> you need to do posters and possibly other representation in advance >> in order to attract visitors to engage (get close enough in the >> virtual walk to enter the Jitsi video conference), you really need to >> have 3 or 4 minimum serving the stand because a good part of the time >> personnel will be on standby and/or just talking with one another and >> for 2 days you want to have people available for passersby, the >> questions will not be interesting programming questions or modern >> composers looking for the best of the best but more in line of "how >> do I even set this up?" or "I tried entering stuff for my band and >> rather ended up using MuseScore" or "how do I input MIDI to LilyPond" >> and so on. >> >> And visitors will quite more often than not be German-language (since >> many people return to this conference that know the people and >> organisation and that means that its location in Germany does make quite >> a difference even in this second virtual year), even though official >> conference languages are both German and English. So it might have made >> more sense to look for volunteers in German-speaking forums but I don't >> actually frequent those. >> >> So what would be necessary today, if at all, is to conscript a few >> people willing to do some of the leadup work and then serve at the >> virtual stand on the conference date itself. Without the number of >> people actually able to do pretty much everything involved with a real >> stand job apart from travel (and sadly, apart from participating with >> the great "thank you" dinner that was customary for all active >> participants with the in-person conferences), it would not make sense to >> compete for the limited floor space. >> >> Um, yeah, that's basically it. >> >> Do we get there? > > Not sure it makes sense with two people, unless you received more > answers privately. I am quite sure that it does not make sense with just two people, in particular since I am planning on holding talk(s) and if those get accepted that will likely put me out for stand duty almost completely as I'll need time to ensure my setup will work for the actual talks. > We shouldn't be spending the entire weekend in front of ours PCs... Frankly, that would not be much of a change to my usual routine... But again: I don't think it makes sense to even try with just two persons. There should be enough that it is possible to comfortably take turns. -- David Kastrup
Re: Chemnitzer Linuxtage 2022 Call for Presentations/Participation/Lectures
Jonas Hahnfeld via Discussions on LilyPond development writes: > Am Mittwoch, dem 15.12.2021 um 23:44 +0100 schrieb David Kastrup: >> Hi, >> >> after the "big" Linuxtag event folded, the Chemnitzer Linuxtage are the >> largest such event in Germany, typically drawing about 2500-3000 >> visitors each year. In 2020, they were forced to fold with something >> like a week of advance notice. In 2021, the event was virtual. In >> 2022, this will again be the case. >> >> They have turned the floor plan of the lecture hall building normally >> used (the "Orangerie") into a walk-through game that opens up Jitsi >> sessions at stands and meeting points and connects to Big Blue Button >> sessions in the various lecture rooms. The hallways are, as it was with >> the in-person conference, set with project stands where vendors or free >> software projects can present their projects and help users and other >> interested people with their problems or their questions. >> >> This would be an opportunity to set up a LilyPond stand, along with >> posters, presentations and people manning the stand, without actually >> involving traveling to Chemnitz. Video conference capable hardware is >> all that is required, as is a typical web browser. > > sorry for the late reply; I'd be willing to participate in the event > and be present at the LilyPond stand. Let me know if you need > something for the submission, if you haven't done so already. Ok, I messed this one up. Entry deadline is today. The problem with the stand is that it's sort of like a real stand: you need to do posters and possibly other representation in advance in order to attract visitors to engage (get close enough in the virtual walk to enter the Jitsi video conference), you really need to have 3 or 4 minimum serving the stand because a good part of the time personnel will be on standby and/or just talking with one another and for 2 days you want to have people available for passersby, the questions will not be interesting programming questions or modern composers looking for the best of the best but more in line of "how do I even set this up?" or "I tried entering stuff for my band and rather ended up using MuseScore" or "how do I input MIDI to LilyPond" and so on. And visitors will quite more often than not be German-language (since many people return to this conference that know the people and organisation and that means that its location in Germany does make quite a difference even in this second virtual year), even though official conference languages are both German and English. So it might have made more sense to look for volunteers in German-speaking forums but I don't actually frequent those. So what would be necessary today, if at all, is to conscript a few people willing to do some of the leadup work and then serve at the virtual stand on the conference date itself. Without the number of people actually able to do pretty much everything involved with a real stand job apart from travel (and sadly, apart from participating with the great "thank you" dinner that was customary for all active participants with the in-person conferences), it would not make sense to compete for the limited floor space. Um, yeah, that's basically it. Do we get there? -- David Kastrup
Re: Feedback wanted: syntax highlighting in the LilyPond documentation
J Martin Rushton writes: > Interesting Aaron, but I do note that the paper is from 1983 and didn't > catch on. I wonder if there is a reason for that? I've saved the > paper to read later. Personally I don't know of a single language that > is happy with word processor output as source code, but then I may be > proved wrong. Knuth seems to be addressing issues that have been > effectively bypassed by the rise of object orientated code. I was > trained in a macro assembler (VAX-Macro) and am well aware of their > advantage for repeated idioms, but if they are just another layer on > the top they can merely double the size of the language to master. > > In passing, although Knuth uses variable width fonts in the first six > pages, I note that as soon as he starts to give firm code on page 7 > onwards he uses fixed width! Uh, you are talking about "D. HOW THE EXAMPLE WAS SPECIFIED" which displays the macros used for typesetting the Literate Programming example. That's sort of like complaining that someone lauding some computer language bootstraps his compiler from a different system. Knuth has written both TeX and METAFONT entirely in his WEB programming system for Literate Programming. I have the printed book for TeX. > > On Tue, 2022-01-04 at 05:10 -0800, Aaron Hill wrote: >> On 2022-01-04 4:19 am, J Martin Rushton wrote: >> > Sorry to disagree, but fixed pitch is _so_ much easier to lay out >> > in an >> > editor. Documentation flows nicely with variable pitch and fancy >> > hidden formats, but for code (and Lily's input is a programming >> > language) you just want the plain line-by-line ASCII. It is, as >> > you >> > say, industry standard; and that is for a good reason. >> >> As a counterpoint, Knuth's work with literate programming [1] showed >> it >> was possible to have typographically beautiful setting of code for >> use >> in print. His style largely used proportional fonts though some >> elements were still rendered in fixed width to provide useful >> contrast. >> While Knuth's approach is not perfect for every language, I argue >> the >> vast majority of programming books out there really should have >> followed >> suit. Editors (the people, not programs) seem to struggle with >> fixed-width typefaces, and typos were abundant. >> >> Going beyond printed documentation, some IDEs like Source Insight >> enabled and encouraged programmers to use proportional fonts, where >> horizontal alignment was something handled by the system not the >> programmer. Though I do concede this was probably a novelty, seeing >> as >> these days terminals and editors still rely on fixed pitch. >> >> [1]: http://www.literateprogramming.com/knuthweb.pdf >> >> >> -- Aaron Hill -- David Kastrup
Re: Feedback wanted: syntax highlighting in the LilyPond documentation
Flaming Hakama by Elaine writes:
> In this sense, it seems like the place that has the most potential use
> for helping people distinguish different data types is where the
> syntax is the most complicated and dense, which is in music entry.
>
> The ability to quickly distinguish articulations, dynamics, notes, and
> durations seems like it would probably be most useful to people
> reading examples in docs, since that is the most unusual aspect of
> lilypond syntax.
I find splitting a8 into different colors about as helpful for reading
music as coloring note stems differently would be for reading score
sheets: there is a standard place they are attached to anyway and there
is no particular reason to look elsewhere.
It would be much more useful to highlight note lengths separated by
space but still common to a preceding note or rest, like
\drummode { bd4 r r 4. 8 }
where the 4. is sucked into the second r likely unintentionally.
Highlighting this is helpful. When there is a general "angry fruit
salad" flavor pervading the highlighting with lots of colors everywhere,
there just is not a lot of attention one can draw to actually important
things.
--
David Kastrup
Re: Feedback wanted: syntax highlighting in the LilyPond documentation
Jean Abou Samra writes: > Hi all, > > There is an ongoing proposal to add syntax highlighting > in LilyPond's documentation. Since it is a notable change > to the documentation reading experience, user feedback would > be appreciated. You can browse a syntax-highlighted version > of the notation manual here: > > http://abou-samra.fr/highlighting-demo/notation/index.html > > For comparison, this is the current notation manual: > > https://lilypond.org/doc/v2.23/Documentation/notation/index.html > > The main questions are: what do you think of the principle? > And is the color scheme good enough? I just followed the discussion without much attention because I did not think that it would affect me whether or not there was syntax highlighting. That probably was a mistake. Taking a random example: There is a wild mixture of colors and font styles without apparent rhyme or reason. I don't see that it helps legibility or conveys any useful categories. I cannot even figure out what it thinks it is doing. \layout, \context, \remove are reserved words in the syntax and are printed in boldface and black. So is \override which is printed in normalface blue, like \relative and \repeat. But \relative is a music function while \repeat is a reserved word. Beam.breakable is printed in red while unfold is printed in blue. There is apparently a large collection of colors and some font styles but the application appears rather haphazard, being neither systematically related to the actual category of the tokens nor to their function in user input. There does not appear to be a coherent payback for the inherent lowering of readability (and printability) from the lower contrast of colored passages. What is the information you want to convey better? -- David Kastrup
Re: Updating alists
Jean Abou Samra writes:
> Le 30/12/2021 à 23:04, Lukas-Fabian Moser a écrit :
>> Hi Jean,
>>
>>>
>>> Both of these cases seem to work the same as in
>>> current versions if I do
>>>
>>> [...]
>>>
>>> SCM
>>> assq_tail (SCM key, SCM alist, SCM based_on = SCM_EOL)
>>> {
>>> - for (SCM p = alist; !scm_is_eq (p, based_on); p = scm_cdr (p))
>>> + for (SCM p = alist; scm_is_pair (p) && scm_is_pair (scm_car (p))
>>> && !scm_is_eq (p, based_on); p = scm_cdr (p))
>>> {
>>> if (scm_is_eq (scm_caar (p), key))
>>> return p;
>>
>> Thanks! This seems to be a sensible precaution anyway, as it only
>> changes a certain crash into returning #f. So it might be sensible
>> to make this change anyway?
>
>
> Turns out that you can already trigger the
> crash in current versions with
>
> \version "2.23.5"
>
> x = 0
> x.y.z = 1
That's not what I call a crash. That triggers a Scheme error.
lilypond /tmp/bab.ly
GNU LilyPond 2.23.5 (running Guile 1.8)
Processing `/tmp/bab.ly'
Parsing.../usr/local/share/lilypond/2.23.5/scm/lily/lily.scm:978:21: In
procedure ly:parse-file in expression (ly:parse-file file-name):
/usr/local/share/lilypond/2.23.5/scm/lily/lily.scm:978:21: Wrong type
(expecting pair): 0
And frankly, I don't see something wrong with that. Could use a better
error locator, sure. But it's not the same as a core dump.
--
David Kastrup
Re: Updating alists
Lukas-Fabian Moser writes:
> Hi Jean,
>
>>
>> Both of these cases seem to work the same as in
>> current versions if I do
>>
>> [...]
>>
>> SCM
>> assq_tail (SCM key, SCM alist, SCM based_on = SCM_EOL)
>> {
>> - for (SCM p = alist; !scm_is_eq (p, based_on); p = scm_cdr (p))
>> + for (SCM p = alist; scm_is_pair (p) && scm_is_pair (scm_car (p))
>> && !scm_is_eq (p, based_on); p = scm_cdr (p))
>> {
>> if (scm_is_eq (scm_caar (p), key))
>> return p;
>
> Thanks! This seems to be a sensible precaution anyway, as it only
> changes a certain crash into returning #f. So it might be sensible to
> make this change anyway?
Uh what? assq_tail is exclusively used on internal data structures.
There is no "certain crash" without internal data structures being
corrupted and it seems counterproductive to expend additional
performance in order to hide that internal data structures have been
corrupted.
> I'm a bit surprised about the remark in the code stating that the
> choice not to coalesce multiple override's was made to save the cost
> of detecting them, as it does not seem to be a code path used heavily
> at all.
Overrides of subproperties are used pretty extensively in some newer
code.
Maybe it would make sense to check where code is being used before
trying to change it?
--
David Kastrup
Re: Updating alists
Jean Abou Samra writes: > Le 30/12/2021 à 12:36, Lukas-Fabian Moser a écrit : >> It's much worse than that: It's not the first time _I've_ been >> tripped up by this (previously it was with sort!). I'll just have to >> write 100 copies of >> >> "The exclamation mark in something! does not mean the function is >> guaranteed to make the desired change in-place." >> >> on my wall. > > > :-) > > For assoc-set! and friends, I actually wonder why this > is since when the function has exhausted the alist in > its search for a matching pair, it could well set the > last cdr to add the new pair at the end. An empty list does not have a last cdr. -- David Kastrup
Re: point-and-click default
Lukas-Fabian Moser writes: > Hi David, >> I've been using Lilypond for a few years, and only yesterday learned >> about the point-and-click feature in pdf output. In particular, I had >> no idea that by default Lilypond includes absolute pathnames to local >> source files on my system as metadata in the pdf output files. So when >> I uploaded a couple of files to IMSLP recently, that metadata was >> available for all to see. > > The Notation Reference states > (https://lilypond.org/doc/v2.23/Documentation/usage/configuring-the-system-for-point-and-click): > > "Point and click functionality is enabled by default when creating PDF > or SVG files." > > "Note: You should always turn off point and click in any LilyPond > files to be distributed to avoid including path information about your > computer in the PDF file, which can pose a security risk." > > I agree that these statements make for a gloomy combination by today's > standards of increased awareness for computer security issues. > > Wouldn't it be more reasonable to switch point-and-click off by > default? My personal idea would be to use relative links anyway, but that might possibly not work with the kind of "URL helper" setup that typically ends up calling lilypond-invoke-editor . -- David Kastrup
Re: Updating alists
David Kastrup writes:
> For stuff like
>
>
> midiDrumPitches.ridecymbal = fis,,
> midiDrumPitches.ridecymbala = b
> midiDrumPitches.ridecymbalb = a
> midiDrumPitches.crashcymbal = g
>
>
> \midi
> {
> \context {
> \Score
> drumPitchTable = #(alist->hash-table midiDrumPitches)
> }
> }
>
> you'll get across-session bleed of assignments when making them
> destructive. Another option is, of course, to do what amounts to an
> in-place modification of a structural copy.
As a note aside regarding this code excerpt: we should really support
more than just the default drum kit of the MIDI2.0 standard. The
standard defines something like 10 different drum kits.
And as a note very much aside: an arranger manual from Ketron confused
me without end with a "special parameter" SysEx entry (apparently a
translation oversight) listed as "selezione mappa batteria" with the
possibilities "new MS series" and "old MS series" because the obvious
translation "battery" is also corroborated by web translators. I think
it was at least a year after I first puzzled over this entry that I
thought of the different meaning "battery" may have in English (and
"Batterie" in German hasn't) to figure out the manual was talking about
a drum kit selection.
--
David Kastrup
Re: Updating alists
Lukas-Fabian Moser writes:
> Another question: With the (hopefully) upcoming changes in the
> script-alist structure (using symbols instead of strings as keys),
> we're quite close to being able to simply do
>
> \version "2.23.6"
>
> myScripts = \default-script-alist
> myScripts.tenuto.padding = 5
>
> \layout {
> \context {
> \Score
> scriptDefinitions = #myScripts
> }
> }
>
> {
> a--
> }
>
> (One might also skip defining a new variable and instead change
> default-script-alist directly, but it has to be re-read in a \layout
> block anyway.)
>
> But at the moment, this does not work because the changed key is not
> being replaced in the alist but added at the beginning.
Why would that not work?
> If I see things correctly, this is the remark about "not coalescing
> multiple overrides of the same property" in nested_property_alist(...)
> in ily/nested-property.cc.
>
> Re-enabling the outcommented branch in that function (taking care to
> use assoc_tail instead of assq_tail and correcting the order of
> arguments to that call) basically works, but there's trouble ahead in
> the case where one does
>
> variable.entry = 15
> variable.entry.first = #'i-ve-decided-i-want-a-sublist-after-all
>
> which unfortunately is what happens if one \override's a nested
> property given by a callback
> (e.g. VerticalAxisGroup.staff-staff-spacing), or worse
>
> variable.entry = #'(some . pair)
> variable.entry.first = #'i-ve-decided-i-want-a-sublist-after-all
>
> since an entry that is a pair looks like the beginning of a sublist.
>
> On the other hand, I would expect people who are using
>
> Violin.I = { \someMusic }
> Violin.I = { \someNewMusic }
>
> would indeed like to be their first definition to actually be replaced
> (even if using \Violin.I in a score happens to produce only the most
> recent entry).
>
> Thoughts?
For stuff like
midiDrumPitches.ridecymbal = fis,,
midiDrumPitches.ridecymbala = b
midiDrumPitches.ridecymbalb = a
midiDrumPitches.crashcymbal = g
\midi
{
\context {
\Score
drumPitchTable = #(alist->hash-table midiDrumPitches)
}
}
you'll get across-session bleed of assignments when making them
destructive. Another option is, of course, to do what amounts to an
in-place modification of a structural copy.
--
David Kastrup
Re: \omit-ing a specific type of Script [globally or via edition-engraver]
Kieren MacMillan writes:
> Hi all,
>
> Given
>
> \version "2.21"
> { \omit Script c''1^\fermata_\espressivo }
>
> obviously both Script grobs will be omitted; same, of course, with
>
> \version "2.21"
> \layout { \context { \Score \omit Script } }
> { c''1^\fermata_\espressivo }
>
> Is there a way (e.g., via callback or improved \omit function
> definition) to make \omit more surgical? For example, can one
> effectively say
>
> \omit #'(fermata) Script
>
> so that only fermatas get omitted?
>
> Thanks,
> Kieren.
Sort of butt-ugly:
\version "2.21"
\layout {
\context { \Score
\override Script.stencil =
#(grob-transformer 'stencil
(lambda (grob default)
(and (not (string=?
(ly:event-property (event-cause grob)'articulation-type)
"fermata"))
default)))
}
}
{ c''1^\fermata_\espressivo }
--
David Kastrup
Re: global alignment tweak for ChordName
Jean Abou Samra writes: > [Valentin] >> Hello Jean, hello David, hello Kieren, >> >> you should even be able to write (if sten (ly:stencil-extent sten)), >> as the stencil should always be a stencil or #f. > > > The two universally accepted values for any property > regardless of the predicate are #f and '(), so it > may still be '(), which is why checking with specific > predicates like this is often used in LilyPond's > source. '() is a bit of an ugly cookie since it for some reason has been chosen to be the default for unset properties (seems like a Lisp rather than Scheme idea to me) but shouldn't be used by users for stuff not formally fitting the predicate. In my handwavy impression of trying to sort-of guess unwritten coding conventions. -- David Kastrup
Re: global alignment tweak for ChordName
Valentin Petzel writes: > Hello Jean, hello David, hello Kieren, > > you should even be able to write (if sten (ly:stencil-extent sten)), > as the stencil should always be a stencil or #f. The return value will still be neither #f nor a dimension unless you replace "if" with "and". -- David Kastrup
