Re: musicxml2ly: import chordnames attached to empty measures or whole rests?
Le 11/10/2021 à 22:37, leonardlthomp...@gmail.com a écrit : Hello! It seems that musicxml2ly won't create a chordname if the corresponding harmony element in the musicxml file is attached to an empty whole rest measure. Works just fine with a chord symbol attached to a single quarter rest, for example, even in a measure of only quarter rests. Would a simple modification to the musicxml2ly python file fix this? I've modified other things successfully in that file so I don't mind trying on my own if anyone has a hint. Attached are the two different cases I've mentioned. Thanks very much. Leonard Thanks for your report. This is now https://gitlab.com/lilypond/lilypond/-/issues/6195 Note that xml2ly (living at https://github.com/jacques-menu/musicformats) converts your example just fine. Best regards, Jean
Re: musicxml2ly: import chordnames attached to empty measures or whole rests?
Much appreciated! On Wed, Oct 13, 2021 at 12:41 PM Jean Abou Samra wrote: > Le 11/10/2021 à 22:37, leonardlthomp...@gmail.com a écrit : > > Hello! > > It seems that musicxml2ly won't create a chordname if the corresponding > > harmony element in the musicxml file is attached to an empty whole rest > > measure. Works just fine with a chord symbol attached to a single quarter > > rest, for example, even in a measure of only quarter rests. Would a > simple > > modification to the musicxml2ly python file fix this? I've modified other > > things successfully in that file so I don't mind trying on my own if > anyone > > has a hint. Attached are the two different cases I've mentioned. > > Thanks very much. > > Leonard > > Thanks for your report. This is now > > https://gitlab.com/lilypond/lilypond/-/issues/6195 > > Note that xml2ly (living at https://github.com/jacques-menu/musicformats) > converts your example just fine. > > Best regards, > Jean >
What is the point of bug-lilypond?
Hi, After having opened a few GitLab issues in response to bug reports on bug-lilypond, I find James extraordinarily patient for having done this over the years. However, I don't get the value in this system compared to letting people creating issues on GitLab directly. When we transfer an issue to GitLab, it's usually just pasting the text from the email report. Right now, bug reports often take a week to be acknowledged, and some of them are not acknowledged by us at all. Take https://lists.gnu.org/archive/html/lilypond-user-fr/2021-01/msg00014.html reported 9 months ago, which I just added to the tracker. Ignoring a report is my opinion the worst of all outcomes since it not only loses information but discourages people to engage in later reports or further investigation. The information for maintainers of GNU software agree with me: https://www.gnu.org/prep/maintain/maintain.html#Replying-to-Mail When you receive bug reports, keep in mind that bug reports are crucial for your work. If you don’t know about problems, you cannot fix them. So always thank each person who sends a bug report. In spite of us not advertising this as a way to report problems, a number of users have been creating issues on GitLab themselves, likely because that has become enough of a standard in other places. When replies are made on bug-lilypond, someone has to paste them on the ticket as well, for completeness, which leads to an awkward split where one does not know where the discussion is supposed to happen or whether the other person has read a remark on the other channel. So how about retiring bug-lilypond and directing to GitLab instead? Tickets can be triaged there, closing invalid ones, adding a minimal example if not present, perhaps changing the title. The requirement from the same page of GNU guidelines, If you would like to use an email-based bug tracking system, see https://bugs.gnu.org; this can be connected with the regular bug-reporting address. Alternatively, if you would like to use a web-based bug tracking system, Savannah supports this (see Old Versions), but please don’t fail to accept bugs by regular email as well—we don’t want to put up unnecessary barriers against users submitting reports. can be fulfilled by simply keeping to accept bug reports on lilypond-devel, which are expected to be rare. Thoughts? Regards, Jean
SMuFL Name mapping update, 13 October: Accordionist input needed
Hi all, Just got the next batch of glyphs in: https://wolfgangsta.github.io/emmentaler-bravura/. That completes the mapping of Feta to SMuFL (bar the still-contentious mappings). Parmesan's ancient notation glyphs are all that's left now! There's just one questionable glyph matchup: accordion.oldEE, an apparently obscure or obsolete accordion register glyph . If you've ever dealt with accordion notation before, let me know if you've seen it attested in literature before, and, if so, what it means. As usual, if you notice any other mistakes or typos, or if you have another 2 cents to offer regarding what I've previously mapped, let me know! Owen Lamb
Re: What is the point of bug-lilypond?
Hello, My own thoughts on this. On 14/10/2021 01:31, Jean Abou Samra wrote: Hi, After having opened a few GitLab issues in response to bug reports on bug-lilypond, I find James extraordinarily patient for having done this over the years. However, I don't get the value in this system compared to letting people creating issues on GitLab directly. When we transfer an issue to GitLab, it's usually just pasting the text from the email report. No it is more than that. It is parsing said bug report - is the thing you are reporting valid? Is it just something a user needs to ask on a different list (e.g. the user is expecting X and is getting Y because they don't understand something but LP is working correctly), is it actually working as designed where the design is not broken but just a hard problem to solve and so on. My day job involves having to tell end-users over and over that X is actually correct because 'reasons' and, at the same time, trying to understand why users think X is a bug when it is not (perhaps improved documentation is all that is needed). So perhaps I am good at this because I have had 20+ years of having to explain this kind of thing to non-technical (or mostly non-interested) people. Sometimes emails to the bug take the form of 'I do X is this expected or is this a bug' which again requires a slightly different tack. I would say that 'most' emails to the bug list do NOT need an issue, they are either replies to emails or pointers to existing Issues that explain bug or technical discussions about why something is not a bug but a limitation of what is possible based on how we code things (which itself engenders more emails). Right now, bug reports often take a week to be acknowledged, Maybe but what's the rush? It's not like we have KPIs or Sprints to complete or other arcane methodologies to acknowledge to release LP. The information is there, it isn't going anywhere, if someone fees THAT strongly about wanting conformation (or usually affirmation) then they will just reply to their own emails and someone will look, and some of them are not acknowledged by us at all. Take https://lists.gnu.org/archive/html/lilypond-user-fr/2021-01/msg00014.html reported 9 months ago, which I just added to the tracker. Which proves my point although this is not from the bug list this is a user list. So the report is not being put to the correct list in the first place. I like the separation of lists (user, dev, bug) I don't subcribe to the user list at all in fact (I am not that interested) and I knew that some developers don't subscribe to the bug list for their own good reason. I am not saying we will catch everyone in a timely manner but we do a pretty good job considering (and this bug was reported on the user list). Ignoring a report is my opinion the worst of all outcomes since it not only loses information but discourages people to engage in later reports or further investigation. Nothing is lost. Also I am not so sure it does discourage engagement that much, if a bug is that big a deal and we miss it, then I am sure that another person would report it, again we've plenty to do as it is. The information for maintainers of GNU software agree with me: https://www.gnu.org/prep/maintain/maintain.html#Replying-to-Mail When you receive bug reports, keep in mind that bug reports are crucial for your work. If you don’t know about problems, you cannot fix them. So always thank each person who sends a bug report. Which we do but this assumes that everything sent to bug email list is a bug (they aren't). In spite of us not advertising this as a way to report problems, a number of users have been creating issues on GitLab themselves, likely because that has become enough of a standard in other places. When replies are made on bug-lilypond, someone has to paste them on the ticket as well, for completeness, which leads to an awkward split where one does not know where the discussion is supposed to happen or whether the other person has read a remark on the other channel. But that has always been a problem and will always remain a problem (again I refer you to the bug report you found on the user list, the French user list as well, which is even more removed) also how many times have things been sent to the other user lists or dev lists or even direct to Han-wen/Jan et al? Again I think this is not that big a deal. So how about retiring bug-lilypond and directing to GitLab instead? Tickets can be triaged there, closing invalid ones, adding a minimal example if not present, perhaps changing the title. The requirement from the same page of GNU guidelines, I don't see the difference between triaging GitLab vs triaging Bug apart from the fact that it is very easy to use bug-list interface to track email threads - it's so easy to spot of something on the bug list has had a reply or not. I haven't use GitLab's interface that much
PATCHES - Countdown for October 14th
Hello, Here is the current patch countdown list. The next countdown will be on October 17th. A list of all merge requests can be found here: https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority Push: !956 Fix rounded-box-stencil and markup command \rounded-box - Lukas-Fabian Moser https://gitlab.com/lilypond/lilypond/-/merge_requests/956 !954 Avoid numeric SCM comparison - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/954 !952 Miscellaneous purity cleanups - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/952 Countdown: !963 Doc: make appendix listing paper sizes autogenerated - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/963 !960 Fix \keepWithTag on \autoChange and \partCombine - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/960 !959 Add `\Beat_performer` class of performers - David Kastrup https://gitlab.com/lilypond/lilypond/-/merge_requests/959 !955 NR: miscellaneous documentation fixes - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/955 !950 lily-version: show Guile version - Jefferson Felix https://gitlab.com/lilypond/lilypond/-/merge_requests/950 Review: !962 Web: mention homebrew installation for Mac OS - Jefferson Felix https://gitlab.com/lilypond/lilypond/-/merge_requests/962 !961 Remove `get-property-where-defined` function - David Kastrup https://gitlab.com/lilypond/lilypond/-/merge_requests/961 New: No patches in New at this time. Waiting: !913 release: binaries with cairo - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/913 *** -- Regards James OpenPGP_0xAAC8D177A7F5A364.asc Description: OpenPGP public key
