Re: Pedal cautionary after a line break (current status and improvements)

On 6/25/20, Paolo Prete wrote: > The lack of a cautionary pedal on a bracket could be seen as an enhancement > only in a self-referential context, which doesn't make sense to me. A > proper way to proceed is to check what modern professional engravers do > with it, and check as a consequence if Li

Re: [RFC] Use GitLab Milestones

On 6/23/20, Jonas Hahnfeld wrote: > I knew that description and, honestly, that would be a show stopper for > me reporting any issue to a project in 2020. Why? Because mailing lists are a thing of the past in your view? :-) Sending an e-mail to an open mailing list is much more universal and ac

Re: [RFC] Use GitLab Milestones

On 6/22/20, Jonas Hahnfeld wrote: > In short, I'd like to propose that we replace the labels Fixed_x_y_z > with milestones x.y.z and use these to track which issues were fixed > for a particular release. This has the advantage of a) less labels > which makes the drop-downs more usable and b) the p

Re: xdvipdfmx fails with some regtests (“Invalid object”)

On 6/17/20, Valentin Villenave wrote: > `make doc’ has been broken for nearly a week on my system (even with a > clean git clone), with the following error: > > xdvipdfmx:fatal: typecheck: Invalid object type: -1 7 (line 2161) Git bisect actually tells me that xdvipdfmx started misb

Re: xdvipdfmx fails with some regtests (“Invalid object”)

On 6/17/20, Werner LEMBERG wrote: > I suggest upgrading. The current maintainer of xdvipdfmx fixes bugs > in TeXLive directly – however, this doesn't automatically update the > binaries that are in TeXLive's SVN repository. It's not that > complicated to get the TeXLive sources and compile a pri

Re: “make doc” broken because of gs eps->pdf failing

On 6/17/20, Valentin Villenave wrote: > Thanks for giving me hope, even for a minute :-) I spoke too soon; running doc-clean and _then_ “make doc” indeed fixes the problem. (And Jonas has just merged it onto master so that problem is fixed.) Thanks! Cheers, -- V.

Re: “make doc” broken because of gs eps->pdf failing

On 6/17/20, Michael Käppler wrote: > Do you have > https://gitlab.com/lilypond/lilypond/-/merge_requests/148/diffs?commit_id=c002d5e8c2e737cefbafa84f4b66e4b3bbc6d111 > in your repo? Otherwise that may well be the problem. Jonas wanted to > push this one yesterday, > but it seems that did not happe

Re: xdvipdfmx fails with some regtests (“Invalid object”)

On 6/17/20, Werner LEMBERG wrote: > It seems that you probably have to update your TeX system... Update or downgrade? I’m using the latest fc32 repos. Besides, I haven’t changed anything on my OS recently and this started happening only a week or so ago; isn’t it possible that this is triggered

“make doc” broken because of gs eps->pdf failing

Greetings everyone, I’ve noticed a recent regression with `make doc’: when it reaches Documentation/ly-examples, gs fails on a bunch of files with the following error message: Command: /home/work/lilypond/out/bin/lilypond -dpreview -dresolution=150 -o ./out-www sesto-violin.ly Changing working di

xdvipdfmx fails with some regtests (“Invalid object”)

