Re: Clef, key, and time-signature changes
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. Kevin
Re: On the ly: prefix...
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. Kevin
Re: MacPorts builds for 'Yosemite' and 'El Capitan' fail
On Sun, 5 Feb 2023 at 13:09, Jonas Hahnfeld via Discussions on LilyPond development wrote: > > Any workaround we introduce will have to be removed at some point. > When? 5 years after the last system goes EOL sounds like a reasonable > time, don't you think? So yes, in my opinion "must not". Workarounds don't have to be removed just because the software has reached a certain magic age. > > > The problem could also be in the used clang versions, which are > > probably used on non-macOS platforms, too. > > ... which is also 5 years old, so the same rationale applies. I think it's premature to preemptively object to all potential solutions. Maybe let's see if Dan has a suggestion. Kevin
Re: RFC: require librsvg to implement SVG image support
> My conclusion is that PDF is the more "logical" > successor to the inclusion of EPS.) I'm not on the user list anymore so I didn't see the poll. Personally I mostly work with EPS (for at least one publisher that I worked with it was the only acceptable vector format), but I'm glad that we polled users and I think it was the right thing to do. It's better to work backwards from the user experience to the technical decisions than the other way around. If you decide that svg is too much burden/debt/work then that is fine and we should communicate it like that, and not choose PDF because it's easier for us and then tell users it's what they *should* want anyway. > And this is exactly what scares me: I don't think we should go to all > lengths here in order to fulfill a user poll. I agree. But it's still good to know. The more demand there is for something, the more it will be worth a little effort. Re the RFC: my opinion on the inclusion of librsvg is that it's a good idea if users want it. I haven't done cross compilation with rust, but I have had some interaction with the tooling and I found it convenient/easy to use. I don't think it will add a significant burden. I'm not particularly knowledgeable about rust, but I'm happy to help with it. Kevin
Re: Testing binaries for 2.24.0 and release announcement
On Tue, Dec 13, 2022 at 10:44:26PM +0100, Jonas Hahnfeld via Discussions on LilyPond development wrote: > I also realized that I forgot to send a draft release announcement > text, which I originally wanted to share during the weekend. I went > with the standard text, copying from the previous stable release: SGTM; thank you for doing it. Kevin
Re: Guile potentially changing its GC a second time
On Thu, Nov 24, 2022 at 02:58:16PM +0100, Jean Abou Samra wrote: > What would be the difference with 'make doc'? I was referring to the kind of scores used to test/reproduce the heisenbug we had on Windows, i.e. designed to trigger GC-related problems. Would it be worth saving some scores like that in the codebase somewhere in case we want to stress test a new Guile release? > > In any case, a new Guile release series doesn't happen every > second day, and if we want to switch to a new one, there > should definitely be a mailing list thread where all details > of the transition are discussed, including how sure we are > that it works. For example, to switch to Guile 2.2, there was > a dual release and we removed Guile 1.8 support once it had > seen some use without major problems. Yes I suppose you're right. We can always save this conversation for when it happens. Kevin
Re: Guile potentially changing its GC a second time
On Thu, Nov 24, 2022 at 12:26:57PM +0100, Jean Abou Samra wrote: > Le 24/11/2022 à 12:12, Kevin Barry a écrit : > > GC is definitely not the kind of thing where "passes the > regtests" means there is no problem. As we have seen in the > past, the most infuriating and mysterious GC problems reproduce > 1 time in 20 doc builds ... This is not ideal, but would some kind of manually run test that does things like that (build a bunch of pathological-case scores 100 times) be a bad idea? There would be a maintenance burden, but it might mean we catch problems before breaking users' scores. The test could be run (by a human) when there's a new Guile release, or before we do a stable release, or some such. Kevin
Re: Guile potentially changing its GC a second time
On Thu, Nov 24, 2022 at 03:37:43AM +0100, Jean Abou Samra wrote: > Had anyone seen this?? No, but it's not surprising: Guile sometimes seems to be a one-person hobby project. It's not a project that cares much about breaking things for its users. > https://github.com/wingo/whippet-gc > > This looks like something we will need to watch. If Guile > switches from BDWGC to whippet-gc, I really hope LilyPond > won't need too much adapting and crazy debugging, but only > God knows. If even... One of the great things about Linux - and a major contributor to its success - is its golden rule of never knowingly breaking anything (in userspace). If it works today it has to work tomorrow. You aren't allowed to break it, *even* if you're fixing something more important. I wish more projects were like it (especially where I work). To practically answer your question: I don't think there's much we can do: we are more or less at the mercy of the Guile project. I'm tempted to suggest we add some tests that might catch breaking changes to Guile's GC, but of course our most recent issues were on Windows only, so our automated testing wouldn't have caught them anyway. Perhaps we could describe some manual tests that get run on new releases of Guile? (It's probably less work than rewriting LilyPond from scratch with a different embedded language :D.) Kevin > > There is quite a bit of chat about it on > > https://wingolog.org/ > > Jean >
Re: Prefer luatex for documentation, Re: Prefer luatex for documentation
On Mon, Nov 21, 2022 at 12:03:34PM +0100, Luca Fascione wrote: > I must say I don't understand this discussion. I agree with most of what Luca said. I'm sure whatever the maintenance burden is, Werner is likely to bear it himself. Supporting newer versions of tools may even help (cf. texi2html and texi2any). Either way, since he principally takes care of this part of the codebase I don't think we should use maintainability as an objection. This is not a drive-by patch. And we should care about improvements in typography. Kevin
Re: BDWGC fix in 2.24?
On Fri, Nov 18, 2022 at 11:06:45AM +0100, Jean Abou Samra wrote: > Hi, > > What should we do? Do we accept releasing 2.24 from > the release-8_2 branch in BDWGC even though it is not > released? Do we keep the current workaround, which still > gives some crashes? Do we replace our workaround > with Ivan Maidanski's patch, which seems to apply cleanly > on the v.8.2.2 tag? How sure are we that this patch fixes the issue? Assuming that it does fix it, then I think our options are: - release what we have anyway, and follow up with a patch release removing our workaround when it's no longer needed - wait for the patch to be released My personal preference is for the latter option, but I think either option is OK. I don't like the idea of a stable release built from an unreleased version of BDWGC. Kevin
Re: markup->string
On Tue, Nov 15, 2022 at 02:49:55PM +0100, Jean Abou Samra wrote: > Le 15/11/2022 à 14:43, David Kastrup a écrit : > > If it's "mundane", why would the conversion result in a complex > > replacement? > > Have you looked at the replacement? > > It is > > (lambda* (m #:optional headers) > (if headers > (markup->string m #:props (headers-property-alist-chain headers)) > (markup->string m)) I agree with others' assessment that this doesn't "look" good: it's taking logic that, in a perfect world, would be internal to convert-ly, and inserting it into users' documents. We wouldn't advise users to write this logical check in a new score. We would tell them only to use whichever of the two options applies to their use. > The "complexity" we are talking about is the length of the output > of convert-ly relative to the input. There is no complex logic > at all. Well yes, but for many users it would be replacing something short or simple with something they are not familiar with. The merge request you raised to address it looks good (especially because it only warns for anything more complex than `(markup->string )` Kevin
Re: Potential LSR licensing violations
On Fri, Oct 21, 2022 at 01:27:07PM +0200, Jean Abou Samra wrote: > It would have helped IMO if all the more or less unrelated side > questions had been raised in separate threads… Well yes, but it's totally unavoidable any time licencing comes up for discussion. The subject itself seems to be a magnet for generating endless pontificating (I'm guilty of this too). I see some messages in this thread about how included style files in LaTeX mean the resulting PDF is GPL. It reminds me of a similar discussion about LilyPond some years ago (about '\include "english.ly"' I think) that went nowhere, wasted everyone's time, and was never resolved. That discussion probably did the most in putting me off the subject for life. > What's the specification of that job? > > As I wrote to Harm (but maybe the mailing list didn't > deliver that post to you yet), I don't think there is > a lot to do. If you see a clear license violation, > correct it, as we've done here. The question of whether it's a requirement or not has nothing to do with how onerous it is. I can't weigh in on the specification of the duties because I wouldn't particularly be in favour of adding that responsibility to the LSR maintainers (but I won't object either). Kevin
Re: Potential LSR licensing violations
On Fri, Oct 21, 2022 at 01:12:09PM +0200, Jean Abou Samra wrote: > -- AFAIK, this is the first time we have to do a relicensing, > and the odds of a legal case involving LilyPond are very small > due to its low-key profile in the industry. I feel this would > be much ado about nothing. This is why I think it's usually better not to pay any attention to licence issues that don't come in the form of cease-and-desist or whatever. This whole exercise was (IMO) much ado about nothing. And we are now left with the question of whether licensing is now part of the duties of LSR editors. As Thomas said, it's not mentioned in the CG. I guess we have to add it? Kevin
Re: Potential LSR licensing violations
On Thu, Oct 20, 2022 at 02:32:58AM +0200, Jean Abou Samra wrote: > What should we do about these snippets? Delete them? My two cents is that we should leave it alone and not spend time talking about licences because those discussions rarely arrive at answers, and most of the time there isn't really a problem except in someone's imagination. Kevin
Re: weird error engraving two files with 2.23.14
> I tried 2.23.12 and I got the same error. Do you remember what version it last worked with? > It works great using the cairo backend! > I wanted to test it so I think I'll set it as default for all my scores. > What are the current drawbacks? There's any page in the docs about cairo? It looks like there was some kind of mixup adding info about cairo to the changes doc. I can see the doc code in this diff: https://gitlab.com/lilypond/lilypond/-/merge_requests/1651/diffs?commit_id=1df07dd726ff8bf16e60501080fcbd47b82ae6d4 but it looks like that merge request somehow didn't end up including that. I'll see about preparing a patch for it. To summarise what's there: it should be an improvement over ghostscript, but it's still experimental and doesn't implement all of the features of the other backends (I can't remember what, if anything, is missing). Kevin
Re: weird error engraving two files with 2.23.14
Hi Federico, On Thu, Oct 13, 2022 at 01:06:17AM +0200, Federico Bruni wrote: > Hi folks > > I've recently used convert-ly to update my private music sheet library and > test version 2.23.14 (official binaries). > Two files are failing with the same error message: Did this work with 2.23.13? Or what was the last version it worked on? > Any idea about the cause? I'm using a different font for tablature numbers, > but commenting that line still triggers this error. > These two files are copyrighted and I can't share them here, but I will send > privately to anyone interested in debugging this issue. On the surface it looks like a problem with ghostscript, but it's not clear. If you remove all font changes does the error still occur? Can you send on the verbose log for that? Also, if you are willing to try it, see if adding the option -dbackend=cairo (which should avoid calling ghostscript) also fails (you may need libcairo or some such installed on your system for this). Kevin
Re: Updated release schedule
On Mon, Oct 10, 2022 at 11:08:57PM +0200, Jonas Hahnfeld via Discussions on LilyPond development wrote: > Hi all, > > Yes, I'm trying to slightly shorten the timeline to three weeks between > the release candidates in an attempt to get a release before the end of > the year. We will see how this will work out... Thank you for doing this. It looks good. Kevin
Re: To branch or not to branch
On Wed, Oct 05, 2022 at 03:40:03PM +0200, Jonas Hahnfeld via Discussions on LilyPond development wrote: > > Silence means consent. > > How can you consent to a question, whether to branch or not? This > time I even explicitly asked for thoughts. A (stable) release should > be a team effort, that's not something a single person should or want > to decide... I think I already weighed in in support of the idea. I don't know how else I might contribute, but I would like to help if there is anything I can do. Kevin
Re: To branch or not to branch
> In the last discussion on this topic in > https://lists.gnu.org/archive/html/lilypond-devel/2022-09/msg00070.html > the rare crashes on Windows were identified as a blocker. These seem to > be fixed now, at least for reasonable user scores (we can still trigger > it when running the garbage collection in every translator slot); see > https://gitlab.com/lilypond/lilypond/-/issues/6361 for full details. You asked for comments so I'll give mine: I think we should proceed with 2.24, but with some kind of planned response for a situation where users report experiencing the Windows crashes on a "normal" score. Kevin
Re: Lilypond build dependency tlasm
I have no issues when I Google it. Did you search for tlasm or t1asm? Kevin On Wed 7 Sept 2022, 09:51 Andrew Bernard, wrote: > I cant find out what tlasm is. It's a missing dependency for the build. > Google's indexing of billions of pages produces nothing, unless I am > dreaming. Could somebody help me understand what this program is and > where to find it? > > ../configure outputs: > > ERROR: Please install required programs: t1asm > > > Andrew > > > >
Re: eps backend in latest master
Following up on this with a solution based on Han-Wen's comments in that issue: I can replace `#(ly:set-option 'backend 'eps)` with: ``` #(ly:set-option 'separate-page-formats 'eps,png,pdf) #(ly:set-option 'use-paper-size-for-page #f) ``` And that restores the old behaviour. I'm not sure if it should be socialised or not. The previous way of doing it didn't make any more sense. Kevin On Wed, 17 Aug 2022 at 17:14, Kevin Barry wrote: > > Thank you that definitely looks related! I have posted a comment there. > > On Mon, 15 Aug 2022 at 21:35, Jean Abou Samra wrote: >> >> Le 15/08/2022 à 18:12, Kevin Barry a écrit : >> > Hi all, >> > >> > I used to have a style file for creating musical examples (typically, for >> > printed books and the like) that handily produced cropped images by setting >> > the backend to eps (and removing margins and headers and footers). I >> > noticed that this has stopped working in latest master and I am unable to >> > exactly replicate the behaviour. The crop option does not preserve the >> > space between systems so it's no good. Is there another way to get the old >> > behaviour? >> > >> > Kevin >> >> >> Possibly the same problem as >> https://gitlab.com/lilypond/lilypond/-/issues/6235 >> >> I never took the time to understand all the backend options, there are >> many of them and they've evolved a lot in 2.23.x… I would say that some >> documentation section comparing them would be welcome. >>
Re: eps backend in latest master
Thank you that definitely looks related! I have posted a comment there. On Mon, 15 Aug 2022 at 21:35, Jean Abou Samra wrote: > Le 15/08/2022 à 18:12, Kevin Barry a écrit : > > Hi all, > > > > I used to have a style file for creating musical examples (typically, for > > printed books and the like) that handily produced cropped images by > setting > > the backend to eps (and removing margins and headers and footers). I > > noticed that this has stopped working in latest master and I am unable to > > exactly replicate the behaviour. The crop option does not preserve the > > space between systems so it's no good. Is there another way to get the > old > > behaviour? > > > > Kevin > > > Possibly the same problem as > https://gitlab.com/lilypond/lilypond/-/issues/6235 > > I never took the time to understand all the backend options, there are > many of them and they've evolved a lot in 2.23.x… I would say that some > documentation section comparing them would be welcome. > >
eps backend in latest master
Hi all, I used to have a style file for creating musical examples (typically, for printed books and the like) that handily produced cropped images by setting the backend to eps (and removing margins and headers and footers). I noticed that this has stopped working in latest master and I am unable to exactly replicate the behaviour. The crop option does not preserve the space between systems so it's no good. Is there another way to get the old behaviour? Kevin
Re: RFC on MR 1368
> Also technically I cannot "block contributions", nobody in the > community has the power to do so. > This might be true technically, but in practice your objections are usually enough.
Re: RFC on MR 1368
On Wed, 25 May 2022 at 07:38, Han-Wen Nienhuys wrote: > > I equally object to any contribution being merged "because the author > knows what he's doing". > > I object to reviewers blocking contributions just because they have a > strong opinion on how things should be done. In this case, Jonas has > made 0 contributions to the MF code, so I don't think his concerns > should be overriding. > > If Jonas feels really strongly about how the kerning should be > handled, I invite him to teach himself the joys of Metafont and try > his hand at a follow-up MR. > I agree with this. We should accept Werner's change. And, more generally, I think we should err on the side of accepting contributions. Kevin
Re: Stepping down from Patch Meister role
Hi James, This is a big loss; you will be missed. Thank you for all of your hard work. > I want to stay a > developer and that conflicts both time-wise and with respect to > impartiality. Finding a non-developer to fill James's shoes sounds difficult. I would volunteer, but I still plan to contribute patches. Kevin
Re: Cairo plans
> This use case continues to be supported with > Cairo. Just convert \postscript to \path, wich > works both in the current PS backend and with Cairo. Is this something that can be done automatically with convert-ly? If not then does it justify a major version bump? Kevin
Re: Cairo plans
These changes/improvements are exciting. Thank you and Knut for the hard work! > > I would say that this step requires going to LilyPond 3.0, along with > > removing all the features and commands that cannot be implemented in > > the Cairo backend, or that we don't want to. > > We can discuss this in detail later, but I think a major version bump > is not warranted, as we're leaving the music input intact. I would also have been inclined to say this suggests a major version bump. But if what you say is true - that input is completely unchanged - then it may not be necessary. Will the loss of the ps-command affect users? Kevin
Re: PATCHES - Countdown for August 21st
> I'd be grateful if someone could merge this one (on a phone, and GitLab seems > to heavy for it...). > > Thanks, > Jean Done
Re: Building in WSL
> > I resorted to using WSL out of desperation on a system where I can't > > get the wifi to work on Linux. I was able to develop on LilyPond more > > or less unhindered (until I checked again recently). If you have a > > Linux system there's no reason to use WSL (IMO). > > Quite. The final irony in my case (and why I haven't had to use WSL recently) was that I managed to figure out that my wifi woes in Linux were actually caused by Windows: the fast boot/startup feature leaves the wifi card in a partially powered state that (apparently) only it can revive it from. I wasted a lot of time troubleshooting thanks to that. Kevin
Re: Building in WSL
Hi James, > I cannot even get autogen.sh to run! > > > -bash: ./autogen.sh: /bin/sh^M: bad interpreter: No such file or directory > > This appears to be caused by a line ending difference betwen *nix and > Windows. That's odd; did you clone the repo from within WSL or from Windows? > > Ugh. So much for WSL. I keep running into issues like this and yet some > people keep insisting to me that WSL == Linux (or as good as). I resorted to using WSL out of desperation on a system where I can't get the wifi to work on Linux. I was able to develop on LilyPond more or less unhindered (until I checked again recently). If you have a Linux system there's no reason to use WSL (IMO). Kevin > > Oh well. So much for compiling on WSL. > > James > > > > > > > > Thanks for taking the time. I cannot recall what error I had now - the > > machine that WSL is on is a work machine so I tend to keep it clear of > > personal stuff but I was curious and had some time on my hands - but I > > do remember being able to build LilyPond just not the doc. > > > > I'll check again next week, maybe try an earlier version of Ubuntu if > > such a thing exists on MS marketplace these days. > > > > James > > > > > > > >> > >> > >> On Wed, 9 Jun 2021 at 10:49, Kevin Barry wrote: > >>> Hi James, > >>> > >>> I'm pretty sure that I managed this, but I may not have gone as far as > >>> a full doc build, but I think I managed install-info. I will try to > >>> make time to verify and get back to you. > >>> > >>> Kevin > >>> > >>> On Wed, 9 Jun 2021 at 07:37, James wrote: > >>>> Hello, > >>>> > >>>> Has anyone on this list recently (within the last year or so) ever > >>>> managed to build LP and its Doc using WSL - specifically version 2 > >>>> (I am > >>>> using Ubuntu 20.04)? > >>>> > >>>> Every now and again I go back and reclone the entire git dir and go > >>>> through the setting up of software dependencies etc. but I've never > >>>> managed ever to get a full doc build to complete. > >>>> > >>>> I haven't done any useful debugging as I have a linux box that works > >>>> fine so it's not a huge deal but I was wondering if anyone on this > >>>> list > >>>> had ever tried on WSL and got it to work. > >>>> > >>>> -- > >>>> -- > >>>> > >>>> regards > >>>> > >>>> James > >>> > > > > > -- > -- > > regards > > James >
Re: Building in WSL
OK well something must have changed since I last did a build on WSL because I couldn't even get `make all' on a freshly checked out master to work. And that was *definitely* working before. It fails now with this error: Making Documentation/out/en/changes.texi < tely lilypond-book.py: error: file not found: version.itexi I'm running Ubuntu 20.04 on WSL 2. My normal Linux system doesn't have the same problem. Kevin On Wed, 9 Jun 2021 at 10:49, Kevin Barry wrote: > > Hi James, > > I'm pretty sure that I managed this, but I may not have gone as far as > a full doc build, but I think I managed install-info. I will try to > make time to verify and get back to you. > > Kevin > > On Wed, 9 Jun 2021 at 07:37, James wrote: > > > > Hello, > > > > Has anyone on this list recently (within the last year or so) ever > > managed to build LP and its Doc using WSL - specifically version 2 (I am > > using Ubuntu 20.04)? > > > > Every now and again I go back and reclone the entire git dir and go > > through the setting up of software dependencies etc. but I've never > > managed ever to get a full doc build to complete. > > > > I haven't done any useful debugging as I have a linux box that works > > fine so it's not a huge deal but I was wondering if anyone on this list > > had ever tried on WSL and got it to work. > > > > -- > > -- > > > > regards > > > > James > >
Re: Building in WSL
Hi James, I'm pretty sure that I managed this, but I may not have gone as far as a full doc build, but I think I managed install-info. I will try to make time to verify and get back to you. Kevin On Wed, 9 Jun 2021 at 07:37, James wrote: > > Hello, > > Has anyone on this list recently (within the last year or so) ever > managed to build LP and its Doc using WSL - specifically version 2 (I am > using Ubuntu 20.04)? > > Every now and again I go back and reclone the entire git dir and go > through the setting up of software dependencies etc. but I've never > managed ever to get a full doc build to complete. > > I haven't done any useful debugging as I have a linux box that works > fine so it's not a huge deal but I was wondering if anyone on this list > had ever tried on WSL and got it to work. > > -- > -- > > regards > > James >
Re: [PoC] EXPERIMENTAL binaries of LilyPond 2.22.1
Do Debian package LilyPond for aarch64? If they do, their build scripts are probably available somewhere. On Thu, 20 May 2021 at 07:26, Jonas Hahnfeld via Discussions on LilyPond development wrote: > > Am Mittwoch, dem 19.05.2021 um 22:54 +0200 schrieb Federico Bruni: > > On Thu, May 13 2021 at 22:46:58 +0200, Jonas Hahnfeld via Discussions > > on LilyPond development wrote: > > > After some work, I built binaries from the released sources of > > > LilyPond 2.22.1 for > > > * Linux (compiled on CentOS 7; tested on Arch, CentOS 8, Ubuntu > > > 18.04) > > > > Have you thought about adding more architectures? I'm thinking of > > aarch64 in particular. > > Yes, I *hope* that it would be straight-forward to produce binaries > with the same set of scripts, provided dependencies like Guile and > friends don't choke about the architecture. It clearly needs a native > build host, but it's not obvious to me how much users (would) run > LilyPond on AArch64... > > Jonas
Re: Looking for contractor
Hi Tim, I wish I could volunteer for this, but I have a full-time job, and I'm not really knowledgable enough to do it without help. But I will help if I can. Han-wen opined on the merge request he opened for this issue last year that we would probably have to replace our current pdf rendering system (ghostscript) with an alternative (e.g. libcairo). That sounds like a significant change. I would like to hear what other developers think. Kevin On Tue, Apr 27, 2021 at 09:38:58AM +1000, Tim Starling wrote: > I'm looking for a developer who would like take on a contract to > improve LilyPond security. > > The work would be as discussed last October on this mailing list: > https://lists.gnu.org/archive/html/lilypond-devel/2020-10/msg00096.html > > My summary is as follows: > > * Make all parser-related modules safe. In ly_make_module(), always > use a safe module (make-safe-lilypond-module or make-safe-module). > Remove the reference to Guile_user::the_root_module. > * Work through the consequences in order to allow typical real-world > input files to be rendered as before, without errors. > * Ensure that the documentation and regression tests can still be built. > * Propose code changes so as to update the version to 3.0.0. > > Please tell me if I'm missing something in this summary or if there is > something you would like to add. The scope should be sufficient such > that the changes can be accepted and released. We don't want to leave > it half-done. > > I am looking for someone who is familiar with LilyPond and has > previously submitted code which I can review. > > Please let me know if you are interested. > > -- > Tim Starling > Principal Software Architect > Wikimedia Foundation >
Re: State of LilyPond with Guile 2.2
On Sun, Apr 11, 2021 at 08:11:37PM +0200, Jonas Hahnfeld via Discussions on LilyPond development wrote: > So, that was the main question of the message (sorry if that got hidden > in the lengthy text and many numbers): What is "reasonable"? I think > the numbers I showed are reasonable, but that's certainly subjective. > Yes, they are slower than Guile 1.8 but there'll be a trade-off at some > point. I don't know if my opinion counts, but... Based on the numbers in this thread and the ones from the recent thread with the Guile developer (? whose name escapes me) I think we should move to Guile 2.2 (i.e. make it the default and stop supporting 1.8) as soon as reasonably possible and just accept the deterioration in performance. I don't think we have much to gain by continuing to wait: Guile has already moved on to version 3 so we cannot expect performance problems with 2.2 to change much or go away. The only alternative seems to be Han-wen's suggestion of forking Guile 1.8. I don't know all of the implications of that. Lots of downsides are immediately apparent for developers, but on the other hand everyone is affected by performance so maybe we should give it serious thought. (But again: if there is agreement that this is not the right course then I see no reason not to immediately abandon 1.8.) Kevin
Re: Reducing the number of open issues
On Wed, Mar 17, 2021 at 08:10:08PM +0100, Jonas Hahnfeld wrote: > In the longer term, I think it could make sense to hold a "bug bash > weekend" and try to pick some low-hanging fruits. That would not be > limited to developers to write patches, but everybody to try and > reproduce old reports with the then-current unstable release and close > issues that are no longer relevant. Let me know if this sounds > interesting and you'd be prepared to participate. I would be willing to participate in something like this. Kevin
Re: search-box.ihtml not tracked by check-translation script?
Hi Federico, I don't know anything about this part of the code, but the relevant errors from the doc build pipeline seem to be: no such file: search-box.ihtml: No such file or directory at /builds/lilypond/lilypond/Documentation/lilypond-texi2html.init line 836. /builds/lilypond/lilypond/build/.././Documentation/GNUmakefile:246: recipe for target 'out-www/cs/web-big-page.html' failed Does that point you in the right direction? Kevin On Fri, 18 Dec 2020 at 20:27, Federico Bruni wrote: > > I've just submitted a MR: > https://gitlab.com/lilypond/lilypond/-/merge_requests/545 > > but it doesn't pass the doc build pipeline. > > It worked for me on my computer, even though only english docs were > built. > Basically I just added 'en' to the LY_LANGUAGES variable before the > other languages are appended. > > Any advice is welcomed! :-) > > > > Il giorno mer, dic 9 2020 at 00:38:05 +0100, Federico Bruni > ha scritto: > > Any reason why search-box.ihtml is in Documentation/ instead of > > Documentation/en? > > It seems it's causing troubles to the check-translation script: > > > > $ cd Documentation > > $ make ISOLANG=fr check-translation | grep 'diff --git' > > warning: fr/search-box.ihtml: 128 fatal: path > > 'Documentation/en/search-box.ihtml' does not exist in 'HEAD' > > > > > > > > >
Re: RFC: rethink horizontal alignment of mid-staff bar numbers
On Sun, Nov 15, 2020 at 01:37:34PM +, Graham King wrote: > I think Gould's positioning looks _slightly_ better, except at > line-beginnings where I definitely prefer lilypond's. Moreover, the > position immediately after a bar line is heavily-contested > real-estate, as your examples make clear. Therefore it would be good > to retain the option to preserve the status quo, especially where > convert-ly might otherwise cause skyline changes to existing scores. Thank you for your input! Jean's code makes it possible to restore LilyPond's current behaviour with a single override: \override Score.BarNumber.self-alignment-X = #1 The examples in the pdf differ only in that value: - LilyPond: 1 - This MR: 0 - Gould: 1 - Even farther to the right: 1.55 (I'm not sure how Jean Abou chose that value) So, at the very least, the added code will make it easier for users to choose their preferred alignment. If it turns out that most people prefer to keep LilyPond's current behaviour I will still submit a merge request for Jean Abou's alignment code, just with a default value that preserves current behaviour. I appreciate that you have given a nuanced response. Practically speaking, the vast majority of scores only have bar numbers at the beginning of a line, so I will simplistically categorise your response as in favour of keeping LilyPond's current behaviour. Kevin
Re: RFC: rethink horizontal alignment of mid-staff bar numbers
On Sun, Nov 15, 2020 at 07:07:03AM -0600, David Nalesnik wrote: > Another vote for Gould. (Though does she have anything to say about > the normally unshown measure numbers which are stranded beyond the > line here?) Those are included in the examples purely for the sake of completeness. Gould has nothing to say about such bar numbers and I would surprised if any scores included them. Kevin
Re: RFC: rethink horizontal alignment of mid-staff bar numbers
On Sun, Nov 15, 2020 at 11:02:52AM +, Kevin Barry wrote: > - if you have a preference for one of the four, please indicate which I will be the first responder and say that, of the options in the pdf, I think Gould is the most appropriate. Kevin
Re: tie over clef change
> Both cases were discussed. For an orchestra they are not the same pitch, thus > formally a slur. You cannot make this assumption. It is exceptional to distinguish D sharp and E flat since most performed orchestral music is equally tempered. It is common, for example, for a composer to write D sharp for some instruments and E flat for others.
Re: tie over clef change
On Sat, 26 Sep 2020 at 19:30, Hans Åberg wrote: > The notes d♯ to e♭ have different pitches in the staff notation > system, which cannot express E12 enharmonic equivalents, so this > is slur. So it should be a slur that looks like slur. > > > > I disagree. For all practical purposes in standard classical music, > > enharmonic equivalents *do* sound the same. What you are referring to > > IMHO is a special case that might be controlled by a flag. > > They do not, and the string section, that primarily stands for the pitch > reference, trains to slide the pitch appropriately: In some contexts a notated D sharp and E flat are the same pitch (e.g. equally tempered piano music) and in some they are not (as you pointed out). Since this is a discussion about ties, where the note is the same by definition, we can assume we are dealing with the same pitch. The question isn't whether it's a tie or a slur, but how LilyPond should render a tie when the two notes are not aligned (i.e. the user has entered a "~" indicating that it's a tie). I agree with Gould that ties across clef changes should be avoided (I personally wouldn't even do it in the Liszt example posted), but I think LilyPond needs to handle it. I think it's quite acceptable to detect this situation and switch to using a slur (but I haven't looked at the code). Kevin
Re: branching stable/2.22?
> I concur with the idea that a properly functioning full conversion to > Python 3 and workable (though not required) Guile 2 constitutes sufficient > change for the next stable version. No other features are needed. I agree with this. Kevin
Re: accent glyphs too large?
> OK, thanks. Reducing the size of the accent glyph (both vertically > and horizontally) is a rather trivial change in Emmentaler, and I > could submit an MR. However, it might have a large impact on > formatting older documents. Is this something we should be concerned? > Given that we adjust glyphs here and there from time to time I would > say it doesn't matter much, but I would like to hear opinions. I looked in Gould for an example where an accidental and an accent coincide in a similar manner to your example, but I couldn't find one. I think the change is an improvement, and making something smaller is less likely to have a negative impact on older documents than making something bigger would be. Kevin
Re: Help fixing issues 4182 and 4691
Hi Dan, Thank you for responding. > If this problem involves a twisty maze of callbacks and pure-impure > properties, it's unlikely that anyone's knowledge reaches the level of > expertise you're hoping for. That is a pretty accurate description of it: there are about 50 stack frames between where I think the problem starts to where the error happens. I'll try diving in again and see if I can come up with a better suggestion than my last one. Kevin
Re: glissando lines and accidentals
> By the way, do you agree that this is a bug in LilyPond? Gould suggests it is: the example on page 143 in my edition of Behind Bars, from a Bartok string quartet, shows only the glissando lines that run into an accidental getting shortened (in fact, when there are enough accidentals that there are two columns of them, a glissando that runs into the accidental that is farther away from the note head will stop for the accidental and start again afterwards to fill the gap). She also says the lines should be parallel for parallel glissandos. Kevin
Help fixing issues 4182 and 4691
Hi Developers, I'm struggling with trying to fix these two issues so I'm asking for help from someone with a better knowledge of LilyPond internals. I have spent a couple of weeks looking at the code and trying different solutions (in both C++ and Scheme), so I think I have some understanding of the problem, but I have no idea about how/where to solve it and would like some guidance. I won't go into details about the nature of the bugs but they are both related to cross-staff beams. I know everyone is busy, but I think it would be worth the time to help get two regressions fixed (and maybe I'll learn something from it that means I won't need help next time). Feel free to reply on or off list. I'll be very grateful! Kevin
Re: Accidentals' font
> Again, I hope I am not unpleasant and polemic In my opinion, you are being both. If your goal was genuinely to encourage improvements in LilyPond, then I hope it's clear from the response that you are going about it in a poor way. Acting like it's obvious that LilyPond's default font is badly designed is insulting, and hiding insults behind your "opinion" isn't fooling anyone - it just comes across as superior / talking down. If fonts were so easily comparable as you are pretending, then we wouldn't have so many of them. The philosophy behind the design of LilyPond's default font was to imitate plate engraving (which results in thicker lines than computer engraving, partly because of "squeeze"), not to imitate another computer font like Gonville, so all this Gonville talk is hot air. If you don't like them that's not the fault of the font. Regarding the attachments: in my opinion the lines in the sharp symbol in Gonville are too thin and too close together - I have to squint at it to see the gap properly. And for the clef test I actually don't perceive any real difference other than the "C" for the time signature (and again, I prefer the thicker version). Kevin
Re: new procedure with GitLab CI
The fast-forward rebase has two advantages that I can think of: - the git history is cleaner/easier to parse - it prevents the situation that sometimes arises where a couple of patches - that pass testing independently, but will break when combined - from making it into master (and breaking it) If we move to merge commits our git history will mostly have a merge as every other log entry. It's a small loss, but a tolerable one in my opinion. I don't know how people feel about the second issue. The staging branch existed in the past to stop such breaks making it into master. Maybe it's OK since our source of truth is still on Savannah? I don't have strong opinions about it. Is it a crazy idea to consider some automatic way of doing the rebase + merge on all branches in Patch::push state? I believe Gitlab allows for scheduled pipeline execution. (I'm just throwing the idea out there.) Kevin > > > > I’m not knowledgeable enough to discuss the benefits and downsides of > > merge commits vs fast-foward rebase, so I’ll leave it to others. But > > I think you make a valid point in that our current linear > > mandatory-rebase strategy is cumbersome, heavy on the CI pipelines and > > generating a lot of noise. > > I would like to comment on the last two points: > * "heavy on the CI pipelines": The number of pipelines wouldn't change > with merge commits. We still get one pipeline per push and we would > want to get testing before a set of changes hits master. This is the > same as we have right now. > * "generating a lot of noise": The only "noise" is the rebase > operation before merging. Everything else will stay the same: review > comments, discussion, notifications about pushes, etc. > NB: I don't see a need to rebase during review. If you chose to do it > anyway, the same "noise" applies after switching to merge commits. > > The only advantage of merge commits that I agree with is GitLab's > ability to queue merges and perform them automatically. That may > qualify as less "cumbersome", but lowering the expectation that every > merge request in Patch::push must be merged on the same day will get us > the same result, without any change. > > > That being said, that’s only one of the three issues I raised in my > > latest message (the other two being: how we’ll be handling Issue pages > > from now on, and how patch reviewing can be made a bit more lenient > > and smoother). > > Please see my replies from last Saturday which went unanswered AFAICT. > > Jonas > > > > Jonas has started updating the CG, but that’s bound to reach a > > roadblock if the underlying policies are not discussed and agreed upon > > first. > > > > Cheers, > > -- V.
Re: [RFC] Enabling GitLab CI
On Mon, May 18, 2020 at 11:29:35AM +0100, James Lowe wrote: > Countdown.py (which is Jonas' great cli tool) it's what you see when I do > the countdown (that's literally cut/paste). I haven't seen that script, but the gitlab API exposes pipeline information. It should be enough to correlate a merge request with a pipeline status (running, pending, success, failed, etc).
Re: [RFC] Enabling GitLab CI
On Mon, May 18, 2020 at 12:17:53PM +0200, Urs Liska wrote: > No, at least not at the time I looked. > What James needs is additionally an icon that states that MR is > *currently* being tested. There is an icon for that (it's blue and looks like a half-filled pie chart) - I just couldn't find a merge request list that actually had any in progress.
Re: [RFC] Enabling GitLab CI
On Mon, May 18, 2020 at 10:48:55AM +0100, James Lowe wrote: > but how do I know? That is the nub of what I am asking. If a patch is 'new' > how do I know that an automated make doc is 'in progress, has completed with > errors, has completed without errors' as I am not going to bother to do any > work on it if it is the first two cases. What is the point? The merge request list has an icon next to every merge request showing the current pipline status. There are different icons for passed, failed and in-progress. Is that what you want? See the merge request page for inkscape: https://gitlab.com/groups/inkscape/-/merge_requests Is the information you would like to be able to see visible there? It will only show a pass if all stages pass, as far as I know. Kevin
Re: README.md (was: migrating to GitLab)
On Sun, May 17, 2020 at 10:08:12AM +0200, Urs Liska wrote: > Do I understand you correctly that README.txt is generated upon > compiling LilyPond? So where does it end up, I couldn't find a > README.txt neither in the source repository nor in the installation > directory. Does it only end up in the documentation (which I haven't > built locally)? It gets built during a normal make all build. The source seems to be Documentation/topdocs/README.texi. The built version seems to appear in Documentation/topdocs/out.
Re: PATCHES - Countdown for May 15th
On Fri, May 15, 2020 at 04:25:52PM +0200, Jonas Hahnfeld wrote: > That the script is doing exactly what I told it to do: The diff between > the previous and the rebased commit is not empty. Therefore it adds the > Patch::new label, removing Patch::push. Shouldn't `diff staging...HEAD` be the same before and after a rebase (three dots)?
Re: Verifying issues on Gitlab
Hi Federico, Thank you for the instructions. I will try to help get them done as well. On Tue, May 12, 2020 at 12:28:24AM +0200, Federico Bruni wrote: > In the last comment you should find a commit id (if it's missing you'll have > to search it). > The easiest and quickest way to verify that a certain id has been included > in the release tag label used in the issue is using Github. Start from this > URL: Another handy way to do this is to run git tag --contains . (For me this is faster than github.) Kevin
Re: How are dynamics (self-)aligned exactly?
Hi Valentin On Sun, May 10, 2020 at 10:13:04AM +0200, Valentin Villenave wrote: > Greetings, > > could anyone give me a hint as to where dynamics alignment is handled? > As far as I can see, the self-alignment-interface functions are not > used by the (formerly new) dynamic-engraver; and AFAICS the following > diff doesn’t break compiling nor change any of the regtests: As far as I can tell, the self-alignment-interface functions are called by Grob::try_callback_on_alist (grob.cc). The callback is actually run by scm_call_1 so perhaps whatever magic (DECLARE_SCHEME_CALLBACK ?) makes c++ procedures like aligned_on_x_parent available to scheme works without including the header files in the c++ files that use scm_call_X. This is just a guess though... Kevin
Re: Issue 3778: Use bounding box as skylines for markup in svg backend (issue 582010043 by barr...@gmail.com)
I will close this rietveld issue now that you are taking care of it. Whatever discussion needs to take place can happen at the one you have opened. On Sat, May 02, 2020 at 11:54:14AM +0200, Han-Wen Nienhuys wrote: > See http://codereview.appspot.com/545970043 > > note: > 1) Depending on the renderer, the skylines diverge from the text. > Inkscape reproduces exactly, but EOG messes up the text formatting. > > 2) The lack of regression testing is worrying. We could have a section > of regtests that is powered by > > inkscape --export-background-opacity=1.0 --export-background=white > --export-type="png" svg.cropped.svg > > and then do imagemagick diffs on the result. > > On Sat, May 2, 2020 at 10:53 AM Kevin Barry wrote: > > > > On Sat, May 02, 2020 at 09:59:18AM +0200, Han-Wen Nienhuys wrote: > > > Not necessarily, but the refactoring means I'll likely have to > > > overwrite the fix wholesale. Because there is no regtest, it willl > > > depend on my diligence anyway to fix this again. > > > > OK, so what should we do? I am happy to take responsibility for making > > sure it stays fixed after your work (even if that means another patch), > > but if there's some way I can rebase it off your work that would be fine > > too. > > > > -- > Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Issue 3778: Use bounding box as skylines for markup in svg backend (issue 582010043 by barr...@gmail.com)
On Sat, May 02, 2020 at 09:59:18AM +0200, Han-Wen Nienhuys wrote: > Not necessarily, but the refactoring means I'll likely have to > overwrite the fix wholesale. Because there is no regtest, it willl > depend on my diligence anyway to fix this again. OK, so what should we do? I am happy to take responsibility for making sure it stays fixed after your work (even if that means another patch), but if there's some way I can rebase it off your work that would be fine too.
Re: Issue 3778: Use bounding box as skylines for markup in svg backend (issue 582010043 by barr...@gmail.com)
On Sat, May 02, 2020 at 01:16:30AM -0700, beauleetien...@gmail.com wrote: > On 2020/05/02 07:38:58, hanwenn wrote: > > I don't completely understand, though: if we put the "utf-8-string" > directly > > into the SVG output, the SVG browser might make other font choices, > making the > > outline potentially incorrect. Is this a problem in practice? "utf-8-string" never appeared directly in the svg output and that doesn't change. Typically (without changing options) you would end up with . > There isn't really an "outline" anymore; the bounding box is used. That > is based on the specified font, but if a font were substituted, there > will be slight differences. They wouldn't be too big though and so > wouldn't be a problem. Yes, and to expand on this: - lilypond was *already* falling back on the bounding box for pure utf-8-string stencils - but when a grob mixed utf-8-string stencils with something else (a note for example), it would give the grob a skyline *just* from the note, meaning the text portion of the grob would collide with other grobs - this patch changes the behaviour of stencils that mix utf-8-string and other kinds of stencil to be the same as pure utf-8-string (i.e. fall back to the bounding box). > > https://codereview.appspot.com/582010043/
Re: Issue 3778: Use bounding box as skylines for markup in svg backend (issue 582010043 by barr...@gmail.com)
On Sat, May 02, 2020 at 12:25:15AM -0700, hanw...@gmail.com wrote: > please don't submit; I'm rearranging this file completely. > > Can you add your regression test + instructions on how to reproduce the > problem? I did add a regression test in the first patch set, but it breaks testing. It seems we have no way to include the SVG backend in regression tests (I can see one other example that tries to, using inkscape, but it was disabled in 2008). I had to remove the regression test in the second patchset in order to not break make test/check/etc. Do you have any suggestion about how to deal with it? The issue in the tracker shows how to reproduce the problem - do you want that added to the code somewhere? > > https://codereview.appspot.com/582010043/
Re: [PATCH v1] Issue 3778: Use bounding box as skylines for markup in svg backend
Hi Jonas, > Done (hopefully). Thank you very much; it looks like it worked! Kevin
Re: [PATCH v1] Issue 3778: Use bounding box as skylines for markup in svg backend
Hi James, > We do have a process, see: > http://lilypond.org/doc/v2.19/Documentation/contributor-big-page#summary-for-experienced-developers I have followed this as best I can, but it seems I need to have write access to the issue tracker before I can send patches. If that is the case then can someone please arrange that for me? My username is barrykp. Kevin
Re: [PATCH v1] Issue 3778: Use bounding box as skylines for markup in svg backend
Hi James, Thank you for responding. On Mon, Apr 27, 2020 at 11:09:50AM +0100, James wrote: > Is this patch read for full testing or is it work-in-progress you just want > someone to comment on it? It's not work in progress no - unless someone has objections or observations, but I don't mean to circumvent the review process or anything. If there's a better way to go about this then I'm happy to follow a process. Kevin
Re: [PATCH v1] Issue 3778: Use bounding box as skylines for markup in svg backend
Patch is attached to this mail as a file if that is more convenient.
Kevin
>From 1c5715ad52139aab936ee7dffb2cdef3d123b369 Mon Sep 17 00:00:00 2001
From: Kevin Barry
Date: Fri, 24 Apr 2020 19:26:26 +0100
Subject: [PATCH v1] Issue 3778: Use bounding box as skylines for markup in svg
backend
As there is no routine for determining skylines for utf-8-string
stencils, they normally fall back to the grob's bounding box, which is
fine. However, when there is a mixture of utf-8-string and other types
of stencil (which have associated skyline functions) in a single grob,
the entire grob gets a skyline determined only from the non-utf-8-string
stencils. This sometimes causes the text portion of such mixed grobs
(e.g. metronome marks) to collide with other grobs.
While looping over the stencils, check for utf-8-string and if found,
clear the skylines and break out of the loop. Empty skylines forces a
fallback to the grob's bounding box, which restores the behaviour from
before the patch to improve skyline approximations (issue 2148). This
does not fix the issue that there is no routine for determining skylines
for utf-8-strings when the backend is svg, but it does at least remove
the collisions without changing the behaviour in non-broken situations.
Add a suitable (svg backend) regression test.
---
input/regression/svg-metronome-mark-skylines.ly | 15 +++
lily/stencil-integral.cc| 10 +-
2 files changed, 24 insertions(+), 1 deletion(-)
create mode 100644 input/regression/svg-metronome-mark-skylines.ly
diff --git a/input/regression/svg-metronome-mark-skylines.ly
b/input/regression/svg-metronome-mark-skylines.ly
new file mode 100644
index 00..844e4a8081
--- /dev/null
+++ b/input/regression/svg-metronome-mark-skylines.ly
@@ -0,0 +1,15 @@
+\header {
+texidoc = "In svg output, a @code{MetronomeMark} or any grob mixing text
+and other glyphs does not collide with other grobs.
+"
+}
+
+\version "2.21.1"
+
+#(ly:set-option 'backend 'svg)
+
+{
+ \tempo "Allegro" 4 = 120
+ r1
+ r4 f''' e''' b''
+}
diff --git a/lily/stencil-integral.cc b/lily/stencil-integral.cc
index 7b12eaf17b..8ac386a10e 100644
--- a/lily/stencil-integral.cc
+++ b/lily/stencil-integral.cc
@@ -1097,7 +1097,15 @@ Stencil::skylines_from_stencil (SCM sten, Real pad, SCM
rot, Axis a)
vector boxes;
vector > buildings;
for (SCM s = scm_reverse_x (data, SCM_EOL); scm_is_pair (s); s = scm_cdr (s))
-stencil_dispatcher (boxes, buildings, scm_caar (s), scm_cdar (s));
+{
+ // If any stencils are utf-8-string, fall back on the bounding box
+ if (scm_is_eq (scm_cadar (s), ly_symbol2scm ("utf-8-string")))
+{
+ boxes.clear();
+ break;
+}
+ stencil_dispatcher (boxes, buildings, scm_caar (s), scm_cdar (s));
+}
// we use the bounding box if there are no boxes
// FIXME: Rotation?
--
2.25.3
[PATCH v1] Issue 3778: Use bounding box as skylines for markup in svg backend
As there is no routine for determining skylines for utf-8-string
stencils, they normally fall back to the grob's bounding box, which is
fine. However, when there is a mixture of utf-8-string and other types
of stencil (which have associated skyline functions) in a single grob,
the entire grob gets a skyline determined only from the non-utf-8-string
stencils. This sometimes causes the text portion of such mixed grobs
(e.g. metronome marks) to collide with other grobs.
While looping over the stencils, check for utf-8-string and if found,
clear the skylines and break out of the loop. Empty skylines forces a
fallback to the grob's bounding box, which restores the behaviour from
before the patch to improve skyline approximations (issue 2148). This
does not fix the issue that there is no routine for determining skylines
for utf-8-strings when the backend is svg, but it does at least remove
the collisions without changing the behaviour in non-broken situations.
Add a suitable (svg backend) regression test.
---
input/regression/svg-metronome-mark-skylines.ly | 15 +++
lily/stencil-integral.cc| 10 +-
2 files changed, 24 insertions(+), 1 deletion(-)
create mode 100644 input/regression/svg-metronome-mark-skylines.ly
diff --git a/input/regression/svg-metronome-mark-skylines.ly
b/input/regression/svg-metronome-mark-skylines.ly
new file mode 100644
index 00..844e4a8081
--- /dev/null
+++ b/input/regression/svg-metronome-mark-skylines.ly
@@ -0,0 +1,15 @@
+\header {
+texidoc = "In svg output, a @code{MetronomeMark} or any grob mixing text
+and other glyphs does not collide with other grobs.
+"
+}
+
+\version "2.21.1"
+
+#(ly:set-option 'backend 'svg)
+
+{
+ \tempo "Allegro" 4 = 120
+ r1
+ r4 f''' e''' b''
+}
diff --git a/lily/stencil-integral.cc b/lily/stencil-integral.cc
index 7b12eaf17b..8ac386a10e 100644
--- a/lily/stencil-integral.cc
+++ b/lily/stencil-integral.cc
@@ -1097,7 +1097,15 @@ Stencil::skylines_from_stencil (SCM sten, Real pad, SCM
rot, Axis a)
vector boxes;
vector > buildings;
for (SCM s = scm_reverse_x (data, SCM_EOL); scm_is_pair (s); s = scm_cdr (s))
-stencil_dispatcher (boxes, buildings, scm_caar (s), scm_cdar (s));
+{
+ // If any stencils are utf-8-string, fall back on the bounding box
+ if (scm_is_eq (scm_cadar (s), ly_symbol2scm ("utf-8-string")))
+{
+ boxes.clear();
+ break;
+}
+ stencil_dispatcher (boxes, buildings, scm_caar (s), scm_cdar (s));
+}
// we use the bounding box if there are no boxes
// FIXME: Rotation?
--
2.25.3
Re: [PATCH] Issue 3778: Use bounding box as skylines for markup in svg backend
On Fri, Apr 24, 2020 at 09:25:19PM +0200, Han-Wen Nienhuys wrote: > Just add a test file under input/regression/ , following the style of > other files there. Thanks for the pointer. The only other svg backend file there looks like it has been deliberately disabled, so apologies if I have done this wrong. A revised patch will follow with an added regression test. Kevin
Re: [PATCH] Issue 3778: Use bounding box as skylines for markup in svg backend
On Fri, Apr 24, 2020 at 09:18:10PM +0200, Han-Wen Nienhuys wrote: > Can you add a regression test that shows the problem? Yes. I'll go read the docs to see how to do that and do one up (but feel free to point me in the right direction...) Kevin
[PATCH] Issue 3778: Use bounding box as skylines for markup in svg backend
As there is no routine for determining skylines for utf-8-string
stencils, they normally fall back to the grob's bounding box, which is
fine. However, when there is a mixture of utf-8-string and other types
of stencil (which have associated skyline functions) in a single grob,
the entire grob gets a skyline determined only from the non-utf-8-string
stencils. This sometimes causes the text portion of such mixed grobs
(e.g. metronome marks) to collide with other grobs.
While looping over the stencils, check for utf-8-string and if found,
clear the skylines and break out of the loop. Empty skylines forces a
fallback to the grob's bounding box, which restores the behaviour from
before the patch to improve skyline approximations (issue 2148). This
does not fix the issue that there is no routine for determining skylines
for utf-8-strings when the backend is svg, but it does at least remove
the collisions without changing the behaviour in non-broken situations.
---
lily/stencil-integral.cc | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/lily/stencil-integral.cc b/lily/stencil-integral.cc
index 7b12eaf17b..47179148cd 100644
--- a/lily/stencil-integral.cc
+++ b/lily/stencil-integral.cc
@@ -1097,7 +1097,14 @@ Stencil::skylines_from_stencil (SCM sten, Real pad, SCM
rot, Axis a)
vector boxes;
vector > buildings;
for (SCM s = scm_reverse_x (data, SCM_EOL); scm_is_pair (s); s = scm_cdr (s))
-stencil_dispatcher (boxes, buildings, scm_caar (s), scm_cdar (s));
+{
+ // If any stencils are utf-8-string, fall back on the bounding box
+ if (scm_is_eq (scm_cadar (s), ly_symbol2scm ("utf-8-string"))) {
+ boxes.clear();
+ break;
+ }
+ stencil_dispatcher (boxes, buildings, scm_caar (s), scm_cdar (s));
+}
// we use the bounding box if there are no boxes
// FIXME: Rotation?
--
2.25.3
Re: Resolving standoffs (was: Naming question for get_property, set_property)
Hi David, Although you have changed the subject to "Resolving standoffs" your email reads like an attempt to force a resolution - in your favour - of one *particular* standoff. It seems to be more of a protest than an attempt to elicit discussion. I am both a lurker and not capable of understanding the disagreement between you and Han Wen, so I can't offer an opinion on it. And obviously take my view with a grain of salt, but is it not typical for this development community that, when there is some kind of irreconcilable disagreement, that the proposal just dies? I don't know if it's frequent or not, but I saw it happen with many discussions that arose after the recent in-person meet (they died in standoffs). It seems to be the norm. Is it only a problem now that it is holding up something you are advocating? Kevin
Re: website issue
On Wed, 25 Mar 2020 at 20:06, David Nalesnik wrote: > > I'm getting some spurious characters at > http://lilypond.org/manuals.html. Screenshot attached. looks python2 vs python3 related: b'' is how python3 prints byte strings (which were the default string type in python2, but not in python3).
Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)
> > > The direction of this statement is correct, but the magnitude is not. The > kernel is still provided by the host. Getting a crash report can be > frustrating when the guest's behavior hinges on /proc features that the > host OS has configured appropriately for the host, not the guest. > Configurable security restrictions can make the debugging experience > different from one installation to another. Et cetera. > Yes it's true that containers are not completely safe from host configurations, but I didn't think talking about the 1% would help this discussion. If you think it makes pursuing this idea a waste of time then fair enough. David K doesn't like it either so I think it's time to let it go. >
Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)
> > > I say that having a developer monoculture doesn't buy as anything since > we still need to provide for a multitude of users. > We are talking about testing builds right? If a user gets as far as "I need to test changes I made to the source code" then surely it would be better to have something to point them to than to say "let's see if one of the devs ever ran into the same problem you are having". It also means we could have some confidence when figuring out if a problem is environmental or not. Having some kind of official dockerfile isn't pushing a monoculture: it actually makes it easier for people to run whatever OS they want and not have to keep it in line with LilyPond build requirements. It would make building on Windows or MacOS easier since there are prepackaged docker apps for both. > > Installing docker and building an image is much easier than setting up > > a working build environment for LilyPond now. > > Get a LilyPond source .deb and do sudo apt build-deps on it. Afterwards > you have a working build environment. > That would not work on my system. Making everyone use .deb is another kind of monoculture. > I don't really see the underlying logic. Users should consider it a win > when the developers state "you are no longer allowed to run LilyPond > natively, get a docker container", and you want to convince developers > to stop using and developing LilyPond natively on their systems because > it will be so much easier to maintain a virtual layer in between? > I wouldn't ever suggest that we make running LilyPond require docker. I thought this discussion was about testing builds. > We have had the LilyDev VM for a long time now. It has seen some use, > but not overwhelmingly much, and the reasons for that are pretty much > the same for newer virtualisation methods. > I disagree. The docker image specification could be a simple text file that is kept in the LilyPond repo, and people can build it if they want. Tests could build it and use that image for testing, etc, etc. Kevin >
Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)
> > > Frankly, I am more sympathetic to "worksforme" discussions among > developers than telling users "worksforme". Where is the point in being > able to tell users that no developer will reproduce their problem? > > I'd rather have an error popping up for at least some developers than > for none. > This sounds like you are saying it's better for the situation to be a mess for developers so that they can better help users deal with the same mess, therefore we should leave things as they are. Installing docker and building an image is much easier than setting up a working build environment for LilyPond now. I think it would be a win for both devs and users. Kevin
Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)
On Thu, 12 Mar 2020 at 12:48, wrote: > I'll defer you to Jonas' reply to this thread just after yours. > > I'm all for conistent build envs but at least make sure your testing is > actually ... err testing what it should be testing. > > Containers don't protect against that. A docker container is the same everywhere; the underlying distribution or other differences in people's setups don't make any difference. So if there was an agreed dockerfile that would simplify discussions about 'worksforme'. Jonas's reply referred to native Ubuntu, which misses Han-Wen's point I think. The container provides a consistent and portable environment (providing you have docker installed, it's basically a single text file). If we had some kind of official docker/container image/file for these tests, then if something passes there, but not on someone's personalised distribution then it would be on that person to figure it out (or just use the docker container). And developers would have a single target for testing. Kevin
Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)
> > > Would docker give us this 'proverbial canary' or would it turn into > 'worksforme' when someone tried to build their own version of LP on a > vanilla base of Linux? > Docker would eliminate 'worksforme' type issues yes. >
Re: Staging is broken
"no space left on device"
Is that a full disk or something?
On Sun, Feb 9, 2020, 13:10 wrote:
> Hello,
>
> ..
>
> Making lily/out/metronome-engraver.o < cc
> Making lily/out/warn-scheme.o < cc
> Making lily/out/lexer.o < cc
> Making lily/out/parser.o < cc
> ./out/parser.cc: In function 'int yyparse(Lily_parser*,
> scm_unused_struct**)':
> ./out/parser.cc:2917:12: warning: conversion to 'yytype_int16 {aka short
> int}' from 'int' may alter its value [-Wconversion]
> *yyssp = yystate;
> ^~~
> out/lexer.cc: In member function 'virtual int
> yyFlexLexer::LexerInput(char*, int)':
> out/lexer.cc:6468:21: warning: conversion to 'int' from 'std::streamsize
> {aka long int}' may alter its value [-Wconversion]
> return yyin.gcount();
>~~~^~
> Making lily/out/lilypond
> /usr/bin/ld: final link failed: No space left on device
> collect2: error: ld returned 1 exit status
> /tmp/lilypond-autobuild/stepmake/stepmake/executable-rules.make:12:
> recipe for target 'out/lilypond' failed
> make[1]: *** [out/lilypond] Error 1
> /tmp/lilypond-autobuild/stepmake/stepmake/generic-targets.make:6: recipe
> for target 'all' failed
> make: *** [all] Error 2
>
> --
>
> I pushed a doc change but it doesn't look like that so either it's
> Han-Wen's or Jean-Charle's cherry picks.
>
> James
>
>
>
Re: RFC: docker for CI
On Fri, Feb 07, 2020 at 01:21:35PM +0100, Han-Wen Nienhuys wrote: > Proposal: rather than using the patchy scripts for validating > LilyPond, we use docker images. Without getting into technical details, I think this is a really good idea. Automatic building/testing saves lots of time, and having a containerised build environment means it can be as portable as a single dockerfile (or one for each version of guile, if that is what you were thinking). Kevin P.S. I think I have seen a dockerfile for creating a build environment for LilyPond somewhere. I wonder whether an official docker file would be beneficial in its own right - at least for Linux users, it would decouple the build environment from the OS packages.
Re: [RFC] switch to GitLab / gitlab.com
> (CC to Kevin Barry, who mentioned GitLab experience in a separate > thread. My info here is more based on research than experience, so > please call out any misunderstandings I have.) Thank you for the CC. I have read through the messages, and the previous discussion from 2018. My two cents are: - I think if we want to integrate issue tracking, code review, and source code hosting in one place, then Gitlab is the best option - I do not have the experience of working with SF/Allura, Rietveld, and Savannah to get code into LilyPond, but, judging from appearances, the flow for contributions will be smoother for existing developers and less off-putting for new or occasional developers (I think, outside projects like the Linux kernel, drive-by pull/merge requests are more common than drive- by patches) - I agree that using gitlab.com is better than self-hosting, but depending on the technical challenges involved it may be necessary to host a dedicated Gitlab runner (i.e. a server for doing CI/CD builds/tests). - I think it's possible James Lowe's workflow might be be different under Gitlab. Re the concerns he raised in the old thread, I believe he would be able to mostly replicate what he does now with labels (and sorting by priority label). (I can see that this flow, including the "countdown" is under discussion elsewhere.) - I don't know who tests that every patch successfully builds and passes basic tests, but in my experience, having Gitlab do that for me every time someone opens a merge request (on one of my own projects at work) has been a godsend (before that, I had to do it myself every time). > Additionally I'm not (yet) proposing to use MRs to actually > merge the change, that still happens via staging -> master. I only > propose that we use the UI to review the patches, instead of Rietveld. I think this is a good approach. Gitlab allows, for example, to have a number of protected branches (master + staging), and to default merge requests to any one. You can also set it to do different CI/CD on a branch by branch basis (for example you may want to run more stringent or longer tests on the staging branch than on others).
Re: development process
I don't know if lurkers' opinions count, but on the subject of potential replacements for Savannah/Sourceforge: I am part of a team that administer both Gerrit and Gitlab in-house deployments. If choosing between them I would advocate for Gitlab because it includes issue tracking and CI/CD so perhaps all work can go through one place and contributors/maintainers would not need to have accounts for multiple apps/systems. Gerrit is a good code review tool, but for various reasons that may be our own fault, it is deeply unpopular where I work. I am sadly not quite up to the task of developing the codebase (maybe one day), but I can help with systems/operational things if wanted. (I don't have a view on the bigger discussion about process - the change most likely to help me to contribute would be mentorship rather than any process change).
Re: french beaming incorrectly makes stems longer
On Sat, Jan 25, 2020 at 09:27:07AM +0100, Thomas Morley wrote:
> Am Sa., 25. Jan. 2020 um 08:58 Uhr schrieb Kevin Barry :
> >
> > The minimum length of the stem of the middle note is forcing the beams down.
>
> Not here. It's more the relevant value of
> beamed-extreme-minimum-free-lengths. See:
>
> \relative c'' {
> r16 f d f
> \override Stem.details.beamed-extreme-minimum-free-lengths =
> #'(2.0 0.8) %% original: '(2.0 1.25)
> \override Stem.french-beaming = ##t
> r16 f d f
> }
OK I see. It seems the value is hard coded now, but in the case of
French beaming it would need to be different depending on how many beams
there are (the above code works for semiquavers, but I think the value
needs to be smaller for demisemiquavers).
I am happy to try patching it, but I wouldn't know where to start.
>
> Cheers,
> Harm
Re: french beaming incorrectly makes stems longer
The minimum length of the stem of the middle note is forcing the beams down.
Re: packaging lilypond as a docker container?
On Mon, Jan 20, 2020 at 10:05:23PM +, Carl Sorensen wrote: > > Wouldn't it be much more simple to build lilypond as a Docker application? > > I don't know anything about building lilypond as a Docker application. If it > were possible to execute a docker application from the command line in MacOS, > then I think that would meet my requirements. I need to be able to have > multiple binaries installed so that I can run multiple versions from > Frescobaldi. Running docker on MacOS requires a virtual machine running Linux. The Docker for desktop app for MacOS hides that detail away from the user for the most part. It is technically possible to do what you want (make it so Frescobaldi can call multiple versions of LilyPond) with docker, but there would be some work involved: you'd probably need to have one-liner shell scripts for each version of LilyPond that execute the relevant container.
Re: Stepping down and moving on
Hi David, Just echoing everyone else's sentiments: your contribution to our lives and work through your work on LilyPond is incalculable. As a lurker of course I don't really understand much of what you do, but it's clear that LilyPond would be far behind where it is now without your development and leadership. I am sorry that I was never in a position to help out financially, so I am happy to hear about your new job. I wish you all the best! Kevin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mentoring opportunity: anybody claiming to care about the website
I have some unexpected free time and would like to do this. Should I contact you off list? Kevin On Sun, Jul 19, 2015 at 4:31 PM, Graham Percival gra...@percival-music.ca wrote: Add weight to your opinions by showing that you're not afraid of getting your hands dirty. texi2html is a vital part of the documentation. It's currently used for the website as well, but that is almost incidental to its use for the rest of the documentation. https://code.google.com/p/lilypond/issues/detail?id=1000#c20 https://code.google.com/p/lilypond/issues/detail?id=1000#c21 I cautiously estimate 20 hours of work for the non-translation portion[1]. I am willing to mentor. Programming ability is desirable, but not strictly required. [1] at the present time, I am not willing to look into the translation system in sufficient detail to offer an estimate of how much work it would take. If we complete the English part, and those involved wish to continue, then I promise to also mentor the translation part. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
compiling lilypond on a raspberry pi
Dear All, During a transitional period where I have no computer I have tried compiling the latest stable version of lilypond from source on a raspberry pi to see if I could get it working. (The latest raspbian - still Debian wheezy - is using 2.14.2 which will not work on most of my files.) Everything works ok (configure gives no errors) up until compilation when make fails with the following error: make[1]: *** No rule to make target '../flower/./out/library.a', needed by 'out/lilypond'. Stop. make[1]: Leaving directory '/home/pi/src/lilypond-2.18.2/build/lily' /home/pi/src/lilypond-2.18.2/stepmake/stepmake/toplevel-targets.make:30: recipe for target 'install' failed make: *** [install] Error 2 Can anyone shed any light on this? Is it something I can fix? Kevin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reasons for cross-voice limitations?
For sure the voice context limitations are a pain, and if I knew how, I would write a function for starting and finishing slurs without the need for creating a hidden voice, but I don't even know if it is possible. In my own head, I imagine that LilyPond `thinks' in voices and there isn't much that can be done about that. Practically 100% of my work is either piano music or music reduced to two staves, so I bump up against this issue all the time. I never use the part combiner. I obviously don't know how necessary this limitation is, but iirc the old DOS program SCORE required that the whole score be reentered for the purposes of adding slurs. How hard would it be to write a cross-voice slur function? On Sun, Mar 29, 2015 at 6:49 PM, Urs Liska u...@openlilylib.org wrote: Hi, this has been discussed numerous times, but I think I'll have to bring it up once more: the limitations that slurs, dynamics and other spanners can't cross voice borders. This limitation is a major inconvenience for users: New users are regularly confused, using hidden voices to work around the limitation is actually an ugly workaround, and it's not acceptable to be forced to use such workarounds for reasonably common things. And now I've come to suffer from an issue where this limitation is a real PITA: the partcombiner. I find it quite obscure to tame the partcombiner to do its work anyway (for example, when you're facing an issue you don't have a real way to tell what mode it currently is in because the last switch could have happened about anywhere, and in any of the voices taking part in the combination). But I've come to the conclusion that very often the partcombiner has to make ugly choices because it's bound to keep voice contexts alive during the whole spanners. Often it remains in partcombineApart mode for ridiculously long ranges, just because a slur has to be closed in the same voice as it has begun. And this kind of issue is usually sooo awkward to solve because you might end up inserting a hidden voice to achieve the slurring but have to restrict that to the partcombined staff while not using it for individual part printing etc. So I want to bring that up once more: Why do we still have this limitation? Is it an inherent problem that can't be fixed, is it just because noone cared (or had the chance) to fix it, or is it only because we didn't explicitly think about the right way to deal with it semantically and with regard to syntax? I mean, I can't imagine it makes a serious difference when it comes to *engrave* a slur. It may make a difference for managing and maintaining contexts, but just as it is possible to add a hidden voice to accomplish a cross-voice item it should be possible to create a built-in solution for that. This wouldn't fix the partcombiner limitations, but it would at least make it possible to think about improvements. Any ideas? Urs, frustrated ... ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Disappearing barlines with skipBars - possible bug?
On Tue, Mar 24, 2015 at 2:38 PM, Mark Knoop m...@opus11.net wrote:
{ \time 2/4 c'4 c'1 c'4 } % 3 bars, 2nd of which is empty
{ \time 2/4 c'4 c'2 c'4 } % 2 bars, neither of which is empty
At best I would consider these to be non-standard notation. At worst I'd
say it's incorrect. It's possible to write a note value longer than a bar,
but I don't think there is an accepted standard for notating that, except
for connecting smaller note values with ties. And as I said before I have
never seen it in a score (do you have any examples?).
skipBars is introduced in the Learning Manual (3.4.5 Scores and parts)
as a way of condensing multi-measure rests. Its only references in the
Manuals are regarding this function. I suspect its impact on notes
crossing barlines is either unintended or at least not thought through
It's just used there as an example of a context property. I agree that its
behaviour for notes rather than rests might not be thought through (but it
/is/ mentioned in the IR so it may not be unintended). Normally full-bar
rests are condensed with \compressFullBarRests (which probably just sets
skipBars to #t, but I didn't check).
I can't imagine a situation where the current behaviour would be
desirable (silently hiding a barline thus changing the length of a bar)
and it would certainly seem to be a very different use case than
condensing multi-measure rests.
I think the default behaviour (without touching skipBars) is ok, and agree
that there's no apparent need for it to affect notes (the possible scenario
with long notes and short empty bars seems implausible). So perhaps
skipBars could be changed to only affect rests, or at the very least a
different context property could be used as an example in the learning
manual (or both).
I verified that \compressFullBarRests does indeed affect notes as well, so
if you want to file a bug report then perhaps proceed on that basis.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feedback request: website home page revision
3G looks best to me. K. On Sun, Mar 1, 2015 at 8:22 PM, Joram joram.no...@gmx.de wrote: Hi Paul, Am 01.03.2015 um 20:22 schrieb Paul Morris: Joram Berger wrote all versions have the green background fading in on the top right edge. I do not like that. Hi Joram, Based on previous feedback from Phil and Trevor, I'm taking it as a given that the top left green background with the white image of music notation should stay. The green background in the top right corner is to balance it out, for greater symmetry. I see. I just wrote my comments as feedback to your request. Of course there are differing opinions and of course you are free to choose something else. I've adopted many of your other specific suggestions in the most recent proposals 3F and 3G. Thanks. As you can guess from my previous mail, version 3G is what I prefer. (I consider all versions 3 an improvement.) Cheers, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: issue 1432 (issue 206770044 by barr...@gmail.com)
On Sat, Feb 28, 2015 at 11:17 AM, pkx1...@gmail.com wrote: Barry if you make a git formatted patch, I can push it for you. James I'm still getting used to git, so I hope I've done it right. It should be attached to this email, assuming that's what you wanted. Kevin From 976465f12cb50c74f5ad4e36121758a7597d5e53 Mon Sep 17 00:00:00 2001 From: Kevin Barry barr...@gmail.com Date: Thu, 19 Feb 2015 15:51:52 + Subject: [PATCH] Doc: replaced tabs with spaces in /ly/*.ly --- ly/arabic.ly | 26 +- ly/articulate.ly | 682 +++ ly/chord-modifiers-init.ly | 4 +- ly/chord-repetition-init.ly | 2 +- ly/drumpitch-init.ly | 160 ly/dynamic-scripts-init.ly | 1 - ly/engraver-init.ly | 10 +- ly/event-listener.ly | 26 +- ly/graphviz-init.ly | 8 +- ly/gregorian.ly | 150 +++ ly/init.ly | 4 +- ly/makam.ly | 23 +- ly/midi-init.ly | 1 - ly/music-functions-init.ly | 382 - ly/predefined-guitar-ninth-fretboards.ly | 34 +- ly/property-init.ly | 18 +- ly/satb.ly | 51 ++- ly/scale-definitions-init.ly | 11 +- ly/script-init.ly| 28 +- ly/spanners-init.ly | 18 +- ly/string-tunings-init.ly| 2 +- ly/text-replacements.ly | 6 +- ly/toc-init.ly | 54 +-- 23 files changed, 847 insertions(+), 854 deletions(-) diff --git a/ly/arabic.ly b/ly/arabic.ly index 645b47a..ec637d3 100644 --- a/ly/arabic.ly +++ b/ly/arabic.ly @@ -87,18 +87,18 @@ iraq = #`( \Score keyAlterationOrder = #`( - (6 . ,FLAT) (2 . ,FLAT) (5 . ,FLAT ) (1 . ,FLAT) - (4 . ,FLAT) (0 . ,FLAT) (3 . ,FLAT) - (6 . ,SEMI-FLAT) (2 . ,SEMI-FLAT) (5 . ,SEMI-FLAT ) (1 . ,SEMI-FLAT) - (4 . ,SEMI-FLAT) (0 . ,SEMI-FLAT) (3 . ,SEMI-FLAT) - (3 . ,SHARP) (0 . ,SHARP) (4 . ,SHARP) (1 . ,SHARP) - (5 . ,SHARP) (2 . ,SHARP) (6 . ,SHARP) - (3 . ,SEMI-SHARP) (0 . ,SEMI-SHARP) (4 . ,SEMI-SHARP) (1 . ,SEMI-SHARP) - (5 . ,SEMI-SHARP) (2 . ,SEMI-SHARP) (6 . ,SEMI-SHARP) - (6 . ,DOUBLE-FLAT) (2 . ,DOUBLE-FLAT) (5 . ,DOUBLE-FLAT ) (1 . ,DOUBLE-FLAT) - (4 . ,DOUBLE-FLAT) (0 . ,DOUBLE-FLAT) (3 . ,DOUBLE-FLAT) - (3 . ,DOUBLE-SHARP) (0 . ,DOUBLE-SHARP) (4 . ,DOUBLE-SHARP) (1 . ,DOUBLE-SHARP) - (5 . ,DOUBLE-SHARP) (2 . ,DOUBLE-SHARP) (6 . ,DOUBLE-SHARP) - ) + (6 . ,FLAT) (2 . ,FLAT) (5 . ,FLAT ) (1 . ,FLAT) + (4 . ,FLAT) (0 . ,FLAT) (3 . ,FLAT) + (6 . ,SEMI-FLAT) (2 . ,SEMI-FLAT) (5 . ,SEMI-FLAT ) (1 . ,SEMI-FLAT) + (4 . ,SEMI-FLAT) (0 . ,SEMI-FLAT) (3 . ,SEMI-FLAT) + (3 . ,SHARP) (0 . ,SHARP) (4 . ,SHARP) (1 . ,SHARP) + (5 . ,SHARP) (2 . ,SHARP) (6 . ,SHARP) + (3 . ,SEMI-SHARP) (0 . ,SEMI-SHARP) (4 . ,SEMI-SHARP) (1 . ,SEMI-SHARP) + (5 . ,SEMI-SHARP) (2 . ,SEMI-SHARP) (6 . ,SEMI-SHARP) + (6 . ,DOUBLE-FLAT) (2 . ,DOUBLE-FLAT) (5 . ,DOUBLE-FLAT ) (1 . ,DOUBLE-FLAT) + (4 . ,DOUBLE-FLAT) (0 . ,DOUBLE-FLAT) (3 . ,DOUBLE-FLAT) + (3 . ,DOUBLE-SHARP) (0 . ,DOUBLE-SHARP) (4 . ,DOUBLE-SHARP) (1 . ,DOUBLE-SHARP) + (5 . ,DOUBLE-SHARP) (2 . ,DOUBLE-SHARP) (6 . ,DOUBLE-SHARP) +) } } diff --git a/ly/articulate.ly b/ly/articulate.ly index bbfea19..e2c8700 100644 --- a/ly/articulate.ly +++ b/ly/articulate.ly @@ -32,7 +32,7 @@ %%%USAGE % In the \score section do: % \articulate -% all the rest of the score +% all the rest of the score % % or use the lilywrap script. % @@ -66,8 +66,8 @@ % -- accent needs better control of dynamics. % -- Articulations: mezzo-staccato, portato. % -- Handling of generic ornaments (in lily, `\stopped'; in -% most early music: ornament this note (trill, turn -% or mordent as the player wishes)) +% most early music: ornament this note (trill, turn +% or mordent as the player wishes)) % * Automatic gruppetto at end of trill; better handling of % initial/final grace notes on trill % * Automatic ornaments. @@ -209,8 +209,8 @@ #t) (begin (if (any (lambda (z) (eq? 'NoteEvent (ly:music-property z 'name))) - (ly:music-property lastev 'elements)) - (ly:warning (_ stealing the entirety of a note's time))) +(ly:music-property lastev 'elements)) +(ly:warning (_ stealing the entirety of a note's time))) (set! (ly:music-property lastev 'elements) '()) (set! ac:eventsBackward (cdr ac:eventsBackward)) (ac:stealTimeBackward (- tosteal levlen @@ -236,12 +236,12 @@ % Raise note one step in the current diatonic scale. #(define (ac:up note) (let* ((pitch (ly:music-property
Re: Doc: issue 1432 (issue 206770044 by barr...@gmail.com)
On Sat, Feb 21, 2015 at 5:45 PM, pkx1...@gmail.com wrote: This issue also says it is blocked by https://code.google.com/p/lilypond/issues/detail?id=777 But I am not sure if what Barry has done so far is relevant to this. https://codereview.appspot.com/206770044/ I did first try using the ly-python indent script (which hasn't seen any substantial changes since 2013 judging from the relevant github page), but it did a lot of reformatting, and in one or two situations behaved in a way that I wasn't sure was correct (although emacs's indent-region typically produced the same results). For example, it seems to be the norm to indent the first line after declaring a LilyPond variable, but neither the ly indent script nor emacs will do this unless the line declaring the variable also contains an open bracket of some kind (most do, but some don't). So I just did it manually. Along the way I touched up one or two things (whitespace) but obviously didn't catch everything that could be improved. Should I go ahead and make the changes c_sorensen suggested? I don't mind going through the files looking a bit more closely. The alternative I suppose would be to try and update the ly indent script or ask for it to be changed. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Some more possible tweaks to the appearance of the website
On Fri, Feb 20, 2015 at 5:57 PM, Paul Morris p...@paulwmorris.com wrote: So I look forward to hearing from others on the list! LGTM ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: issue 1432 (issue 206770044 by barr...@gmail.com)
On Thu, Feb 19, 2015 at 4:46 PM, d...@gnu.org wrote: This is not just replacing tabs with spaces. You also reformat here and remove empty lines at the end of the file. So the issue description is somewhat misleading. Any other changes? Yes, sorry. I wasn't really sure how detailed to be. Where I found them I removed trailing whitespaces and extra lines at the end of files. And in one or two places I moved the beginning of a scheme function that is encased in a lilypond variable to a new line to keep line lengths a bit shorter or (as in the case of the drum file you commented on, to keep things more consistent with the other variables in the file). ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Ossias and key signatures
Can someone point to a well engraved example (Bärenreiter, UE, etc.) of a similar ossia staff that shows clef and key signature? My gut feeling is that both clef and key signature should be *before* the barline, not after. Not off the top of my head, but Gould says `When the /ossia/ stave starts mid-system at a barline, most editions do not include an initial barline through the cue stave', so perhaps there's no need for a barline there at all. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
mentorship
Dear Lilypond developers, I read in the contributor's guide that there is a system of mentorship for people who would like to help the project. Is that still the case? And if so how do I get involved in it. Kevin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mentorship
It depends on which part of LilyPond you want to help with as to the availability of people to help you. Is there a particular skill-set, set of issues or area of LilyPond you are particularly interested in? Thank you for responding. I would like to be able to contribute code to the project but I'm not really a programmer (I'm a music academic). I worked through some chapters of SICP in the past, so I have a rudimentary understanding of ... the first few chapters of SICP. I would like to learn more, if that's something that would help. Otherwise I will help any way that might be needed. I don't have any specific goals other than contributing somehow and maybe learning more about programming along the way. Kevin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
