Re: Question about \include options
Aloha. I kind of suspected that this was a Scheme-ism but didn't dig into it (yet). I used to progam Lisp but know nothing about Scheme. Perhaps it's so fundamental to the Core group that it's 'duh' but that's not the case for the rest of us (me). Of course, booleans would be fundamental but I tend to interpret alpha as a kind of macro command. So it didn't occur to me that it would be be a boolean value. Mahalo for the follow-up. Appreciate your effort. J. On 1/8/24 20:38, Werner LEMBERG wrote: It's true that special characters can cause inconsistent results in almost anything but if you're searching Documentation for a command that includes them, you expect the search to be 'complete'; i.e., encompassing all possibities. The thing is that `#f` and `#t` are nothing special; they are part of Scheme, and you learn them in lesson one, so to say. However, the Notation Reference isn't an introduction to Scheme, thus it is not feasible to really document such fundamental elements. Anyway, I've added index entries to the Notation Reference and the Learning Manual for `#f` and `#t`. https://urldefense.com/v3/__https://gitlab.com/lilypond/lilypond/-/merge_requests/2230__;!!Mih3wA!CSSDx3tfKA07_Dlu8t6PXaus9A1ynPmgQGAVCwFoDwZzdvyQeDoGSu3fi_l64xhgEd7AFwg$ Werner -- John Helly / San Diego Supercomputer Center / Scripps Institution of Oceanography https://www.sdsc.edu/~hellyj / 808 205 9882 / 760 8408660
Re: Question about \include options
> It's true that special characters can cause inconsistent results in > almost anything but if you're searching Documentation for a command > that includes them, you expect the search to be 'complete'; i.e., > encompassing all possibities. The thing is that `#f` and `#t` are nothing special; they are part of Scheme, and you learn them in lesson one, so to say. However, the Notation Reference isn't an introduction to Scheme, thus it is not feasible to really document such fundamental elements. Anyway, I've added index entries to the Notation Reference and the Learning Manual for `#f` and `#t`. https://gitlab.com/lilypond/lilypond/-/merge_requests/2230 Werner
Re: Question about \include options
> See for example http://lilypond.org/notation.html, which you reach > by clicking on "details of Notation" at > http://lilypond.org/manuals.html. Could anyone please come up with > a better formulation than "details of ...", since it's far from > intuitive what such a link might contain. Perhaps simply replacing '(details of ...)' with '(more)'? Werner
Re: Help with correct pitch after function call within \relative
Artur Dobija writes: > Dear Experts, > > I am working on writing my own function which combines several notes into > one custom symbol (ligature). > (For the context, I now about Mensural_ligature_engraver, but I want to > create something that will allow for more flexibility, as I try to engrave > symbols as close to one of different manuscripts from different eras and by > different hands) > > My code is like: > \relative { a \customLigatura { b c d } f } > > In my approach, I want to remove all the notes except the first, which will > receive the ligature stencil. I can't figure out your function details, but assuming you have sequential music mus that should (in \relative) follow relative rules but only have the first note affect the sequence, you would wrap it in (make-relative (mus) (make-music 'EventChord mus) ...) This works by casting the expression to an EventChord before running it through the \relative wringer (in case this occurs in \relative) but making the permanent effect on \relative come from the first element. The ... itself is never seen by \relative, only the EventChord is. The result can, of course, end up something that isn't a valid chord but it is only used for passing through \relative and then thrown away. -- David Kastrup
Re: Question about \include options
Aloha Carl. Yes, I have read most of the manuals and have created ~12 scores over the past few years but LP is so vast that there seems to be no end of interesting things I don't understand or can't find. It's a truly amazing piece of work and my ship is so small. The point I am trying to communicate is not antagonistic, just trying to suggest something that might be helpful to others as well as me. If there are others out there who have trouble with such searches while the keepers of the keys think otherwise, then there's potential for a lot of wasted time for everyone. If this is not helpful feedback, please feel free to ignore and I'll go silent. J. On 1/8/24 13:07, Carl Sorensen wrote: On Mon, Jan 8, 2024 at 3:29 PM John Helly wrote: Aloha K. I go to the LP home page, using that search box (upper right), type #f and this is what is returned. I can send a video if you'd find it helpful.: John, It looks like the reference Kieren found is the next one down on your list in the enclosed image (just off the page). Have you read the Learning Manual? The recommended way to get up to speed with lilypond is not to try to set some piece of music yourself, but to first read through the learning manual. Try out the examples in the LM. Then, after you have the LM in your working memory, you can move onto using the Notation Reference and the Internals Reference to help you set that challenging score. If you are trying to understand generalities, rather than specifics, it's almost always best to look first in the Learning Manual. If you don't have the Learning Manual in mind, it's really hard to get up to speed on LilyPond. HTH, Carl -- John Helly / San Diego Supercomputer Center / Scripps Institution of Oceanography https://www.sdsc.edu/~hellyj / 808 205 9882 / 760 8408660
Re: Help with correct pitch after function call within \relative
Artur Dobija writes: > Dear Lilypond-user, > I sent this mail to the wrong mail, I should have send it to > lilypond-user-requ...@gnu.org ! Sorry! No, you sent it to the right address. lilypond-user-request is the address for sending list server commands. Send it an Email with "help" in the body and it will tell you what it can do for you. -- David Kastrup
Re: Question about \include options
On Mon, Jan 8, 2024 at 3:29 PM John Helly wrote: > Aloha K. > > I go to the LP home page, using that search box (upper right), type #f and > this is what is returned. I can send a video if you'd find it helpful.: > > John, It looks like the reference Kieren found is the next one down on your list in the enclosed image (just off the page). Have you read the Learning Manual? The recommended way to get up to speed with lilypond is not to try to set some piece of music yourself, but to first read through the learning manual. Try out the examples in the LM. Then, after you have the LM in your working memory, you can move onto using the Notation Reference and the Internals Reference to help you set that challenging score. If you are trying to understand generalities, rather than specifics, it's almost always best to look first in the Learning Manual. If you don't have the Learning Manual in mind, it's really hard to get up to speed on LilyPond. HTH, Carl
Re: Help with correct pitch after function call within \relative
Dear Lilypond-user, I sent this mail to the wrong mail, I should have send it to lilypond-user-requ...@gnu.org ! Sorry! Best, Artur Dobija pon., 8 sty 2024 o 23:56 Artur Dobija napisał(a): > Dear Experts, > > I am working on writing my own function which combines several notes into > one custom symbol (ligature). > (For the context, I now about Mensural_ligature_engraver, but I want to > create something that will allow for more flexibility, as I try to engrave > symbols as close to one of different manuscripts from different eras and by > different hands) > > My code is like: > \relative { a \customLigatura { b c d } f } > > In my approach, I want to remove all the notes except the first, which > will receive the ligature stencil. > I need to *remove* them, not only hide, because if they are still there, > they still heavily affect the spacing in unexpected ways! > What I ask you is: how to *remove* notes "c" and "d" in such a way, that > it would not mess up the relative mode and think, that the note "f" is > calculated from the note "d" (otherwise it will be octave lower)? The > function is agnostic of the pitch before and pitch after. > > What I tried: > – \resetRelativeOctave > – setting to-relative-callback note property to ##f > > customLigatura = > #(define-music-function > (music) > (ly:music?) > > (let ((notes (list)) ; notes participating in ligature creation: pitch, > duration, shape (square, punctum, obliqua, pes, ) > (total-duration (make-duration-of-length (ly:music-length music > > ; get all those notes only that will form ligature's stencil > (for-some-music > (lambda (m) >(if (equal? (ly:music-property m 'name) 'NoteEvent) > (set! notes >(append notes > (list (make-music > 'NoteEvent > 'pitch (ly:music-property m 'pitch) > 'duration (ly:music-property m 'duration) > 'mensural-ligature-shape (ly:music-property m > 'mensural-ligature-shape) > #f)) > music) > > #{ > \once \override MensuralVoice.NoteHead.stencil = > #ly:text-interface::print > \once \override MensuralVoice.NoteHead.text = \markup \translate > #'(0 . -0.5) "Ligatura" % this will be my stencil. > > % only the first note with new stencil must be printed > #(make-music > 'NoteEvent > 'duration total-duration > 'pitch (ly:music-property (list-ref notes 0) 'pitch)) > > %{ >What goes here to trick the relative mode to think > that it must calculate the pitch from the LAST note > (and not the given note)? >something like: \countRelativeFrom d > > I tried: > (ly:make-music-relative! music (ly:make-pitch > -1 > (quotient > (ly:pitch-steps > (ly:make-pitch 1 0)) > 2))) > \resetRelativeOctave #(last (music-pitches music)) > %} > #})) > > % TESTS > << > \new MensuralStaff \new MensuralVoice \relative { \clef F g,1 \ligatura { > a a' c,, g''} a } > \new MensuralStaff \new MensuralVoice \relative { \clef F g,1 a a' c,, g'' > a } > >> > << > \new MensuralStaff \new MensuralVoice \relative { a1 \ligatura { b c d } f > } > \new MensuralStaff \new MensuralVoice \relative { a1 b c d f } > >> > > % ArturJD, Engraving Chant, https://www.instagram.com/engraving.chant/ > >
Help with correct pitch after function call within \relative
Dear Experts, I am working on writing my own function which combines several notes into one custom symbol (ligature). (For the context, I now about Mensural_ligature_engraver, but I want to create something that will allow for more flexibility, as I try to engrave symbols as close to one of different manuscripts from different eras and by different hands) My code is like: \relative { a \customLigatura { b c d } f } In my approach, I want to remove all the notes except the first, which will receive the ligature stencil. I need to *remove* them, not only hide, because if they are still there, they still heavily affect the spacing in unexpected ways! What I ask you is: how to *remove* notes "c" and "d" in such a way, that it would not mess up the relative mode and think, that the note "f" is calculated from the note "d" (otherwise it will be octave lower)? The function is agnostic of the pitch before and pitch after. What I tried: – \resetRelativeOctave – setting to-relative-callback note property to ##f customLigatura = #(define-music-function (music) (ly:music?) (let ((notes (list)) ; notes participating in ligature creation: pitch, duration, shape (square, punctum, obliqua, pes, ) (total-duration (make-duration-of-length (ly:music-length music ; get all those notes only that will form ligature's stencil (for-some-music (lambda (m) (if (equal? (ly:music-property m 'name) 'NoteEvent) (set! notes (append notes (list (make-music 'NoteEvent 'pitch (ly:music-property m 'pitch) 'duration (ly:music-property m 'duration) 'mensural-ligature-shape (ly:music-property m 'mensural-ligature-shape) #f)) music) #{ \once \override MensuralVoice.NoteHead.stencil = #ly:text-interface::print \once \override MensuralVoice.NoteHead.text = \markup \translate #'(0 . -0.5) "Ligatura" % this will be my stencil. % only the first note with new stencil must be printed #(make-music 'NoteEvent 'duration total-duration 'pitch (ly:music-property (list-ref notes 0) 'pitch)) %{ What goes here to trick the relative mode to think that it must calculate the pitch from the LAST note (and not the given note)? something like: \countRelativeFrom d I tried: (ly:make-music-relative! music (ly:make-pitch -1 (quotient (ly:pitch-steps (ly:make-pitch 1 0)) 2))) \resetRelativeOctave #(last (music-pitches music)) %} #})) % TESTS << \new MensuralStaff \new MensuralVoice \relative { \clef F g,1 \ligatura { a a' c,, g''} a } \new MensuralStaff \new MensuralVoice \relative { \clef F g,1 a a' c,, g'' a } >> << \new MensuralStaff \new MensuralVoice \relative { a1 \ligatura { b c d } f } \new MensuralStaff \new MensuralVoice \relative { a1 b c d f } >> % ArturJD, Engraving Chant, https://www.instagram.com/engraving.chant/
Re: Question about \include options
Aloha J-A. Excellent. That's a good place but I don't see the #t,f. Am I missing it? I'd like to suggest placing a link to the Index in the Manuals area (https://lilypond.org/doc/v2.23/Documentation/web/manuals.html). This seems to be the /de facto/ top of the Documentation tree even though it's not in the TOC hierarchy where you can find the Index. Re: Godel's: As you likely know, that's about asking questions from within a system that can't be answered within the system. This just needs an index entry and an obvious way to find the Index. J. On 1/8/24 12:14, Jean Abou Samra wrote: Le lundi 08 janvier 2024 à 12:04 -1000, John Helly a écrit : My default search engine is Google but I've also tried DuckDuckGo and Bing with similar, but different, results. So, this problem falls into a use-case that I usually call 'the completeness and consistency of a search'. Is there an analogue of Gödel's theorem for search engines? IMHO, one 'simple' way around this would be to have a complete index somewhere in the Documentation tree. This? https://lilypond.org/doc/v2.24/Documentation/notation/lilypond-index Ok, these specific terms are missing but it goes a long way already. -- John Helly / San Diego Supercomputer Center / Scripps Institution of Oceanography https://www.sdsc.edu/~hellyj / 808 205 9882 / 760 8408660
Re: Question about \include options
Le lundi 08 janvier 2024 à 12:04 -1000, John Helly a écrit : > My default search engine is Google but I've also tried DuckDuckGo and Bing > with similar, but different, results. So, this problem falls into a use-case > that I usually call 'the completeness and consistency of a search'. Is there an analogue of Gödel's theorem for search engines? > IMHO, one 'simple' way around this would be to have a complete index somewhere > in the Documentation tree. This? https://lilypond.org/doc/v2.24/Documentation/notation/lilypond-index Ok, these specific terms are missing but it goes a long way already. signature.asc Description: This is a digitally signed message part
Re: Question about \include options
On 2024-01-08 21:49, Kieren MacMillan wrote: Hi all, A pity, since this is clearly explained on https://lilypond.org/doc/v2.24/Documentation/learning/types-of-properties.html That’s the first hit when I search! :) K Yes, but Google remembers your search history, so others may get a completely different first hit. As an alternative, I would recommend the "big HTML" or PDF versions of the manuals, where you can do a free text search in the full manual. See for example http://lilypond.org/notation.html, which you reach by clicking on "details of Notation" at http://lilypond.org/manuals.html. Could anyone please come up with a better formulation than "details of ...", since it's far from intuitive what such a link might contain. /Mats
Re: Question about \include options
Hi John, On the main webpage (https://lilypond.org/doc/v2.23/Documentation/web/index), when you use the search box (in the top nav bar), and type #f (no quotes or anything), do you not get the “Types of Properties” link within the first few hits (it’s the third when I search)? Thanks, Kieren. __ My work day may look different than your work day. Please do not feel obligated to read or respond to this email outside of your normal working hours.
Re: Question about \include options
Exactly. J. On 1/8/24 10:49, Kieren MacMillan wrote: Hi all, A pity, since this is clearly explained on https://urldefense.com/v3/__https://lilypond.org/doc/v2.24/Documentation/learning/types-of-properties.html__;!!Mih3wA!HBqo-HvW94DSKk2DDGkbgwtz9zOikB4lQukpZRtlEGWoWXMkUhDEX0T6AtXdwXwIzM-IPgdHDPlY-qCoRCahg_aL$ That’s the first hit when I search! :) K __ My work day may look different than your work day. Please do not feel obligated to read or respond to this email outside of your normal working hours. -- John Helly, University of California, San Diego / San Diego Supercomputer Center / Scripps Institution of Oceanography / 760 840 8660 mobile / http://www.sdsc.edu/~hellyj ORCID ID: orcid.org/-0002-3779-0603
Re: Question about \include options
Hi all, > A pity, since this is clearly explained on > https://lilypond.org/doc/v2.24/Documentation/learning/types-of-properties.html That’s the first hit when I search! :) K __ My work day may look different than your work day. Please do not feel obligated to read or respond to this email outside of your normal working hours.
Re: Question about \include options
Aloha. Well, when I do that search I just get back the \include page (https://lilypond.org/doc/v2.24/Documentation/notation/including-lilypond-files). So, the answer is no. However, one has to consider the issues of web-caching interfering with search results. Within the LP docs I wouldn't have thought to quote the string, initially, but that doesn't work either; at least not for me as I get 'no reults found'. I might have tried \#f, '#f', "#f", for example, but generally don't do exhaustive things if the 'natural' one doesn't work; depends on how crazed I am at the time about solving. At any rate, I'm open to advice, opinion, suggestion or willing to just move on. J. On 1/8/24 09:31, Kieren MacMillan wrote: Hi John, My larger concern is with the ability to find these details with limited knowledge about LP; as a relative novice. I wrote a longer reply to the list about this but, in short, I wouldn't have likely found this bit about #t #f without referrals. Seems I should have been able to search for them but it didn't succeed. I'd like to help figure out why it didn't succeed. If you do a web search for lilypond "#f" is the very first hit not sufficiently helpful? Cheers, Kieren. __ My work day may look different than your work day. Please do not feel obligated to read or respond to this email outside of your normal working hours. -- John Helly, University of California, San Diego / San Diego Supercomputer Center / Scripps Institution of Oceanography / 760 840 8660 mobile / http://www.sdsc.edu/~hellyj ORCID ID: orcid.org/-0002-3779-0603
Re: Question about \include options
> If you do a web search for > > lilypond "#f" > > is the very first hit not sufficiently helpful? In defense of the OP, the first hit for me on Qwant is http://lilypond.org/doc/v2.25/Documentation/usage/advanced-command_002dline-options-for-lilypond which would not be exactly helpful if I were learning the basics of LilyPond :( And this is Google's first hit: https://lilypond.org/doc/v2.23/Documentation/snippets/tweaks-and-overrides.fr.html A pity, since this is clearly explained on https://lilypond.org/doc/v2.24/Documentation/learning/types-of-properties.html signature.asc Description: This is a digitally signed message part
Re: Question about \include options
Hi John, > My larger concern is with the ability to find these details with limited > knowledge about LP; as a relative novice. I wrote a longer reply to the list > about this but, in short, I wouldn't have likely found this bit about #t #f > without referrals. Seems I should have been able to search for them but it > didn't succeed. I'd like to help figure out why it didn't succeed. If you do a web search for lilypond "#f" is the very first hit not sufficiently helpful? Cheers, Kieren. __ My work day may look different than your work day. Please do not feel obligated to read or respond to this email outside of your normal working hours.
Re: Question about \include options
Mahalo. Appreciate the input. I understand the \include stuff and am familiar with the concepts with that added info. My larger concern is with the ability to find these details with limited knowledge about LP; as a relative novice. I wrote a longer reply to the list about this but, in short, I wouldn't have likely found this bit about #t #f without referrals. Seems I should have been able to search for them but it didn't succeed. I'd like to help figure out why it didn't succeed. J. On 1/8/24 02:37, Aaron Hill wrote: On 2024-01-07 11:14 pm, John Helly wrote: Aloha. In reading the documentation about \include (https://urldefense.com/v3/__https://lilypond.org/doc/v2.24/Documentation/notation/including-lilypond-files__;!!Mih3wA!HDjAraGREPu720QX_4rbInA4mBp2q8iZVSzhqWOqPV1rAhmglwXGHkmJgPFkmDaV-3KRfxJByQDrUSMeZdye$ ), I find the following sentence but can't find any explanation anywhere about what *#f and #t *are or do. Can anyone enlighten me, please? They seem to have something to do with the file system but...? #t and #f are just the Scheme ways of indicating the Boolean values of true and false, respectively. So, for a setting like relative-includes, #t would enable the feature; #f would disable it. '... Complex file structures, that require to|\include|/both/files relative to the main directory and files relative to some other directory, may even be devised by setting|relative-includes|to*|#f|or|#t|***at appropriate places in the files. ...' This part of the documentation is simply indicating that the relative-includes setting can be freely changed during input processing as needed. So when you go to \include something, it is the current setting that will affect where LilyPond will search for the file in question. -- Aaron Hill -- John Helly, University of California, San Diego / San Diego Supercomputer Center / Scripps Institution of Oceanography / 760 840 8660 mobile / http://www.sdsc.edu/~hellyj ORCID ID: orcid.org/-0002-3779-0603
Re: Question about \include options
Mahalo. Appreciate the response. J. On 1/8/24 02:39, Graham King wrote: On Sun, 2024-01-07 at 21:14 -1000, John Helly wrote: Aloha. In reading the documentation about \include (https://lilypond.org/doc/v2.24/Documentation/notation/including-lilypond-files), I find the following sentence but can't find any explanation anywhere about what *#f and #t *are or do. Can anyone enlighten me, please? They seem to have something to do with the file system but...? #f and #t are the boolean values "false" and "true", respectively. In other words, they are the mechanism by which you can turn relative-includes off and on. '... Complex file structures, that require to|\include|/both/files relative to the main directory and files relative to some other directory, may even be devised by setting|relative-includes|to*|#f|or|#t|***at appropriate places in the files. ...' -- John Helly, University of California, San Diego / San Diego Supercomputer Center / Scripps Institution of Oceanography / 760 840 8660 mobile /http://www.sdsc.edu/~hellyj ORCID ID: orcid.org/-0002-3779-0603
Re: Question about \include options
Good-oh, indeed. It's true that special characters can cause inconsistent results in almost anything but if you're searching Documentation for a command that includes them, you expect the search to be 'complete'; i.e., encompassing all possibities. This search capability does not seem to be complete. If I could find out more about it, I might be able to dig into it and find out why. I don't know how the documentation is put together though. It's obviously very sophisticated but it doesn't seem familiar. J. On 1/8/24 01:09, Brian Barker wrote: At 23:10 07/01/2024 -1000, you wrote: It does indeed. Good-oh! However, I wonder why these symbols are not searchable. For example, when I search within the page you cite, they are findable. However, if I go to the top of the Documentation tree, they are not. Not sure. I'm not sure were you are searching, in fact. But different search techniques will anyway do different things with non-alphanumeric characters, I think. Is that relevant? There's no way I would probably find these without your help. Am I missing something? Don't know, I'm afraid. Brian Barker -- John Helly, University of California, San Diego / San Diego Supercomputer Center / Scripps Institution of Oceanography / 760 840 8660 mobile / http://www.sdsc.edu/~hellyj ORCID ID: orcid.org/-0002-3779-0603
Re: Question about \include options
On Sun, 2024-01-07 at 21:14 -1000, John Helly wrote: > Aloha. > > In reading the documentation about \include > (https://lilypond.org/doc/v2.24/Documentation/notation/including-lilypond-files > ), I find the following sentence but can't find any explanation > anywhere about what #f and #t are or do. Can anyone enlighten me, > please? They seem to have something to do with the file system > but...? #f and #t are the boolean values "false" and "true", respectively. In other words, they are the mechanism by which you can turn relative- includes off and on. > > '... Complex file structures, that require to \include both files > relative to the main directory and files relative to some other > directory, may even be devised by setting relative- > includes to #f or #t at appropriate places in the files. ...' >
Re: Question about \include options
On 2024-01-07 11:14 pm, John Helly wrote: Aloha. In reading the documentation about \include (https://lilypond.org/doc/v2.24/Documentation/notation/including-lilypond-files), I find the following sentence but can't find any explanation anywhere about what *#f and #t *are or do. Can anyone enlighten me, please? They seem to have something to do with the file system but...? #t and #f are just the Scheme ways of indicating the Boolean values of true and false, respectively. So, for a setting like relative-includes, #t would enable the feature; #f would disable it. '... Complex file structures, that require to|\include|/both/files relative to the main directory and files relative to some other directory, may even be devised by setting|relative-includes|to*|#f|or|#t|***at appropriate places in the files. ...' This part of the documentation is simply indicating that the relative-includes setting can be freely changed during input processing as needed. So when you go to \include something, it is the current setting that will affect where LilyPond will search for the file in question. -- Aaron Hill
last line of section with ragged right
Hello, does anyone know of a simple way to have the last line of a section with ragged right, something like ragged-last=##t affecting not only the last line of a score, but also the last line of a section? Thanks, Gilg