Intrusive instrumentation
Note to composers: This thread is about software development. Check this out! 1. Save and unzip the attached JSON file. 2. Visit https://ui.perfetto.dev/ in a browser. 3. Click "Open trace file" and choose the JSON file. 4. Explore. What you should see is a visualization of the activity in service of this command: lilypond -djob-count=2 -dtime-trace-file=z \ ~/lilypond-src/input/regression/mozart-hrn-3.ly \ ~/lilypond-src/input/regression/typography-demo.ly I don't expect to have code ready for review this weekend, but I wanted to share this much. -- Dan<>
Re: LilyDev3 problems - a translator's point of view
On 2024-05-14 10:49, 周 卫星 wrote: [HIGH] The LilyDev3 docker build is **MISSING SOME PACKAGES** and not available for work out-of-box! To me it looks like a critical issue - why all the bother with Docker when I need to search and install the missing packages manually? I believe that Federico wrote recently that he is not maintaining LilyDev any longer, but I am having a hard time finding a written record of it. I could push some Dockerfile updates that I have been using, but I don't know where to push them. I don't want to make my fork the de-facto trunk and become personally responsible for processing all new contributions. -- Dan
Re: Contributing
On 2024-04-29 17:39, Steph Phillips wrote: Hi there! I'm an experienced Python developer with some additional background in C# and C++ and would be really excited to contribute to LilyPond. It's definitely hard to decide where to begin though, so I'm hoping you can point me at the starting line! Welcome, Steph. Please consider contributing to the review of these merge requests that are currently in progress. "Various `musicxml2ly` issues" https://gitlab.com/lilypond/lilypond/-/merge_requests/2316 "clean up and accelerate www_post script" https://gitlab.com/lilypond/lilypond/-/merge_requests/2312 If that doesn't lead you to something interesting, you will at least get a sense of the current activity. -- Dan
Re: regtest threshold problem
On 2024-04-28 03:34, Werner LEMBERG wrote: > Independent of improving the metrics, maybe we could improve the review workflow by adding dynamic control to the diff web page to expand or collapse the entries based on a variable threshold. Yes, this would be a nice feature – please submit an issue for that. https://gitlab.com/lilypond/lilypond/-/issues/6711 -- Dan
Re: regtest threshold problem
On 2024-04-27 00:24, Werner LEMBERG wrote: I'm working on a modification of `musicxml2ly` that will cause a change in the result as shown by the attached images. However, our regtest classifies this as 'below threshold' and doesn't display it. Does anybody have an idea how to improve this? I'm not an expert in image analysis, and a quick search in the internet didn't help me in finding a good metrics. I think we would need something that checks whether a shape completely disappears and/or reappears in the images (contrary to shapes that are only slightly shifted and/or distorted), almost regardless of its size. Independent of improving the metrics, maybe we could improve the review workflow by adding dynamic control to the diff web page to expand or collapse the entries based on a variable threshold. -- Dan
Re: Music property articulations
[adding lilypond-devel (mea culpa)] On 2024-04-16 09:24, Maurits Lamers wrote: Hi! I looked at it now you mentioned it. Trying to grok it: does it mean that when I do not have an articulations listener it does add the articulations to the note, and when it is being listened to, it doesn't? When I test that assumption by removing the listener for articulations from the Voice context listeners, the list of articulations is still empty. cheers Maurits Op 16-04-2024 om 13:14 schreef Dan Eble: On 2024-04-15 04:20, Maurits Lamers via Discussions on LilyPond development wrote: Hey all, plus 'moment should be enough to combine them, but having all the articulations to a note as a property on that note event would save me a bit of time. Are you familiar with `Rhythmic_music_iterator::process` in lily/rhythmic-music-iterator.cc? (On LilyPond mailing lists, please add your reply after the quoted message.) > When I test that assumption by removing the listener for articulations > from the Voice context listeners, the list of articulations is still empty. Rats. I was hoping that code would explain what you are seeing. -- Dan
Re: How to detect SpanBar from inside a make-bar-line definition?
On 2024-03-13 20:09, Thomas Morley wrote: I don't understand what you propose. My advice was general software-design advice based on a hasty consideration of your post, so I'm not really surprised. To give a different example, let's look at make-dotted-bar-line (afaik it's your code). There you have a `making-span-bar?'-condition, obviously you want a span bar a little different than bar line. Yes, I remember that there were cases where the dashes didn't meet well, but I don't remember the details. a) If I implement (pretty-print grob) there, I always get BarLine, never something else, regardless where I place that. In that case, I think you will need to pass more information into the function from above or find a heuristic that works better. c) the condition itself may fail, see /input/regression/non-centered-bar-lines.ly for an example, or try to set bar-extent to an interval not crossing zero. That's why the comments call it a heuristic. Because of b) I tried to patch make-dotted-bar-line, alas I found no condition to apply the patched functionality to span bars only. Thus I ask if there is such a condition at all. Or how it could be coded. I'm not sure, and I have to be very motivated to read Scheme, which I am not at the moment. Sorry. -- Dan
Re: How to detect SpanBar from inside a make-bar-line definition?
On 2024-03-13 17:35, Thomas Morley wrote: currently I'm attempting to improve dashed/dotted bar lines wrt to changed staff-space and span bars. We use both definitions for BarLine _and_ SpanBar, but then SpanBar is frequently a little off. It would be nice to have a possibility to detect whether a definition is used for span bars. What specifically do you want to know? Do you expect to code something like if the grob is a BarLine: adjust ... by ... if the grob is a Divisio: adjust ... by ... if the grob is a SpanBar: adjust ... by ... If so, it seems that you could add a grob property for that adjustment and get it from the grob. #(define (make-test-bar-line grob extent) (let ((grob::make-span-bar? #f)) Another possibility is for the grob's print procedure to pass more information down to this function. That might be more appropriate if the information you require is not associated with the grob only, but is derived from a number of sources, like the surrounding staves, and would be useful for many different glyph print procedures. Of course, ly:bar-line::print would provide values appropriate for bar lines and ly:span-bar::print would provide values appropriate for span bars. These are the opinions off the top of my head and I reserve the right to change them. -- Dan
Re: hel-arabic.ly
On 2024-03-11 18:27, hassan.elfat...@free.fr wrote: you delete (define-safe-public FIVE-HALF-FLAT -5/2) (define-safe-public SEVEN-HALF-FLAT -7/2) (define-safe-public FIVE-HALF-SHARP 5/2 you delete (define-safe-public FIVE-HALF-FLAT -5/2) As I understand it, this change was made after your statement at https://lists.gnu.org/archive/html/lilypond-devel/2023-01/msg00176.html that "5/2 and 7/2 are not being used, You can delete them." -- Dan
Re: hel-arabic.ly
On 2024-03-07 09:24, hassan.elfat...@free.fr wrote: by trying to make hel-arabic.ly dependent on arabic.ly without consulting me, you screwed up the hel-arabic.ly file. Neighbor, 1. You contributed to an open-source project. Proposed changes are posted for public review. GitLab sends notifications to those who are subscribed. This mailing list receives a "PATCHES" message with merge-request headlines three times a week. You have had the same opportunity as any other contributor to follow and respond to proposed changes. 2. The command git grep hel-arabic input/regression/ returns no results. If you are interested in reducing the dependence on the vigilance of one or two expert reviewers, consider contributing a test or two to exercise the unique features of hel-arabic.ly such that breaking changes would cause visual differences even non-experts can appreciate. -- Dan
Re: clang compiler warnings
On 2024-02-27 07:14, Luca Fascione wrote: inline constexpr vsize VPOS (vsize(-1)); OK, but don't repeat the type. inline constexpr auto VPOS = vsize (-1); Personally, I don't like flower's aliases related to vsize, ssize, and Real -- I'd rather just use standard names -- but I remember that there was some resistance to changing them the last time I suggested it. -- Dan
Re: 5th anniversary conference? :)
On 2024-02-23 14:10, Mike Blackstock wrote: > just above the Bulk Barn on Bloor... cheap pints ... 90% whey protein isolate by the kilo ... But seriously: I'm not keen to tour the 18-lane highway to Hogtown just to socialize for an hour; however, if this idea grew into a day-long conference, I would plan to attend, provided that it didn't fall on a Sunday morning. -- Dan
Re: Error with make doc
On 2024-02-10 07:52, Werner LEMBERG wrote: systems like macOS that neither have or use '/bin/bash'. Apple changed the default shell for new users to zsh about 5 years ago, but bash is still there. I don't oppose making the build scripts more portable, but let's not misunderstand the situation. -- Dan
Re: Chord grids enhancement
On 2024-02-02 14:29, Éric Würbel wrote: How can submit a patch ? forking the master branch and submitting a pull request ? Yes. https://lilypond.org/doc/v2.25/Documentation/contributor/summary-for-experienced-developers -- Dan
Re: Error with make doc
On 2024-01-20 20:55, Carl Sorensen wrote:
File
"/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/subprocess.py",
line 524, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['/usr/bin/tidy', '-o',
'/dev/null', '-q', 'compare-dir1dir2/index.html']' returned non-zero exit
status 2.
Try commenting out this part of scripts/build/output-distance.py and
retrying:
tidy_bin = shutil.which('tidy')
if tidy_bin:
subprocess.run([tidy_bin, '-o', '/dev/null', '-q', html_fn],
check=True)
I'm not sure that that's the only problem, but it should eliminate one
thing.
--
Dan
Re: Harp_pedal_engraver: an overengineered solution to a niche problem
On 2023-12-07 05:12, Saul Tobin wrote: I’d welcome feedback and I’d be happy to submit this as a pull request for either OLL or Lilypond itself if there is interest. They're "merge requests" on GitLab, but they smell as sweet. You would likely get more engagement from busy developers if you submitted a number of right-sized merge requests with regression tests. I extended side-position-interface::move-to-extremal-staff to allow for placement of grobs below the top staff if direction is set to CENTER. merge request (though it sounds questionable as stated) IMO note-name->string should be changed to accept an integer instead of ly:pitch, to be consistent with accidental->text-accidental-markup. merge request I’ve also duplicated note-name->markup, because the original implementation doesn’t allow for printing naturals, and also because for some reason it inserts a space between the note name and the flat sign, which IMO is quite ugly (this is a general issue I see on both Mac and Windows when entering flat signs in markups, not just with that function). merge request -- Dan
Re: bizarre behaviour of `output-filename`
On Oct 21, 2023, at 01:12, Werner LEMBERG wrote: > > > >>> Some debugging shows it seems to be the latter: All top-level >>> definitions are available as paper variables within a book's paper >>> block, together with all paper variables of the top-level paper >>> block: >>> >>> Is this really intentional? >> >> https://gitlab.com/lilypond/lilypond/-/issues/5917 >> https://codereview.appspot.com/567450043 > > Really? I would never have expected that this quite innocent-looking > patch makes top-level definitions (outside of any block) available as > paper variables within `\book`. The comment in `book.cc` only talks > about `\header` blocks. How does this influence stuff outside of > `\header`? And how does it influence `\paper`? > > In case this patch is really the cause, can the behaviour be > restricted to `\header` blocks as announced in the commit message? I might have been mistaken. I don't have much time to give to LilyPond these days. — Dan
Re: bizarre behaviour of `output-filename`
On Oct 20, 2023, at 06:29, Werner LEMBERG wrote: >> >> Or is this an inheritance thing? Does a `\book` block inherit all >> top-level expressions and convert them to paper variables? > > Some debugging shows it seems to be the latter: All top-level > definitions are available as paper variables within a book's paper > block, together with all paper variables of the top-level paper block: ... > > > > Is this really intentional? https://gitlab.com/lilypond/lilypond/-/issues/5917 https://codereview.appspot.com/567450043 — Dan
Re: PATCHES - Countdown to September 1
On Aug 31, 2023, at 07:38, Jean Abou Samra wrote: > > > >> Le 31 août 2023 à 13:22, Dan Eble a écrit : >> >> My opinion hasn't changed since we instituted the automation. The previous >> discussion is in the archive. > > I couldn't find it. Do you happen to have a link at hand? Sorry for the confusing couple of slightly different emails earlier. My internet connection was up and down and I got confused about what was actually sent. I'm sure we discussed the issue of draft reviews, but I can't find it in the list archive either. We probably discussed it in one of the trial MRs when we were evaluating GitLab. My opinion was that we should let "Draft:" do what it was designed to do (prevent merging) and otherwise ignore it. I didn't think it should prevent CI pipelines and review because such feedback is useful even for draft work. If people want to prevent Draft MRs from advancing to Patch::countdown, well, I don't see either harm or benefit in it; however, making Draft equivalent to Patch::needs_work would be giving something up. — Dan
Re: PATCHES - Countdown to September 1
On Aug 31, 2023, at 02:46, Werner LEMBERG wrote: > > > >>> Colin, something that starts with 'Draft:' in the description >>> should be omitted from the normal review cycle. So: MR 2089 is >>> *not* on countdown. Please adjust the tag accordingly. >> >> Thanks for the clarification, Werner. I've set it back to Needs_work, >> as that was the last status you set, but perhaps freezing it at Review >> would also be appropriate. What do you and the other devs think about >> that as a general principle for all MRs described as Draft? > > IMHO, 'Needs_work' is exactly the right tag, since a draft MR, well, > usually needs work :-) My opinion hasn't changed since we instituted the automation. The previous discussion is in the archive. — Dan
Re: Cannot build latest master branch
On Jul 27, 2023, at 08:22, Jean Abou Samra wrote: > > as Dan said, we're on C++17 now (and I think the experiment has lasted long > enough without Guile quirks that actually using C++17 features would be fine > by now). Good, because I queued up a random bunch of minor improvements during my recent vacation. I hope to start trickling them into review after the next release. — Dan
Re: Cannot build latest master branch
On Jul 26, 2023, at 14:38, Jason Yip via Discussions on LilyPond development wrote: > > * ../configure > --prefix=/home/lj/projects/internships/2023/lilypond/build/release > --disable-debugging --disable-optimising --enable-checking > --enable-profiling 'CC=ccache clang' 'CXX=ccache clang++' > 'CXXFLAGS=-std=c++11 -march=native -O0 -g -pedantic -fno-plt > -Wformat -Werror=format-security -Wno-unused-command-line-argument > -fstack-clash-protection -fstack-protector-strong -fcf-protection > -fuse-ld=mold -Wp,-D_GLIBCXX_ASSERTIONS' > LDFLAGS=-Wl,--sort-common,--as-needed,-z,defs,-z,relro,-z,now > PYTHON=/usr/bin/python > * make > > My configure args have always worked in the past, but not this morning > 'CC=ccache clang' 'CXX=ccache clang++' Have you tried clearing the cache? > CXXFLAGS=-std=c++11 Why this? We started using C++14 in June 2022. We are currently building with -std=c++17, though we haven't intentionally started using C++17 features. > -pedantic I'm surprised that this doesn't complain about ##__VA_ARGS__, but I guess that Clang is not as pedantic as GCC. You're using a some compiler features that I don't immediately recognize. Have you tried just `autogen.sh --ci`? — Dan
Re: No applicable method for #< - (4)> in call
On Jul 9, 2023, at 10:39, Jean Abou Samra wrote: > > It definitely makes sense to keep the option to build without bytecode, since > that is quite faster for incremental rebuilds (especially in Guile 2.2, I think it makes sense to skip `make bytecode` when iterating on particular tests, but I always `make bytecode` before `make check` because `bytecode` requires 15s and shortens `check` by 60s. I don't know whether that is typical, but I wouldn't mind having `make` compile the bytecode for me in the case of `check` and `doc` targets. — Dan
Re: No applicable method for #< - (4)> in call
On Jul 8, 2023, at 13:55, David Kastrup wrote: > > Ok, here is the deal: I think it probably is sanest to just ditch the > operator for ly:pitch-negate and the equivalent for Moment. That being > said, I've also found incorrect manual conversions in some code. The > question is whether it is better to address this with a bulk fix, or > with reverts and redo of what turns out a number of co-dependent > commits. Speaking just for myself, this state of affairs is only a slight annoyance, so whatever you deem the cleanest or most convenient path is fine with me. — Dan
No applicable method for #< - (4)> in call
I'm hitting this on master after (roughly) autogen.sh; make; make bytecode. ``` $ out/bin/lilypond ~/lilypond-src/input/regression/other/display-lily-tests.ly GNU LilyPond 2.25.7 (running Guile 2.2) Processing `/home/user/lilypond-src/input/regression/other/display-lily-tests.ly' [...] /home/user/lilypond-src/input/regression/other/display-lily-tests.ly:252:8: error: Guile signaled an error for the expression beginning here \test # #[ \key e \minor #] No applicable method for #< - (4)> in call (- 0 #) /home/user/lilypond-src/input/regression/other/display-lily-tests.ly:252:7: error: wrong type for argument 2. Expecting pair, found # \test##[ \key e \minor #] […] ```
Re: Getting beam subdivision working
On Jun 19, 2023, at 13:21, Jason Yip wrote: > \set minSubdivideInterval = #(ly:make-moment 1 8) > \set maxSubdivideInterval = #(ly:make-moment 1 16) These values could be `\musicLength 8` and `\musicLength 16`. Also, MR 2032 (merged hours ago) adds `musical-length?` and `positive-musical-length?` predicates that you might find useful to reduce the amount of validation where these properties are read. https://gitlab.com/lilypond/lilypond/-/merge_requests/2032 — Dan
Re: Getting beam subdivision working
On Jun 17, 2023, at 09:27, David Kastrup wrote:
>
>>
>> That sounds like it would make more sense to specify those values in the
>> form of a "duration log", like the first argument to a ly:make-duration
>> call.
>
> Or just use a duration in the first place. First iterations would
> likely only use the duration-log info while I consider it conceivable
> that in the context of tuplets, ultimately also the factor may get used.
There are no Duration properties. I recently tried a step down the path of
adding them and got as far as supporting
\set Staff.parserTestDuration = \breve
\set Staff.parserTestDuration = ##{ 4. #}
\set Staff.parserTestDuration = \duration 4.
before deciding to leave the existing Moment properties as they are and provide
\musicLength [1] to clear ly code of #(ly:make-moment…) cruft.
I'm not saying that Duration properties couldn't or shouldn't be added; I'm
just warning that they're not a ready option.
—
Dan
[1] https://gitlab.com/lilypond/lilypond/-/merge_requests/1887
Re: Getting beam subdivision working
On Jun 16, 2023, at 19:13, Jason Yip wrote: > > minSubdivideInterval and maxSubdivideInterval. They are both Rationals. Their > numerator and denominator must be a power of 2. For each power of 2 > (including negative powers of 2 of course) between those two values, the beam > can be subdivided by that interval. minSubdivideInterval can be 0 for no > minimum limit, maxSubdivideInterval can be infinity for no maximum limit. Setting the representation aside, is the following another way of describing what you have in mind? * These properties are independently optional. * The allowed values are integer powers of two (including negative powers). — Dan
Re: 2.25.6 release
On Jun 16, 2023, at 04:37, Jean Abou Samra wrote: > > I know that 2.25.6 was planned for this weekend. Unfortunately, due to > https://gitlab.com/lilypond/lilypond/-/issues/6620 , current master is not > going to work on Kubuntu and possibly other distros. > > I will try to find time this evening to experiment with the alternative > approaches proposed on > https://gitlab.com/lilypond/lilypond/-/merge_requests/2033 . Meanwhile, > should we delay the release, or > do it nevertheless? I don't see a problem either with releasing it with a note about the known issue, or with delaying the release. I have no concerns about leaving the decision to Jonas, since he is the one spending his time on it. — Dan
Re: Time-signature cancellation
On Jun 4, 2023, at 08:18, Werner LEMBERG wrote Has anyone here ever used or seen the time-signature cancellation sign shown in MR 2029, or anything like it? https://gitlab.com/lilypond/lilypond/-/merge_requests/2029 >>> >>> Never. >>> Kieren. >> >> Now I'm starting to doubt that I should bother with it. > > Maybe asking on 'lilypond-user', too? https://lists.gnu.org/archive/html/lilypond-user/2023-06/msg00010.html One user has provided an example and another has wisely recommended not describing it as a cancellation sign, since it can be used at the start of a piece. — Dan
Re: Time-signature cancellation
On Jun 4, 2023, at 15:27, Flaming Hakama by Elaine
wrote:
>
> I guess I am kind of confused at the default behavior, why does lilypond
> not reprint a clef when you specify \clef ?
>
> Are people putting \clef commands in their code where they don't want a
> clef to appear?
> Is this a common practice?
I can't read the mind of the original designers, but I can appreciate that it
simplifies certain things like unfolding repeats and reusing music from
variables in different parts of a work.
sectionA = { \clef "alto" . . . }
sectionB = { . . . \clef "treble" . . . }
refrain = { \clef "treble" . . . }
\new Staff {
\sectionA
\refrain
\sectionB
\refrain % [1]
}
If it didn't work the way it does, the question at [1] would be, "Why is
LilyPond printing an unnecessary change clef and confusing my __ section in
rehearsal?"
—
Dan
Re: Time-signature cancellation
On Jun 4, 2023, at 07:53, Kieren MacMillan wrote: > > Hi Dan, > >> Has anyone here ever used or seen the time-signature cancellation sign shown >> in MR 2029, or anything like it? >> https://gitlab.com/lilypond/lilypond/-/merge_requests/2029 > > Never. > Kieren. Now I'm starting to doubt that I should bother with it. — Dan
Time-signature cancellation
Has anyone here ever used or seen the time-signature cancellation sign shown in MR 2029, or anything like it? https://gitlab.com/lilypond/lilypond/-/merge_requests/2029 — Dan
Re: Clef, key, and time-signature changes
On Jun 3, 2023, at 04:09, Kevin Barry wrote: > > On Sat, 3 Jun 2023 at 06:06, Carl Sorensen wrote: > >>> I vote for adjusting the code so that it follows the documentation, >>> probably by adding `forceTimeSignature` and `forceKeySignature` >>> properties, both for orthogonality and a way to retain backward >>> compatibility. >>> >> >> I vote for initially just fixing the code -- use scm_equal_p instead of >> scm_is_eq >> >> At that point, we'd be consistent with the documentation. >> >> If there is a use case for 'forceTimeSignature' then I suppose we could >> create it, but it seems to me like YAGNI. > > My preference would be to leave things as they are (and update the > documentation), or, if not that, then follow Werner's suggestion. I > have sometimes needed to reprint a time signature even if it wasn't > different. I am partial to changing the default behavior and providing a consistent way to override it. There are some things that I would change about `forceClef`. -- Dan
Clef, key, and time-signature changes
About time signatures, the Notation Reference says briefly,
> Time signatures are printed at the beginning of a piece
> and whenever the time signature changes.
That is true, but incomplete: time signatures are also printed when the time
signature hasn't changed -- and it has been that way for years.
Time_signature_engraver::process_music has this condition:
SCM fr = get_property (this, "timeSignatureFraction");
if (!scm_is_eq (last_time_fraction_, fr) && scm_is_pair (fr))
{
// . . . create the grob . . .
scm_is_eq tells whether these two things refer to the very same instance; if
they are different pairs containing equal values, the grob is created.
Essentially, this creates a time signature whenever `\time` is used.
I haven't tested key signatures, but Key_engraver::process_music looks similar.
Clefs work differently.
Anyone want to weigh in on whether anything should be done about these
inconsistencies? Do they call for editing the documentation? something more
radical?
Regards,
—
Dan
Assigning issues
I was obliquely asked about my reaction to having another person assign an issue to me. The main practical effect of assigning an open issue is to deter others from acting on it: a person interested in working on an issue ought to coordinate with the current assignee before doing something that might be considered interference. If I were unable to respond for some time to an issue that was just assigned to me, the assignment could be counterproductive. A simple @-mention would get my attention just as well without discouraging others from getting involved. The other important consideration is that people in this group commonly have the temperament of an artist and the verbal filter of an engineer. Therefore, my advice is not to assign an issue to another contributor lightly; but if you understand the practical impact and can communicate your reasons delicately, it might be appropriate on occasion. I hope that helps. — Dan
Re: quoting percent repeats
On May 18, 2023, at 08:47, Valentin Petzel wrote: > > Essentially it checks: Do we start at the begin of a measure, and if so, does > or repeated music take exactly one or two measures? I've dropped the user list from this thread. I suggest looking at Percent_repeat_iterator::create_contexts(). There is code that reads context properties. Next, read the comment on Music_iterator::create_contexts(). This is the salient point: // Think twice before reading context properties here. Other iterators' // process () methods may run after this call and before this iterator's // process () method runs (and may change the context properties). Therefore, try deferring the Percent_repeat_iterator's initialization that depends on context properties until the first call to process(). You are right that quoting on the whole does not smell sweet, and I don't have time now to list the remaining problems I see, but taking the above action might mitigate the problem at hand. — Dan P.S. Include a regression test in your merge request. :)
Re: strange volta bracket example in LSR
On May 18, 2023, at 00:29, Werner LEMBERG wrote: > > >>> The snippet 'Adding volta brackets to additional staves' >>> >>> https://lsr.di.unimi.it/LSR/Item?id=427 >>> >>> doesn't seem to do what the description says. Honestly, I have no >>> idea what this snippet actually wants to demonstrate at all... >> >> https://gitlab.com/lilypond/lilypond/-/issues/6373 > > Aah, thanks. Maybe it makes sense to replace this non-standard > example in the documentation with > > https://lsr.di.unimi.it/LSR/Item?id=220 > > (which we already import into LilyPond but don't use in the NR)? That's not a bad idea. I've written more in the ticket. -- Dan
Re: strange volta bracket example in LSR
On May 17, 2023, at 14:04, Werner LEMBERG wrote: > > The snippet 'Adding volta brackets to additional staves' > > https://lsr.di.unimi.it/LSR/Item?id=427 > > doesn't seem to do what the description says. Honestly, I have no > idea what this snippet actually wants to demonstrate at all... https://gitlab.com/lilypond/lilypond/-/issues/6373 — Dan
Re: Next releases
On May 10, 2023, at 16:19, Jonas Hahnfeld via Discussions on LilyPond development wrote: > > Hi all, > > due to various constraints, I am kind of restricted when I will be able > to do the next releases, so I thought I might as well let you know: > > LilyPond 2.25.5 will happen on the weekend of the 20th/21st (unless I > get too bored this next weekend...). I'm planning version 2.25.6 for > the second weekend of June (10th/11th) or the one after (17th/18th). > > I also think it might be a good idea to have another bugfix release of > stable/2.24, towards the end of June / early July? Whatever works for you. I'm glad you keep these things moving. — Dan
Re: Tick bar from font
On May 5, 2023, at 06:14, Jean Abou Samra wrote: > > Le jeudi 04 mai 2023 à 22:51 -0400, Dan Eble a écrit : >> >> >> I thought it would be nice to be able to draw a tick BarLine from a font >> glyph in lieu of the default rounded rectangle. I have a working prototype >> that uses a new property BarLine.tick-font-glyph-name to enable the >> behavior, but I need some advice about font-size. > > > Could you elaborate on the expected advantage? This is in the context of 6564. I am looking for ways to increase the configurability and maintainability of Divisio by changing it to share internals with BarLine, and one of the differences between the two is the variety of shapes used for the divisio minima. — Dan
Tick bar from font
I thought it would be nice to be able to draw a tick BarLine from a font glyph in lieu of the default rounded rectangle. I have a working prototype that uses a new property BarLine.tick-font-glyph-name to enable the behavior, but I need some advice about font-size. VaticanaStaff has \override Divisio.font-size = #-2. In order to make a tick BarLine that looks about the same, I could override BarLine.font-size = #-2. That would be fine for the tick, but it would also shrink other font glyphs (dots, bracket tips, segno and kievan bar lines). I'm not sure what to do. * add another BarLine property for a tick-specific scaling factor * add smaller versions of the font glyphs for \caesura and \virgula * give up on unifying this aspect of Divisio and BarLine * other Thanks, — Dan
Re: LSR #983 produces strange result
On Apr 23, 2023, at 05:22, Jean Abou Samra wrote:
>
>> {
>> \textLengthOn
>> s1-"loong"
>> \once \omit Staff.BarLine
>> \clef F
>> r1
>> }
>> with a starting spacer _and_ an omitted BarLine _and_ a clef change.
>>
>> 2.22. is ok, but output of 2.24. is bad.
>
>
> The MM rest placement sounds like
> https://gitlab.com/lilypond/lilypond/-/issues/6550
I don't see a multi-measure rest.
—
Dan
Bar lines in mensural notation (request for interpretation)
Everything I know about 16th-Century Italian I learned from 20th-Century Spanish. I hope that someone here is able and willing to check my guesses about this. The following text seems to follow an introduction to mensural rests, and it surrounds a figure of a single bar line and a double bar line on an otherwise empty staff. The book often uses bar lines in a way that looks semantically modern, though it also contains sample compositions without bar lines. > Gli Ecclesiastici etiandio pongono le Pause ne i loro canti, no gia per > ornamento, ma per necessità. . . . > Il che fa dibisogno, che li Compositori etiandio auertitenza delle parole si > oda, & intenda interamente: percioche facendo in cotal modo, allora si potrà > dire, che le Pause siano state poste nelle parti della cantilena con qualche > proposito, & non a caso. Ne si debbeno porre per alcun modo, auanti che sia > finita la sentenza, cioè nel mezo della Clausula: conciosia che colui, che le > ponesse a cotal modo, dimostrarebbe veramente essere vna pecora, vn goffo, & > vno ignorante. Però adunque il Musico si sforzerà di non cascare in simili > errori; accioche non dia alli dotti mala opinione di se, il che molto si > debbe prezzare, & preporre ad ogn'altra cosa. This is what I've drawn out: When notating a chant, anyone who places full-height single or double lines anywhere but the end of a phrase is a sheep, a klutz, and an ignoramus. My main doubt is whether this restriction is limited to church music. I hope to understand whether to regard the bar lines in the rest of the book as a normal part of the notation that this author is teaching, or rather as a learning aid that he expects the reader not to carry over into his work. More context might be required. The book is available at IMSLP. See page 212. https://imslp.org/wiki/Le_Istitutioni_Harmoniche_(Zarlino,_Gioseffo) Thanks and regards, — Dan
Re: On the ly: prefix...
On Apr 2, 2023, at 14:39, Kevin Barry wrote: > > On Sun, 2 Apr 2023 at 19:31, Jean Abou Samra wrote: >> I can do >> >> (define-public grob-interpret-markup ly:grob-interpret-markup) >> >> like we already have for assoc-get aka ly:assoc-get, but it seems >> clumsy. > > That is what I would do. Do yourself a favor: do this and worry about everything else later. — Dan
Re: MacPorts builds for 'Yosemite' and 'El Capitan' fail
On Feb 5, 2023, at 09:28, Dan Eble wrote: > > 2. Attack this TODO in flower/include/real.hh. > >using std::abs; // TODO: replace abs (x) with std::abs (x) and remove this https://gitlab.com/lilypond/lilypond/-/merge_requests/1834 — Dan
Re: MacPorts builds for 'Yosemite' and 'El Capitan' fail
Friends, I don't have a Yosemite or El Capitan environment in which to validate changes. There are two things I would try. 1. Does changing the few occurrences of `#include ` to `#include ` fix it? I don't know that it will, but it seems like less work than 2. 2. Attack this TODO in flower/include/real.hh. using std::abs; // TODO: replace abs (x) with std::abs (x) and remove this I have more in my schedule today than a usual Sunday, but if I get time and I don't hear that anyone else has started turning these cranks, I will try later. Regards, — Dan
Re: Explicit default duration?
On Jan 26, 2023, at 12:22, David Kastrup wrote: > >c'' x2 > That looks a lot like "twice" to me. — Dan
Re: Explicit default duration?
On Jan 23, 2023, at 18:05, David Kastrup wrote: > > Dan Eble writes: > >> On Jan 23, 2023, at 10:11, David Kastrup wrote: >>> >>> I am not saying that 0 is the best choice here. It merely appears to be >>> rather cheap. I thought of * and / but the first renders sequences like >>> c4*2 ambiguous and the second would at least become a mess in chord >>> mode. >> >> Can you clarify how `c4*2` would be ambiguous? (I was about to >> suggest `r*1` for your original example.) > > c4*2 could be read as c4 c4 c2 if all of 4 * 2 are interpreted as > individual durations. I see. I was thinking not of using '*' as a duration, but of omitting the duration part of r4*1. r4 quarter rest rrest of default duration r4*2/3 quarter rest compressed to 2/3 of its duration r*2/3rest of the default duration, compressed to 2/3 of it So r*1 would use the unscaled default duration. — Dan
Re: Explicit default duration?
On Jan 23, 2023, at 10:11, David Kastrup wrote: > > I am not saying that 0 is the best choice here. It merely appears to be > rather cheap. I thought of * and / but the first renders sequences like > c4*2 ambiguous and the second would at least become a mess in chord > mode. Can you clarify how `c4*2` would be ambiguous? (I was about to suggest `r*1` for your original example.) — Dan
Re: want to help
On Jan 16, 2023, at 16:26, David Zelinsky wrote: > Or try to make a merge request? Welcome. This is the way. — Dan
Slurs without Stems (Issue #3760)
Should slurs require Stem_engraver? No: https://gitlab.com/lilypond/lilypond/-/issues/3760#note_339794300 Yes: https://gitlab.com/lilypond/lilypond/-/merge_requests/1800#note_1227831830 I'm looking for some input from old-timers to help decide this so I can avoid wasting more time on broken or unacceptable solutions. Thanks, — Dan
Re: Strange behaviour with unknown alternativeNumberingStyle
On Dec 30, 2022, at 12:10, Thomas Morley wrote:
>
> Hi all,
>
> please have a look at:
>
> \version "2.25.0"
>
> {
> \override Score.BarNumber.break-visibility = ##(#f #t #t)
> % \set Score.alternativeNumberingStyle = #'whatever
> b1
> \repeat volta 2 { c' c' }
> \alternative { d' e' }
> f'
> }
>
> As soon as the style-setting is uncommented it behaves like
> \set Score.alternativeNumberingStyle = #'number
> shouldn't an unknown style behave like the default '()?
I don't see documentation or regression tests for anything beyond 'number and
'numbers-with-letters.
Since https://gitlab.com/lilypond/lilypond/-/merge_requests/594#note_477121479,
Timing_translator chooses the numbers and Bar_number_engraver formats them.
Any value of "alternativeNumberingStyle" causes Timing_translator to use the
alternative numbering scheme common to both of those styles.
> tl;dr
> This probably prevents me defining a knew style
> with a custom engraver
> as fix for lsr-snippet 1080 "Incrementing bar numbers in volta
> repeats"
> https://lsr.di.unimi.it/LSR/Item?id=1080
From the description: "Here is a hack that increments the currentBarNumber
property whenever volta repeats occur. It also offers basic (though limited)
support for alternatives."
Do you need a new value for alternativeNumberingStyle? If you want the
behavior arising from leaving alternativeNumberingStyle unset, why not leave it
unset and let your custom engraver do the rest?
Besides, the snippet's numbering scheme seems oriented toward the volte in
general rather than the alternatives. It isn't clearly a new kind of
alternative numbering.
—
Dan
Re: Another user complaint about incompatible mark-like events
On Dec 3, 2022, at 08:48, Jean Abou Samra wrote: > > It rejects the \sectionLabel that comes at the same > time as an implicit \codaMark. > > Should this be supported, or is there a reasoning that > I am missing? It's the same concern as from the beginning: I was reluctant to allow assigning multiple labels to the same moment in a performance because of known and unknown complications. For example, if a moment were marked with both 턌 and Part II, what should the jump text say? D.C. al 턌 e poi la Coda D.C. al Part II e poi la Coda D.C. al 턌Part II e poi la Coda Automating that was not something I was willing to struggle with. > Of course, for now one can use > > \tweak font-size 1.5 \textMark "Part II" If the score must have a coda mark and a section label at the same point, I think that is a reasonable recommendation for 2.24. — Dan
Re: Another user complaint about incompatible mark-like events
On Dec 3, 2022, at 10:25, Jean Abou Samra wrote: > > Le 03/12/2022 à 16:18, Dan Eble a écrit : >> Printing "Coda" instead of a coda mark is the defining use case for >> \sectionLabel. > > But judging from how \repeat segno uses it and from its break-visibility, > \codaMark is for a jump to the coda, not for the start of the coda itself, > isn't it? "What it's for" and "how I managed to make it work" are not necessarily the same. There is an implicit \codaMark \default at the start of every alternative ending. — Dan
Re: Another user complaint about incompatible mark-like events
On Dec 3, 2022, at 08:48, Jean Abou Samra wrote: > > It rejects the \sectionLabel that comes at the same > time as an implicit \codaMark. Printing "Coda" instead of a coda mark is the defining use case for \sectionLabel. I'll try to take a closer look at the example soon. — Dan
Re: Guile 2 vs. Guile 3
On Nov 26, 2022, at 17:43, Eric Benson wrote: > > ton of warnings, mostly of the form "implicit conversion changes > signedness". These seem like the sort of thing that might not be too hard > to fix. https://gitlab.com/lilypond/lilypond/-/merge_requests/1744 fixes warnings other than conversion warnings. — Dan
Re: Prefer luatex for documentation
On Nov 19, 2022, at 05:19, Werner LEMBERG wrote: > > Attached you can find an example that demonstrates (a), taken from the > MR. The sample LGTM. Beyond that, I prefer not to involve myself in the discussion. — Dan
Re: Automated test on PDF or SVG output
On Nov 14, 2022, at 04:43, Paolo Prete wrote: > > I need to execute the following automated test: > given a .ly file, I would like to check if the produced output is what I > expect it to be. For checking the impact of LilyPond changes on my own scores, I use a Docker container and a bash script that does this: 1. reads PDF files from two directories recursively 2. converts each page to a bitmap 3. overlays the two versions of each page so that pixels which are white in one and black in the other become either red or green 4. collates the new images into new PDF files in a third directory Then I review every score. It works well when specific things have moved, appeared, or disappeared. It can be quite noisy when there have been general changes to spacing. If that appeals to you, I can send you the scripts privately. — Dan
Re: Updated release schedule
On Nov 12, 2022, at 09:07, Werner LEMBERG wrote: >> 2. Release 2.23.81 without the fix and instead review it properly. ... > Option 2 is fine with me. +1 — Dan
Re: Labels for ties and slurs
On Oct 22, 2022, at 09:16, Jean Abou Samra wrote: > > We have many issues related to ties and to slurs. Would anybody mind creating > two GitLab labels ~"Ties" and ~"Slurs" for these? It would ease searching for > defects in those specific areas. I don't have a problem with your creating any labels that you deem useful. — Dan
Re: To branch or not to branch
On Oct 7, 2022, at 13:51, Jonas Hahnfeld via Discussions on LilyPond development wrote: > > On Thu, 2022-10-06 at 08:39 +0200, Jean Abou Samra wrote: >> A factor that I was starting to forget in my enthusiasm for branching is >> !1510 (source locations). Here I am guilty of taking forever to prepare >> the latest version of that patch. I am open to opinions on whether it >> should be included in 2.24. I do think so, because the problem it fixes >> has been called a possible release blocker by some. > > I have to say this is very late. Yes, the MR is a bit older, but it > also touches very core parts of LilyPond. On the other hand, the > compilation isn't enabled by default and the other change is about the > error path. I don't know… I'm fine either way. — Dan
Re: Administration of mailing lists
On Oct 7, 2022, at 16:45, Jean Abou Samra wrote: > Thus I wrote to the general GNU list server admins and proposed > to step up for being an admin on these lists, just like I am > already an admin on lilypond-user-fr (the French-speaking equivalent > of lilypond-user, in case you didn't know). > > Is that OK with everyone? It is fine with me. — Dan
Re: Tablature full notation rests and aethstetics
> I'm only familiar with a subset of C++ up to C++03. Would my lack of > knowledge of modern C++ exclude me from being a contributor? No. Others will review your code and suggest using new features where it is appropriate. > I'm also not an expert on UB in C++, although I very much want to avoid it. > Would that exclude me from being a contributor? No. — Dan
Re: GregorianTranscriptionStaff
On Aug 1, 2022, at 10:44, Lukas-Fabian Moser wrote: > > fwiw, I'm a bit confused about the GregorianTranscriptionStaff context - for > example, in the typical liturgical situations where one uses a "modern" staff > for notating Gregorian chant, one usually doesn't use stems. I've been going through the documentation, and it seems that all examples of transcribing Gregorian chant remove the time signature. I propose that we remove it from GregorianTranscriptionStaff and use that in the examples: https://gitlab.com/lilypond/lilypond/-/merge_requests/1614 — Dan
Re: Replacing fixcc.py with clang-format?
On Sep 6, 2022, at 12:46, Jean Abou Samra wrote: > > I would like to propose moving to clang-format as the canonical > formatting tool and removing fixcc.py. I don't care as long as the version is specified. — Dan
Re: "Hymn template" snippet
On Aug 9, 2022, at 10:07, Trevor wrote: > In more modern hymn books there is a movement to use thin double lines > throughout rather than commas to show how the lines of the verse map onto the > music, although settings of traditional hymns usually retain the commas (see > Common Praise). Thanks. For the record, here's evidence that both the comma and the double bar are not tied to line position in _Common Praise_: https://hymnary.org/hymn/CPAM2000/369 — Dan
Re: Moving most initialization to .scm files
On Sep 4, 2022, at 16:38, Jean Abou Samra wrote: > > it will create conflicts with everyone's WIP local branches This is obviously unwelcome. I would need to read a lot before I would have a hope of speaking competently on this issue, and I'm very busy right now. — Dan
Re: Removing a snippet
On Sep 4, 2022, at 18:23, Thomas Morley wrote: > >> The Contributor's Guide has sections on adding, editing, and renaming >> snippets. What should I do when I want to stop using a snippet in the >> Notation Reference? > > Well, short answer, adjust NR in > Documentation/*/notation/expressive.itely, and you're done. Thanks. I'll do that much and also record your answer in the CG. Later, I will coordinate with you about fully cleaning up this and any other obsolete snippets I find. — Dan
Removing a snippet
Harm, The Contributor's Guide has sections on adding, editing, and renaming snippets. What should I do when I want to stop using a snippet in the Notation Reference? The one I have in mind now is "Inserting a caesura", though there might have been one in the past that I removed from the source without asking this question. Thanks, — Dan
Syntax highlighting of a new grob name
I am trying to document \caesura in the Notation Reference. I have just made the docs starting from a clean build directory. I see that CaesuraScript is highlighted differently than other grob names in this text: \override Score.Script.color = ... \override Score.MultiMesaureRestScript.color = ... \override Score.CaesuraScript.color = ... Can I do something to address this? TIA. — Dan
Re: Stale branches in Savannah repository
On Sep 1, 2022, at 14:54, Jonas Hahnfeld via Discussions on LilyPond development wrote: > > Hi all, > > it's been 2 years now that development has moved to GitLab. In the very > beginning, we agreed to keep existing branches on Savannah, but I'd > like to revisit that decision and propose that we make it a mirror of > only the master and stable/* branches, just as GitHub is. The migrated > branches continue to be available on GitLab. > > However, I'd like to also propose to delete some of these branches > (both on Savannah *and* GitLab) that don't serve a purpose anymore: I don't have a strong opinion. — Dan
Re: A more automated LY_DEFINE?
On Sep 2, 2022, at 04:42, Jean Abou Samra wrote:
>
> Does C++ provide tools for making this simpler? I'm thinking that something
> like
>
> LY_DEFINE (ly_grob_relative_coordinate, ..., (Grob *g, Grob *refp, Axis a),
> ...)
> {
> ...
> return ret;
> }
>
> would be equivalent to
>
> LY_DEFINE (ly_grob_relative_coordinate, ..., (SCM g_scm, SCM refp_scm, SCM
> axis_scm), ...)
> {
> auto *const g = LY_ASSERT_SMOB (Grob, g_scm, 1);
> auto *const refp = LY_ASSERT_SMOB (Grob, refp_scm, 2);
> LY_ASSERT_TYPE (is_scm, axis_scm, 3);
> Axis a = from_scm (axis_scm);
> ...
> return to_scm (ret);
> }
This has been on my wish list for a while, which is why it is currently
possible to pass overloaded functions to macros such as LY_DEFINE, and
hand-code the function as a SCM function wrapping another function. I suspect
that David had similar thoughts when he created from_scm() and to_scm().
> I might be willing to spend time on it in the future, although not very soon.
>
> If it is not feasible, being told it before I try could save me time. I'm
> not yet very familiar with C++ templating techniques.
It's hard to give any assurance about complicated problems one doesn't do every
day. I can confidently predict that the experience will involve an instance of
trying something obvious that doesn't work and learning that it requires a more
recent version of C++.
I don't want to discourage you, but this is a good thing to attempt when you're
prepared for a steep learning curve and possible failure.
—
Dan
Macro for NR appendix
I tried this:
@macro appendixBarLineDemo{BARTYPE}
@code{"\BARTYPE\"}
@lilypond[notime,relative=2]
\bar "\BARTYPE\" b4 \bar "\BARTYPE\" b4 \bar "\BARTYPE\"
@end lilypond
@end macro
but with \BARTYPE\ in the lilypond section, no staff appears in the PDF. I
guess I need some additional quoting — or unquoting. Is there a way to make
this work or am I stuck writing out the bar type 4 times per type?
Thanks,
—
Dan
Re: Mixed chord/note mode
On Aug 14, 2022, at 06:59, Jean Abou Samra wrote: > > Le 14/08/2022 à 12:21, David Kastrup a écrit : >> Jean Abou Samra writes: >> >>> We could also introduce a music function. I don't think >>> tremoli are used frequently enough that having the most >>> concise syntax for them is very important. >> Drum roll... Let me guess: you don't write percussion parts frequently? > > That is a good point. > One could say he hit it on the head. — Dan
Re: Can't have rehearsal mark and segno mark at same moment
On Aug 14, 2022, at 04:03, Werner LEMBERG wrote: > >> Or maybe \textMark and \textEndMark? I'm not sure. > > I prefer `\textMark` over 'ad-hoc' or 'nonce'. As with Jean, I've > never used the word 'nonce' before. I also prefer \textMark. Then ad-hoc-mark-event can remain ad-hoc. FYI, "nonce" is alive and well as jargon in at least two domains. * https://en.wikipedia.org/wiki/Cryptographic_nonce * https://en.wikipedia.org/wiki/Nonce_word I do not think there would have been a problem using "nonce" in an internal name, but if I preferred it over "ad-hoc", I would not have used "ad-hoc" in the first place. — Dan
Re: Can't have rehearsal mark and segno mark at same moment
On Aug 13, 2022, at 19:00, Jean Abou Samra wrote: > > I now have a patch locally that renames AdHocMarkEvent into > LegacyAdHocMarkEvent > (also ad-hoc-mark-event into legacy-ad-hoc-mark-event), If I were less familiar with this stuff, I would probably be confused by leaving "ad-hoc" in these names while introducing not-very-closely related things that also have "ad-hoc" in their names. Would you be willing to use another name? My best idea is nonce-rehearsal-mark-event. The rest of your plan sounds fine. — Dan
Re: Can't have rehearsal mark and segno mark at same moment
On Aug 10, 2022, at 18:01, Dan Eble wrote: > > On Aug 10, 2022, at 14:20, Jean Abou Samra wrote: >> >> \set Score.rehearsalMark = >> \mark \default ... > Remember the reasons that you preferred that \bar send an event rather than > set a property? Maybe they apply to this too. Oh, never mind this statement. There is still an event in your example. (The lesson is this: Don't try to respond to an email after your wife has summoned you to dinner.) — Dan
Re: Can't have rehearsal mark and segno mark at same moment
On Aug 10, 2022, at 14:20, Jean Abou Samra wrote: > > There is also \mark . I don't know if it's really that > useful. If you need this, you can just as well do > > \set Score.rehearsalMark = > \mark \default I found that interface inconvenient enough not to imitate it in the coda and segno mark implementation. \codaMark and \segnoMark are supported, but the context properties holding the current sequence numbers are internal. Remember the reasons that you preferred that \bar send an event rather than set a property? Maybe they apply to this too. % warning about this is very easy with with assign_event_once << \mark 1 \mark 2 >> % we can't warn about this << \set Score.rehearsalMark = 1 \set Score.rehearsalMark = 2 >> — Dan
Re: Can't have rehearsal mark and segno mark at same moment
On Aug 10, 2022, at 00:38, Werner LEMBERG wrote: > > Just imagine a piece (say, a waltz by Johann Strauss[*]) that has not > a single segno, but a bunch of them. It might confuse an orchestra if > the conductor asks to start 'at the segno' during a rehearsal – from > experience I can tell you that at least one musician will ask 'which > one?'… Then that score is not an example of using a segno and a rehearsal mark at the same point. It is an example of ambiguous segni, and stacking rehearsal marks on top of them addresses only half of the issue: the D.S. instructions remain ambiguous. > In other words, it actually does make sense to have both rehearsal > marks and segno signs at the same position. Between preparing caesura-related MRs, I will try allowing a rehearsal mark to occur at the same point as the other types of marks. Maybe now, after having spent some time away from it, I will see other ways to do the things that made me implement the restriction in the first place. I would like advice on whether it would be ideal to split Mark_engraver into Rehearsal_mark_engraver and Performance_mark_engraver. I recall that my primary reason for keeping them all together originally was a concern that we might discover interdependencies between different types of marks that are easier to manage with one engraver in charge, and I thought it would probably be easier to start with one and split it in a future release than to go the other way. — Dan
Re: Can't have rehearsal mark and segno mark at same moment
On Aug 3, 2022, at 17:22, Jean Abou Samra wrote:
>
> \version "2.23.12"
>
> {
> c'1
> \mark \default
> \repeat segno 2 {
> c'1
> }
> }
>
>
> A power user on -user-fr is frustrated that the above
> doesn't work, as rehearsal-mark-event and segno-mark-event
> are mutually exclusive at the same time step.
Vincent,
The marks that \repeat segno creates are intended to identify points of
repetition and departure for performance. Having one of those, I do not
understand why one would want to identify the same point with a second mark for
rehearsal.
I read a machine translation of the thread on lilypond-user-fr, and I thought
that probably you did not really want to print a rehearsal mark and a segno
simultaneously. Can you clarify for me what you wanted to achieve?
—
Dan
Re: "Hymn template" snippet
On Aug 9, 2022, at 08:26, Kieren MacMillan wrote: > > Hi all, > > The big difference, in my mind — as composer, arranger, conductor, and > performer — is that a caesura is generally longer than a comma/breath, and > intentionally interrupts the flow of the overall line, whereas the > comma/breath usually doesn't (or at least doesn't in as dramatic a manner). > > In musical theatre scores, the caesura is used almost exclusively when the > music completely stops and is restarted ‘from silence’ in the next phrase — > indeed, the caesura is quite often coupled with a fermata — whereas the > comma/breath is really only used in situations where the singer/performer > literally needs a little time to phrase off (either for dramatic or > technical/breathing purposes) but the music [in the accompaniment] basically > continues unbroken. > > Hope that helps add useful context! > Kieren. Thanks. Those are the intended semantics of the \breathe and \caesura commands in the code that is under development. — Dan
Re: Alternative music keeps staff alive
On Aug 9, 2022, at 02:31, Jean Abou Samra wrote:
>
> \new Staff {
> \alternative {
> \volta 2 c'1
> }
This unfolds better (but not well):
\alternative {
\volta 2 \new Staff ...
}
Conditional (folded/unfolded) context creation is something I thought of, but I
don't think I had a good solution for.
> The example above shows that \alternative sometimes keeps staves
> alive longer than they should be.
It could be a bug in the \alternative iterator. Please create a ticket and
assign it to me. Thanks.
—
Dan
Re: "Hymn template" snippet
On Aug 9, 2022, at 07:40, Trevor wrote:
> A comma is the standard way of writing a breathing point in vocal music. It
> is used extensively in Hymns Ancient and Modern, New Standard. Gould writes
> on page 436 in the Vocal Music chapter: "When a note should be sung for its
> full duration, with extra time for the breath, add a comma above the stave -
> this adds a short pause to the bar in which it occurs." No mention here of a
> caesura.
"The comma (턒) or diagonal-stroked caesura 턓 indicates that a note is sustained
for its full value, then extra time allotted for a short break in sound"
(p.187).
> If you change this snippet to use a caesura and render it as a comma in this
> section of the NR ("Chants, Psalms and Hymns") that would be OK I suppose
> (although \breathe seems the appropriate LP command), but "//" is definitely
> a no-no. I've never seen that in a hymnal.
\breathe takes time from the preceding note and \caesura adds time after it.
Which is better for this example?
The engraving is configurable. Note that Gould's "comma above the stave" is
something different than what \breathe currently engraves (see p.189), and
something I plan to support.
Also, what about the bar lines?
Thanks and regards,
—
Dan
Re: "Hymn template" snippet
Gilles, I would like to learn the reason for using \breathe and \bar "||" in the LilyPond snippet entitled "Hymn template" [1], Are they intended to communicate two different things, or was it merely a stylistic decision to use \bar "||" at the end of a system and \breathe in the middle? Also, why not use \bar "|." at the end? I want to revise this snippet to use \caesura (which is still under development) to end phrases, but I want to stay faithful to your intent. Thanks, Dan [1] https://lsr.di.unimi.it/LSR/Item?id=703
"Hymn template" snippet
"Hymn template" https://lsr.di.unimi.it/LSR/Item?id=703 I don't see any way to find the author of a snippet. I'd like to ask the author of this snippet about the reason for using \breathe and \bar "||". Are they intended to communicate two different things, or was it merely a stylistic decision to use \bar "||" at the end of a system and \breathe in the middle? I would like to revise it to use \caesura but stay faithful to the original intent. Thanks, Dan
Re: generate-documentation failure on context mods
On Jul 12, 2022, at 09:29, David Kastrup wrote:
>
>> Apparently, document-mod-list in document-context-mods.scm reads
>> an unbound variable.
>
> Well, yes.
>
> ((assign)
> (string-append
>(format #f "@item Sets translator property @code{~a} to" name-sym)
>(if (pretty-printable? value)
>(format #f ":~a\n" (scm->texi (car args)))
>(format #f " ~a.\n" (scm->texi (car args))
>
> Here (pretty-printable? value) should likely be (pretty-printable? (car
> args)) .
Thank you. I included this change in
https://gitlab.com/lilypond/lilypond/-/merge_requests/1525 by necessity.
—
Dan
Re: PATCHES - Countdown to August 8
On Aug 5, 2022, at 22:35, Colin Campbell wrote: > !1525 Divisio_engraver - Dan Eble > https://gitlab.com/lilypond/lilypond/-/merge_requests/1525 Those with an interest in ancient music, please take note. I don't want you thinking of me next time you are singing Psalm 94. — Dan
Re: Can't have rehearsal mark and segno mark at same moment
On Aug 3, 2022, at 17:22, Jean Abou Samra wrote:
>
> \version "2.23.12"
>
> {
> c'1
> \mark \default
> \repeat segno 2 {
> c'1
> }
> }
>
> A power user on -user-fr is frustrated that the above
> doesn't work, as rehearsal-mark-event and segno-mark-event
> are mutually exclusive at the same time step.
I'm willing to discuss it, but I don't think you should open an issue yet.
I try to be conservative because it's easier to relax the rules than to tighten
them. I have tried to keep in mind the possibility of creating new features
where LilyPond uses "the" label at a given point of the piece. (The jump
instructions already do some of this.)
Having both a rehearsal mark and a segno seems like an unusual editorial
choice, where it might make sense to force power users into workarounds so that
more casual users can benefit from the warning.
Before discussing solutions, what are the details of the use case?
* Is this about true rehearsal marks, or one of the (ahem) creative uses of
rehearsal marks that are floating around in snippets? (e.g., fermata, CD track
number)
* Does the user want the rehearsal mark to appear in addition to or in lieu of
the segno?
* What does the user expect the automatic jump instruction to say?
* Are these the user's personal preferences, or are there historical examples?
Regards,
—
Dan
Re: integrating Joram's 'visualindex'
> On Aug 3, 2022, at 07:24, Jean Abou Samra wrote: > > > >> Le 3 août 2022 à 13:12, Dan Eble a écrit : >> >> On Aug 3, 2022, at 06:10, Jean Abou Samra wrote: >>> >>>> Le 3 août 2022 à 11:44, Werner LEMBERG a écrit : >>>> >>>> >>>> Two weeks ago Dan asked the following: >>>> >>>>>> Can you force them to face each other? >>>>> >>>>> I think so, yes, with some TeX trickery. >>>> >> [… it is possible …] >>> >>> Sorry for jumping in as someone without any expertise in typography, but I >>> can’t help thinking: why create the problem if it doesn’t already exist? :-) >> >> If the index were split into two pages, I would prefer to see them together. >> >> I don't say that having to flip pages would rise to the level of "problem", >> but it would be an inferior experience. > > > I probably misunderstood the problem. Are you using a PDF reader where two > pages at a time are shown at a time like when reading a book? If so, I > understand the request. I thought this was uncommon, but I have no idea after > all. I usually use the Preview app in macOS, which has a few modes: • Show pages in a continuous scroll: Choose View > Continuous Scroll. • Show one page at a time: Choose View > Single Page. • Show two pages side by side: Choose View > Two Pages. — Dan
Re: integrating Joram's 'visualindex'
On Aug 3, 2022, at 06:10, Jean Abou Samra wrote: > > Le 3 août 2022 à 11:44, Werner LEMBERG a écrit : >> >> >> Two weeks ago Dan asked the following: >> Can you force them to face each other? >>> >>> I think so, yes, with some TeX trickery. >> [… it is possible …] > > Sorry for jumping in as someone without any expertise in typography, but I > can’t help thinking: why create the problem if it doesn’t already exist? :-) If the index were split into two pages, I would prefer to see them together. I don't say that having to flip pages would rise to the level of "problem", but it would be an inferior experience. If accommodating it would disrupt the rest of the NR, then I think it would be better to make the visual index a separate document. — Dan
GregorianTranscriptionStaff
GregorianTranscriptionStaff currently shows a time signature. Is that desirable? If it should be changed, feel free to list other things that should be changed. — Dan
Re: as_ly_scm_list
On Jul 27, 2022, at 02:02, Jean Abou Samra wrote: > > Did you mean for rather than if, or is this syntax I am not aware of? Yes, sorry. — Dan
Re: as_ly_scm_list
On Jul 25, 2022, at 16:09, Jean Abou Samra wrote:
>
> Now, the next question. Suppose I just want to iterate over the list, nothing
> else. (This is actually the only case I have found myself in.) Suppose I get
> this list from an lvalue. The compiler won’t let me use ly_scm_list (lvalue).
> Is there a way to use ly_scm_list nevertheless and not as_ly_scm_list in
> order not to put the reader in a mode where they look for in-place
> modifications of the SCM lvalue?
Readers will know that you are just iterating if you use a range-based for loop.
If the variable declaration is a reference, assignment modifies the current
list element (and readers will be expecting it).
// set! all elements of the_list to #f
if (SCM : as_ly_scm_list (the_list))
s = SCM_BOOL_F;
If the variable declaration is a value, then it is a copy of the current list
element, which can't be used to change the element.
if (SCM s : as_ly_scm_list (the_list))
{
// s is read, but probably not assigned to.
// If s is assigned to, it doesn't change the_list.
}
However, if s above refers to a smob, the smob can still be modified via s even
though the_list cannot. For a homogeneous list of smobs, we can hamper that;
for example,
if (const auto *col : as_ly_smob_list (the_list))
...
> Is there a way to use ly_scm_list ...
I am aware that I haven't actually answered this question.
—
Dan
Re: Fonts missing in development environment
On Jul 26, 2022, at 09:11, Walter Garcia-Fontes wrote: > > I checked, and the following packages are installed in my system: > > tex-gyre > texlive-fonts-extra > fonts-texgyre > > How can I get these missing fonts? Walter, I'm using https://github.com/fedelibre/LilyDev/blob/master/docker/Dockerfile and I don't see warnings. — Dan
Re: as_ly_scm_list
On Jul 24, 2022, at 19:04, Jean Abou Samra wrote: > > I understand that ly_scm_list takes an rvalue and disallows > lvalues for clarity, while as_ly_scm_list takes an lvalue, > and will fail on an rvalue by design, with the failure being > a compilation failure since e67154f7e330b61c5d9a973fbb89bd56866a148e. > > But I don't understand the real difference that distinguishes > them. Before that commit, what would have been the difference > between as_ly_scm_list (lvalue) and ly_scm_list (lvalue)? The difference is ownership of the head. ly_scm_list has one data member: private: SCM head_ = SCM_EOL; Creating an instance of ly_scm_list creates this head. If a list operation modifies this head, no other SCM is modified. ly_scm_list x (my_things_); // A. x.head_ = my_things_ ... x.clear (); // B. my_things_ is unchanged (B) might or might not be a problem. Without a comment, it can require deep review to tell whether leaving my_things_ alone was an error or not. Forbidding (A) means that people can't write such code, but there are times where we do want to work with a SCM like a ly_scm_list, including operations that change the head SCM. as_ly_scm_list casts a SCM to a ly_scm_list. There is no separate head because there is no new ly_scm_list, just a reinterpretation of the given SCM. auto& x = as_ly_scm_list (my_things_); // C. … x.clear (); // D. clears my_things_ Hope that helps. — Dan
Re: Countdown down?
On Jul 20, 2022, at 15:42, Colin Campbell wrote: > > It does, however, lead me to suggest to the developers that we go to a fixed > schedule, with countdowns beginning on Monday, Wednesday and Friday every > week, rather than the present, somewhat fluid, setup of every second day. That works for me. Thanks. — Dan
Re: \fine, pre-process-in-final-translation-timestep & co.
On Jul 19, 2022, at 18:46, Jean Abou Samra wrote: > > Then we have the style of solution found in !1451, with per-engraver > heuristics. I honestly dislike this. I don't want to sound harsh, but "\fine does not end iteration" https://gitlab.com/lilypond/lilypond/-/merge_requests/1496 — Dan
Re: \fine, pre-process-in-final-translation-timestep & co.
On Jul 10, 2022, at 12:04, Jean Abou Samra wrote:
>
> The currently recommended syntax for DS al fine
> repeats is
>
> \repeat segno 2 {
> c'1 1 1 1
> \volta 2 \fine
> c'1 1 1 1
> }
>
> This seems to work just as well, though:
>
> \repeat segno 2 {
> c'1 1 1 1
> \volta 2 \fine
> \volta 1 { c'1 1 1 1 }
> }
>
> Do you see downsides with that syntax?
Imagining myself in the position of a user looking at a black box, I would not
have much respect for a developer trying to make me believe that LilyPond needs
more information than "\volta 2 \fine" to determine that the work ends there.
I don't want to be that developer.
I won't rule it out, but it's not my first or second choice.
—
Dan
Re: Easy to tackle bug/feature
On Jul 18, 2022, at 09:49, Paulo Matos wrote: > > Anyway, let me take a look and see if I can make sense of it. Dan, are > you the right person to bother if I have any further questions? It is best to post questions to lilypond-devel so that everyone can participate in answering and learning. — Dan