Hey everybody, `make doc’ has been broken for nearly a week on my system (even with a clean git clone), with the following error: Making input/regression/out-www/collated-files.list < 1368 files Making input/regression/out-www/collated-files.texi < tely Making input/regression/out-www/collated-fil

Re: Can you give a sample ETF file? and other questions

On 6/14/20, Jean Abou Samra wrote: > That's how I stumbled on etf2ly. There are no regression tests and I > couldn't find a single ETF file across the Net to see how the script's > output looks like. Can anyone provide one? You can find a bunch of those online, for example here: http://www.igrace

Janus M. Nowacki

Greetings everybody, I just wanted to let you know that Janus Nowacki, one of the founders of the TeX Gyre font suite that is used by default in LilyPond, has recently died: http://www.gust.org.pl/news/jmn-obit-en And his personal website (in Polish): https://jmn.pl/ The TeX Gyre font project was

Re: Texinfo - manual line breaks in URLs?

On 6/6/20, Michael Käppler wrote: > Is there a reason for this inconsistency? How is it supposed to be? Hi, >From what I gather, that’s merely because Werner’s been looking elsewhere for the past 16 years :-) https://git.savannah.gnu.org/cgit/lilypond.git/commit/?id=cae1b39741a43547e3f4add29416f2

Re: new procedure with GitLab CI

On 6/4/20, Jean Abou Samra wrote: > Actually, I had anticipated a long thread full of reactionson bothof the > above options, but not such a silence. Anyone? (I won't feel offended if > you find my proposal dumb!) Well, you have to account for the fatigue :-) I’m not knowledgeable enough to disc

Re: new procedure with GitLab CI

On 5/27/20, Jonas Hahnfeld wrote: > No, "rebase" is currently manual (with "merge when pipeline succeeds" > being automatic). This has been clearly communicated, sorry if you > missed that. Hey Jonas, hey everybody; just so you know, I’m getting increasingly frustrated -- as you may guess if you

Re: GitLab access

On 5/28/20, Aaron Hill wrote: > In some ways, this is akin to a job interview Gosh, I really hope it isn’t!! My apologies if you’ve been seeing it that way. > It is counter-productive for me to use my > time and talents to fill a role that does not need filling. That’s hardly been the way our

Re: new procedure with GitLab CI

On 5/27/20, Valentin Villenave wrote: > On 5/27/20, Jonas Hahnfeld wrote: >> We do want to have the pipeline on the commit before it is merged >> because this replaces patchy. > > Well, that’s absolutely crucial at the MR review stage. But after passing [sorry, I forgot

Re: new procedure with GitLab CI

On 5/27/20, Jonas Hahnfeld wrote: > We do want to have the pipeline on the commit before it is merged > because this replaces patchy. Well, that’s absolutely crucial at the MR review stage. But after passing > The only limitation is that all MRs are > checked individually. Not only individually

Re: new procedure with GitLab CI

On 5/27/20, Jonas Hahnfeld wrote: > Pinging this to attention... Yeah, that’s one of those “I’ve read it without fully understanding it” situations (and then the discussion devolved into James’s workflow and I lost track). So IIUC there’s no way to skip the rebase-triggered CI pipeline right now

Re: remove merged branches & branches with tags

On 5/26/20, Jonas Hahnfeld wrote: > Is this OK with everyone? Fine by me. -- V.

Re: GitLab permissions

On 5/24/20, Jean Abou Samra wrote: > Since I'm trying to work on MusicXML, it would be nice if I could add > the corresponding label to the appropriate issues, and perhaps > self-assign a few of them. Also, there are some old issues that look > fixed but are still open, so I'd like to close those.

Re: helping with testing resources

On 5/23/20, Jonas Hahnfeld wrote: > If you have spare hardware and / or want to help with CI testing, this > is easy to setup with GitLab. First you'll need their runner and I'll > defer to the excellent documentation: https://docs.gitlab.com/runner/ > As testing uses Docker, those sections also a

Re: Markup vertical alignment

On 5/21/20, James wrote: > A bit like this (still open) issue? > https://sourceforge.net/p/testlilyissues/issues/1322/ > ;) Uh, that’s precisely one I’m trying to close… :-) https://gitlab.com/lilypond/lilypond/-/merge_requests/59 > Mind you I was sure there was some discussion in dev-lilypond a

Re: Markup vertical alignment

On 5/20/20, Phil Holmes wrote: > The same is true of the next section on horizontal and vertical alignment. Yes, I tried to rewrite a few things in there. Could you have a look and tell me if that makes thing less confusing in your opinion? On 5/20/20, David Kastrup wrote: > \hspace and \vspace

Re: Markup vertical alignment

On 5/20/20, Phil Holmes wrote: > Could someone oblige? Happy to: https://gitlab.com/lilypond/lilypond/-/merge_requests/67 I also took the opportunity of addressing a comment I left when writing NR 1.8 more than a dozen years ago, about \hspace and \vspace (the latter of which was not even offici

Re: LilyPond GSoC logistics

On 5/20/20, Arthur Reutenauer wrote: > “How often would you like me to make contact?” :-) > https://www.lexico.com/definition/touch_base I urge you not to look up that phrase on Urban Dictionary… ;-) Cheers, -- V.

Re: Final resolution of issue 4751

On 5/16/20, David Kastrup wrote: > I don't really have a good idea here. Looks like quite a mess. I’ve re-categorized it as Status::Started, and removed the Fixed_2_19_44 label for now. I‘ve also linked it with issue #4781 since it seems there’s quite a bit of overlap. Jean, since you wanted t

Re: 2.21.0 Issues all verified!

On 5/16/20, Carl Sorensen wrote: > Thanks to all who have helped us get > back to a more regular release schedule! Well, thanks to you! And to everybody who gave a hand (Federico, Karlin, and a few others?). For a little while I was reminded of the Google tracker era, and of all the great work

Re: Another round of questions

On 5/16/20, Werner LEMBERG wrote: > IMHO only bugfixes should be applied to `musicxml2ly` since `xml2ly` > covers much more of MusixXML (and will, AFAIK, also eventually support > its successor, MNX). Huh. xml2ly has very different requirements than musicxml2ly and is (AFAICS) unlikely to ever b

Re: mirror GitLab -> Savannah

On 5/14/20, Jonas Hahnfeld wrote: > To keep this short: I'd like to enable push mirroring from GitLab to > Savannah for the following branches [1]: > - master > - release/unstable > - stable/* > - translation* Why not staging? (Assuming that’s still gonna be a thing in months to come.) By th

Re: labels on GitLab

On 5/12/20, James wrote: > It was't blind Valentin, He did explain why he reverted it. > Be fair. *Cough* If the point is to facilitate merge requests, I certainly can understand why Patch::* labels need to be at the top of the list; then again, rearranging them is easy enough without “reverting”

Re: labels on GitLab

On 5/12/20, Jonas Hahnfeld wrote: > I'd really hope we can discuss things before changing... And *I*’d really hope “discuss things” can amount to more than “blindly reverting everything and anything that’s been done by someone else”. Look, you’ve obviously spent quite some time setting this up a

Re: labels on GitLab

On 5/12/20, Jonas Hahnfeld wrote: > In my opinion, there are currently far too many labels on GitLab. Well, we used to say `Labels are cheap’ back when we were using Google Code… > please do not create new labels out of thin air for now. Not entirely out of thin air. I’ve actually decreased the

How are dynamics (self-)aligned exactly?

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: diff --git a/lil

Re: migrating to GitLab

On 5/8/20, Jonas Hahnfeld wrote: > I haven't heard further objections which, for me, means we are going > with GitLab. If you don't agree, now's your final time to speak up. Thanks for tackling this! > 3) The idea is to have the "main" repository at GitLab, next to the > issues and merge request

Re: Use GhostScript API instead of forking (issue 548030043 by jonas.hahnf...@gmail.com)

On 5/6/20, jonas.hahnf...@gmail.com wrote: > In case you're interested how I found out about this: > https://www.hahnjo.de/blog/2020/05/06/recursively-timeing-processes.html Good to know, thanks! (And the resulting improvement is indeed impressive.) Cheers, -- V.

Re: GSoC for LilyPond

On 5/5/20, Owen Lamb wrote: > This is all new for me, so I > appreciate your willingness to help me with newbie questions! I'll probably > have quite a few, especially regarding compiling. As it happens, we do have a “newbie-oriented” document here (which includes a section about compiling), so d

Re: GSoC for LilyPond

On 5/5/20, Werner LEMBERG wrote: > While you have > me as a personal mentor … And a great mentor at that! > it is rather the collective wisdom of this > list that will guide you through your work. +1. There are _lots_ of absolutely brilliant people here. > We don't have an IRC channel, sorry.

Re: Add a script for running timing benchmarks (issue 545950043 by hanw...@gmail.com)

On 4/26/20, hanw...@gmail.com wrote: > I can host this script somewhere else so it can be referenced in the CG, > but I don't think there optimizing our C++ code is a domain for > beginners. I may be off the mark here, but what about adding your speed test into the standard regression test suite

Re: Make doc currently broken

On 4/23/20, Federico Bruni wrote: > I confirm it's a stale dependency file. > I had the same problem while testing my patch before pushing and IIRC > removing Documentation/it/out-www/web.texi fixed it. OK, thanks! I should have thought about doc-clean. Cheers, - V.

Re: Verifying fixes?

On Thursday, April 23, 2020, Carl Sorensen wrote:. > > Do you believe we should Verify the fixes, or should we just leave the > issues closed without verification? I'm willing to spend some time doing > the verification, if we think it's valuable to do so. > I'm available to help with that as we

Make doc currently broken

Hey everybody, For the past few days, I’ve been unable to make doc because of the following error: *** No rule to make target '/home/work/lilypond/Documentation/it/web/news-headlines.itexi', needed by 'out-www/web.texi'. Stop. Federico, do you know anything about it? Cheers, V.

Re: Issue #1204: Document, and add regtest for, external fonts. (issue 557640051 by v.villen...@gmail.com)

On 4/19/20, David Kastrup wrote: > However, there are a few > other problems with that regtest that should likely show with Guile-2 > (sometimes?). Could you elaborate as to what I need to watch out for? I’ve tested it successfully with Guile 2.2 here (but history has teached us that unforeseen s

Re: Issue #1204: Document, and add regtest for, external fonts. (issue 557640051 by v.villen...@gmail.com)

On 4/19/20, David Kastrup wrote: > At that day I was having one patchy run after the other and I did go > through the log files to indicate the failed file and the error message. Yep, and I asked for additional info both on the tracker and on Rietveld; the only reply I did get was from James who

Re: Patchy email

On 4/19/20, David Kastrup wrote: > mkstemp! does not generate a string. It overwrites an existing string > in-place, and that's bad news for a literal string. Yes, it overwrite the string, opens a port, then I read the port-filename which should be an _other_ string object, shouldn’t it? (sigh -

Re: Patchy email

On 4/19/20, David Kastrup wrote: > So I am afraid that things are rather weird at my side: > -rw-r--r-- 1 dak dak 36 Apr 19 19:51 .uuid > dak@lola:/usr/local/tmp/lilypond2$ cat dummyfont-C5PUYM-dir/.uuid > 35d52a4b-44f7-41b6-afca-165a4187aa4f WTF. Could it be some trace left due to your filesy

Re: Patchy email

On 4/19/20, David Kastrup wrote: > You need (mkstemp! (string-copy "... > because mkstemp! overrides the string. Why, yes. What I want to copy is precisely the mkstemp-generated string. What did I miss? V.

Re: Rendering chords in "Danish" style

On 4/19/20, Michael Bisgaard Olesen wrote: > *(Resending because it didn't seem to go through the first time)* Greetings, if you’re subscribed to the -devel list, your messages should go through immediately. Perhaps your first message got stuck because your address was not subscribed yet and as s

Re: Patchy email

On 4/19/20, David Kastrup wrote: > Note that the delete-file instructions are executed while the book is > being read in while markup is typeset when the books are being processed > at the end of the input file. Yes, it looked completely bonkers to me as well, until I realized it worked :-) > No

Re: Patchy email

On 4/19/20, David Kastrup wrote: > ERROR: In procedure mkstemp!: > string is read-only: "kaka-XX" Could the following help? diff --git a/input/regression/font-name-add-files.ly b/input/regression/font-name-add-files.ly index 33f73f0c68..264e2b6532 100644 --- a/input/regression/font-name-add

Re: Issue #1204: Document, and add regtest for, external fonts. (issue 557640051 by v.villen...@gmail.com)

On 4/19/20, David Kastrup wrote: > v.villen...@gmail.com writes: > Breaks my patchy again. Whose patchy was comfortable moving it from > staging to master? Well, at any rate James’ patchy what fine with it. (As it went through the review/countdown process not just once but twice.) The regtest a

Re: GS version conflict in packaged 2.20 and 2.21

On 4/17/20, Simon Albrecht wrote: > it appears from this exchange > > that the packaged versions of 2.20.0 and 2.21.0 contain a mixture of GS > 9.21 and 9.26. Yes, a French user also had some gs issues that I think may be re

Re: ly:page-turn-breaking core dumps

On 4/17/20, Pierre-Luc Gauthier wrote: > Sorry for necro-following-through so late in the issue. If I may chime in, since it may appear from your name that you speak French, do feel free to subscribe to our French-speaking mailing list, where other contributors can help you investigate such quest

Re: Annoying 'langdefs.py' warning

On 4/16/20, Werner LEMBERG wrote: > Building lilypond you get a bunch of harmless but annoying > langdefs.py: warning: lilypond-doc gettext domain not found. > and > .../podir-targets.make:14: warning: ignoring old recipe for target > 'po-update' > messages. Is there a way to suppress them?

Re: 2.21.0 released

On 4/9/20, Carl Sorensen wrote: > Thank you so much for your dedication! Ditto; Phil, you and James may both have the most thankless and yet crucial jobs in the LilyPond community, so praises to you both! (And obviously to Jonas, David, Han-Wen & al.). Here’s to hoping we can get back on track w

Re: Search box searches in 2.19

On 4/7/20, Francisco Vila wrote: > Search box on front page, shouldn't it look in 2.20 by default? Well, 2.20 docs haven’t been indexed yet (I’ve spent quite a few minutes trying to get some search engines to pay us a visit, but I guess the robots’ll drop by whenever they feel like it). So, that

Re: Problem with LSR import

On 4/5/20, David Kastrup wrote: > Valentin Villenave writes: >> It should be available in the next LSR database dump (but there’s at >> least one file in the Japanese version that depends on it, so the name >> will need to be updated there as well). > > Thanks! Davi

Re: Problem with LSR import

On 4/5/20, David Kastrup wrote: > So perhaps changing the name of that snippet > in the LSR would be a good idea. Hi, I just changed it to customized-drum-notation-in-printed-and-MIDI-output.ly (and I reworded the doc string to make it match a bit more with our guidelines). It should be availabl

Re: output-distance: write HTML as UTF-8 (issue 563810043 by hanw...@gmail.com)

On 4/4/20, jonas.hahnf...@gmail.com wrote: > The reason is that the latest commit in master has a non-ASCII > character in the first line of its commit message [1]. So IIUC it *was* f5f907599ce88d3d610483fa42fa78be12f53d2e in the end… but just because of a char in the commit message!? Man, how f

Re: Cannot make check from current master (with no patches applied)

On 4/3/20, David Kastrup wrote: > Anybody have an idea whose Patchy pushed the following: > commit f5f907599ce88d3d610483fa42fa78be12f53d2e Uh, I did push it onto staging after the usual review process. Could that really be what broke some stuff? It’s a fairly simple documentation edit… (Unlik

Re: Add dynamic-interface to keepAliveInterfaces (issue 553760043 by j...@abou-samra.fr)

On 3/31/20, j...@abou-samra.fr wrote: > I'll take a look at it, and try to write appropriate documentation (or > find the authors and ask them to document it!). Setting the issue to > needs_work. I believe it was added by Joe Neeman in order to fix issue #442: https://sourceforge.net/p/testlilyis

Re: Add dynamic-interface to keepAliveInterfaces (issue 553760043 by j...@abou-samra.fr)

On 3/31/20, j...@abou-samra.fr wrote: > By the way, why do we say \RemoveEmptyStaves instead of > \removeEmptyStaves? Because it’s a context property that you need to set for your whole context (it’s actually a \with block), not on-the-fly like \cadenzaOn; see also \RemoveEmptyStaffContext, which

Re: Anything missing for 2.21.0?

On 3/29/20, Dan Eble wrote: >str = re.sub (r"\\(compress|expand)FullBarRests)", r"\\\1EmptyMeasures", That’s on me; sorry about that. https://codereview.appspot.com/553750044/diff/561590043/python/convertrules.py I was convinced it had successfully gone through the docs and regtests, which is

An exciting new release… of Sibelius!!!

Hi everybody, I know it’s off-topic but I wanted to share the news because, let’s be honest, nobody in their right mind would want to miss it: Yes! It’s finally here! The latest and brightest version of Sibelius is out… *And* it offers one particularly exciting, exclusive new feature: https://is

Re: Patch on dynamics and \RemoveEmptyStaves

On 3/26/20, James Lowe wrote: > Yes David K is correct. If someone could take a look at the scripts in > git-cl and get them working smoothly again (there are other errors > reported on this list about git-cl) it would be a boon to the dev team. By the way (this is not directly related but may or

Re: Patchy email

On 3/25/20, Werner LEMBERG wrote: > Oops, I gave wrong advice, sorry. You’re not the one to blame; I was the one who jumped the gun. > Please do > s/@example/@samp/ > and re-commit. Done. Aand this is why we have a patch reviewing process. Lesson learned. (Again.) V.

Re: Patch on dynamics and \RemoveEmptyStaves

On 3/24/20, Jean Abou Samra wrote: > I have the attached very simple patch for LilyPond. Could anyone please > guide me through the process for patch submission? Hi Jean, some step-by-step instructions are available here: http://lilypond.org/doc/latest/Documentation/contributor/quick-start.html

Re: [LSR 2.20] what to do with #280

On 3/14/20, Thomas Morley wrote: > Currently > "Engravers one-by-one" > http://lsr.di.unimi.it/LSR/Item?id=280 > returns several times: > programming error: script direction not yet known > What to do? Would it be a good idea to add \override Script.direction = #UP in the definition of MyVoice?

Re: Doc: organize changes.tely

On 3/9/20, David Kastrup wrote: > I think I was told to run the update script and forgot. I am not sure > where to run it now in order to get the results somewhere. Oh, good. Perhaps we should mention it in the CG’s release-work.itexi to make it less easy for people to overlook in the future? I

Re: Doc: organize changes.tely

On 3/8/20, Francisco Vila wrote: > Yes please, it was painful to re-organize a half-translated version. Now > is soon enough, still. By the way (on a more-than-slightly unrelated note), how up-to-date is the official translation status page? http://lilypond.org/translated.html I’m a bit uncomfort

Re: PATCHES - Countdown for April 6th

On 4/6/19, James wrote: > Here is the current patch countdown list. Greetings James, I suspect this (fairly minor) one has gone unnoticed: https://sourceforge.net/p/testlilyissues/issues/5504/ It has already received a LGTM from two (in)valuable contributors, but could you put it in the countdow

Re: gs version error in latest GUB build

On 4/3/19, Knut Petersen wrote: > An strace log that shows argv and env of execve gs would be helpfull ... Here’s a full strace log from that user, I’m not sure how to find that specific information: http://lilypond-french-users.1298960.n2.nabble.com/file/t249946/lily_strace.txt Cheers, V.

Re: gs version error in latest GUB build

On 4/2/19, Federico Bruni wrote: > As far as I can see from my installations, gs distributed in > lilypond.org recent installers is version 9.26. Nope: $ wget http://lilypond.org/download/binaries/linux-64/lilypond-2.19.83-1.linux-64.sh $ sh lilypond-2.19.83-1.linux-64.sh --tarball $ tar -tjvf

Re: gs version error in latest GUB build

On 3/31/19, Valentin Villenave wrote: > I couldn’t reproduce (but then again I’m not running Ubuntu). I also > find it odd that only some scores are reported to fail while other’s > aren’t. OK, as I suspected *all* scores do indeed fail for this user. Further information just in case:

gs version error in latest GUB build

Greetings, someone on -user-fr has reported gs crashing on some scores (for example the first incipit example from NR 2.9.6), with the following error: gs: Interpreter revision (926) does not match gs_init.ps revision (921). This looks very much like something we’ve seen recently: https://lists.

Re: Anchor points of Slurs / Phrasing slurs

On 3/16/19, Valentin Petzel wrote: > Currently the anchor points are set both over or both under the starting / > ending note, depending on the slur’s direction. For the S-shape we would > need > the control points to differ in directions, so one point above and one point > beneath the respective

Re: Syntax: numbers prefixed with # or not

On 2/21/19, David Kastrup wrote: > baba = -.4 Indeed. That’s probably rare enough that we could get away with a @knownissues in the right place(s), though… Right now, the new ability to have #-less numbers (and strings, although my recent patch changes that) isn’t documented anywhere but the git

Syntax: numbers prefixed with # or not

Greetings, Alongside issue #5473, I’ve started investigating whether numbers still require to be prefixed with #. AFAICS, the only ones that still do are in markups and all markups commands, but hardly anywhere else; which _could_ make LilyPond syntax a tiny bit easier to grasp for new users… Or w

Re: Please test new lilypond installers

On 2/6/19, Karlin High wrote: > I got the LilyPond app extracted from .tar.bz and it opens and runs. Greetings Knut, I’ve received reports from two FreeBSD users that the x86_64 installer doesn’t work. - One said that the binary isn’t recognized as an "amd64" arch (he’s using FreeBSD 12.0 on a c

Re: New feature: automatically invert chords or drop/rise chord notes (issue 365840043 by v.villen...@gmail.com)

On 2/3/19, Lukas-Fabian Moser wrote: > This statement surprises me. I always thought of 'drop n' (with 'drop 2' > being the most common one) as a means to transform closed-harmony > _upper_ voices into open harmony _upper_ voices, without changing the > bass at all. I see what you mean (and I did

Re: New feature: automatically invert chords or drop/rise chord notes (issue 365840043 by v.villen...@gmail.com)

On 2/2/19, Dan Eble wrote: > Isn’t the salient property of an inversion simply which note is lowest in > pitch? (It has been a long time since I studied music theory.) If so, both > of those fit, as does the chord resulting from lowering the e' by an octave. David was more specifically referrin

Re: guilev1/2 musing

On 1/25/19, Thomas Morley wrote: > how exactly is your guile-2-setup, simply checkout the > 'guile-v2-work'-branch, rebase and compile? Oh, I wasn’t even keeping track of this branch (isn’t it dormant, much like Patrick’s previous work on Guilev2?); I’m just using master with --enable-guile2, whi

Re: guilev1/2 musing

On 1/25/19, Thomas Morley wrote: > Over the years some people worked on the topic - speaking only for > myself, I think all low hanging fruits are done. Indeed. Lily-guile2 actually works pretty well (if you don’t mind the noticeable performance hit); I think I’ve been using it nearly-daily for m

Re: guilev1/2 musing

On 1/24/19, David Kastrup wrote: > Development happens on Guile2, none on Guile1. That’s what I’m worried about: if we *were* to include guile1 as a git submodule (effectively forking it, although I don’t imagine many Lily devs are gonna be fiddling with its codebase), what are the sustainability

Re: I cannot run make check since Issue 5450: relocate.cc: Introduce new command `set?'

On 1/24/19, David Kastrup wrote: > texi2html(?) does have specific version requirements Yes, I meant texi2html! We’re in a bind similar to that of Guile: the old unmaintained version works and not the new one. (Well, minus the outrageous let’s-drop-non-ASCII-strings-support-because-frankly-who-ne

Re: I cannot run make check since Issue 5450: relocate.cc: Introduce new command `set?'

On 1/24/19, Knut Petersen wrote: > There's the possibility to uses git submodules ... guile, ghostscript and > extractpdfmark are primary candidates. Not to mention the specific Texinfo version we rely on. V. ___ lilypond-devel mailing list lilypond-d

Re: Two people try to get lilypond for 2.0.12, but hit a roadblock

On Fri, May 13, 2016 at 10:09 PM, David Kastrup wrote: > Not really as material for a public discussion. Greetings to you both, Well, I for one am quite happy to see that Jan’s still around (even though you guys have every reason to feel tired)... Schikkers-List was an awesome idea (it still is)

Re: New context modifier \CompletionRhythms?

On Sat, Apr 9, 2016 at 11:37 PM, David Kastrup wrote: > Why would you even split note values across bars in "ancient music"? At the risk of being blunt: more generally, is there a legitimate use case for completion heads? It never occurred to me that some people (like Simon, it seems) might rely

Re: grob.cc segfaults (with GCC6?)

On 3/25/16, Valentin Villenave wrote: > I’m having a weird segfault on several regtests Greetings, I’ve added it as https://sourceforge.net/p/testlilyissues/issues/4814/ (I can use GUB releases for now and Fedora 24 is not even tagged as alpha, so there’s no emergency. Still -- I’m out of

grob.cc segfaults (with GCC6?)

Greetings everybody, I’m having a weird segfault on several regtests (and most of my own ly files, which is annoying): Parsing... Interpreting music... Preprocessing graphical objects... Program received signal SIGSEGV, Segmentation fault. 0x00496c2f in Grob::get_offset (this=this@entry=0x

Re: Unable to use git-cl

On Mon, Mar 7, 2016 at 3:21 AM, Carl Sorensen wrote: > It appears that my ssl certificate is not working properly. Greetings Carl, have you by any chance disabled JavaScript in your Web browser? (I was unable to post anything until I complied with SourceForge demanding to execute non-free JavaScr

Re: Lose the tagline (permanently)

On Fri, Mar 4, 2016 at 11:20 PM, tisimst wrote: > Engraved with LilyPond X.Y---lilypond.org Well, it’s still language-dependent. What about David’s earlier proposal, enclosed with small notes? Too cheesy? (I quite liked it, but maybe it’s just embarrassingly telling about my own lack of taste mor

Re: Define French as a separate input language (issue 288290043 by v.villen...@gmail.com)

On Mon, Feb 29, 2016 at 12:32 AM, David Kastrup wrote: > Seriously? I mean, no German would think about leaving off umlauts from > a letter under any circumstance Well, in German it can alter the meaning (or at least distinguish between plural and singular). In French it’s a bit rarer. (Although

Re: Define French as a separate input language (issue 288290043 by v.villen...@gmail.com)

On Sun, Feb 28, 2016 at 11:07 PM, David Kastrup wrote: > I haven't seen a single reason why anyone would be wanting to use > "francais" for specifying a notename language that calls d "ré". I’m fairly certain that it wouldn’t be used, ever. (Voluntarily, that is.) So this is a point I can grant y

Re: Lose the tagline (permanently)

On Tue, Feb 23, 2016 at 8:00 PM, Noeck wrote: > What is the tiny symbol in front of the url? A time signature but why? Looks like a hack/pun around the © glyph. I like it. (Reminds me of http://artlibre.org/wp-content/copyleft2.jpg) I may be nitpicking here, but is there a reason why we should k

Re: Define French as a separate input language (issue 288290043 by v.villen...@gmail.com)

On Mon, Feb 22, 2016 at 11:53 PM, Noeck wrote: > if you allow non-ascii letters in the note names (namely é in ré), why > not go all the way and call the language "français" instead of > "francais" (or at least in addition)? Greetings Joram, that’s exactly what this patch does :-) The reason for

Re: Allura account

On Tue, Feb 16, 2016 at 2:42 PM, Trevor Daniels wrote: > I see you're already registered as a Developer on Allura. Maybe Phil just > beat me to it. Greetings Trevor, could you add me as well? (On the off chance I’m able to contribute a bit more to LilyPond in weeks to come...) My SF usename is

Re: Add French-specific note names (issue 239930043 byv.villen...@gmail.com)

On Tue, May 19, 2015 at 11:12 PM, Trevor Daniels wrote: > on my laptop I have to hold down the Alt key and the Fn key, and > type JOU, which is actually 164 with the Fn key pressed. That’s because, for some unexplainable reason, you’re still a proud Windows user :-) On a standard GNU Linux englis

Re: Add French-specific note names (issue 239930043 by v.villen...@gmail.com)

On Mon, May 18, 2015 at 9:52 PM, David Kastrup wrote: > We are recommending "español" over "espanol"? Says who? Sorry. I should have said: we’re _likely_ to recommend "español" over "espanol" in the future, now that the syntax allows it. You said yourself that people had been getting annoyed at

Re: Add French-specific note names (issue 239930043 by v.villen...@gmail.com)

On Mon, May 18, 2015 at 9:20 PM, Francisco Vila wrote: > Besides, this is the status for Spanish users: 'ñ' is a non-shift-needing > key in a very prominent place. On the contrary, the very lilypondish '{}[]\' > set are all hidden under AltGr. Likewise here. > I don't oppose but the alias is che

  1   2   3   4   5   6   7   8   9   10   >