Re: Renaming baseMoment
You guys know much better, but I would be wondering "was it baseBeatLength or beatBaseLenth"? A shorter name would be easier to remember. How about baseLength?
Re: Joram Berger's 'Visual LilyPond Index' revisited
Big thanks to Werner Lemberg for thoroughly updating (rewriting) the visual index which I once put here¹ as an easy way to access the LilyPond documentation. With some delay, I now merged this pull request², you can look at the latest PDF here³. So it is no »Christmas present« any longer, but for the record: You can use all code from https://github.com/joram-berger/visualindex and in particular the visualindex*.ly files under the terms of the GNU Free Documentation License (GFDL). That way it can be integrated into the LilyPond documenation. I also made that clear in the readme. By the way, back then, I tried to do the same with the SVG backend to produce an SVG image that can be used in HTML documentation, but I wasn’t able to. So that would still be an idea for the HTML documentation. Cheers, Joram ¹: https://github.com/joram-berger/visualindex ²: https://github.com/joram-berger/visualindex/pull/1 ³: https://github.com/joram-berger/visualindex/files/8239967/visualindex-2.23.pdf Am 24.12.21 um 23:51 schrieb Jean Abou Samra: Le 24/12/2021 à 16:50, Werner LEMBERG a écrit : The last few days I played around to update and extend Joram's excellent 'Visual LilyPond Index' so that it covers the current development version. I've submitted an intermediate stage as a Pull Request that displays almost all grobs from the `Score`, `Staff`, `Voice`, `ChordNames`, `FiguredBass`, and `Lyrics` contexts. I plan to extend it (on a second page) so that more contexts are covered, together with grobs that are not part of any context by default. https://github.com/joram-berger/visualindex/pull/1 https://github.com/joram-berger/visualindex/files/7774733/visualindex-2.23.pdf Have fun! Werner Aaah, so you were *really* testing balloons on severy single grob type in LilyPond! [*] Good work! How about asking Joram to release the original under a GFDL-compatible license and making this a Christmas present to the documentation? Happy Christmas, Jean [*] https://gitlab.com/lilypond/lilypond/-/merge_requests/1077#note_794557700
Re: RFC: rethink horizontal alignment of mid-staff bar numbers
> 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. But is it possible that they have a different alignment with the current code? In case a user turns them on, they would look really strange in there position on the margin. Joram
Re: RFC: rethink horizontal alignment of mid-staff bar numbers
> I would very much like that LilyPond has the ability of automatically > adjusting the horizontal position of some grobs, in particular dynamic > signs, bar numbers, and rehearsal marks. The idea is that a large > delta from the optimum vertical position would make LilyPond retry to > horizontally position the grob within some delta (say, ±2 notehead > widths) from the 'correct' position. If the grob can then be moved > (much) nearer to the standard vertical position, LilyPond should use > this adjusted horizontal position. That woud be great!
Re: RFC: rethink horizontal alignment of mid-staff bar numbers
Hi, I like the change in the bar number alignment. I have some comments to your proposal. (The current solution has similar issues, so most of these are not speaking against proposed changes.) The -> denotes the solution for which that is an argument. 1. putting the bar number over the measure it belongs just makes sense (-> Gould) 2. The end of a measure is typically less crowded so middle-of-line bar numbers need less vertical shifts for collision avoidance which looks better. The new implementation looks irregular and jumpy (-> current) 3. In particular at the start of a line, the number is moved up by every treble clef, i.e. we have an exception by collision avoidance in the most common case. (-> current or MR) 4. Shifting it further right than left aligned is too much and breaks the visual connection between bar line and bar number (-> not further) 5. Bar numbers on the right margin look odd. They should definitely be right aligned in that position (if the user turns them on at all) Therefore, I would center-align it like your MR does for begin-of-line and middle-of-line positions, but not at the end of a line. Cheers, Joram
Re: ancient convert rules
> The python re syntax is clear, it just requires the right amout of > backslashes or r-prefixes I definitely overlooked how often there are *too many* backslashes in the code. So there are a lot more changes requried than what is in merge request 363: https://gitlab.com/lilypond/lilypond/-/merge_requests/363 Cheers, Joram
Re: ancient convert rules
Hi Jonas,
some comments to that:
1. I (hopefully) fixed all the escaping issues like #6024 in my merge
request: https://gitlab.com/lilypond/lilypond/-/merge_requests/363
The python re syntax is clear, it just requires the right amout of
backslashes or r-prefixes;
re.sub(r'\\command', r'\command', s) or
re.sub('command', '\\command', s)
2. pylint spots the clearly wrong ones (e.g. \m) but not the valid ones
(e.g. \n in \numbers or \t in \times). I would gladly compare your fixes
to mine.
3. We might want to cleanup convertrules.py. And I doubt that all
conversions work flawlessly for ancient versions all the way to 2.21.
But IMHO this issue is not the right excuse to drop possibly working
functionality.
4. Mutopia uses very old versions. There was an effort in 2014 - 2015 to
update all Mutopia scores to a version > 2.0.0. So version 0 or 1 should
not be used any more (one exception). But 2.2.0 is also very old.
Details for Mutopia:
Update Mutopia pieces with LilyPond versions < 2.0
https://github.com/MutopiaProject/MutopiaProject/milestone/5
Apparently, one work (KV487) is missing from that effort.
2.16 and 2.18 are the most frequent versions in Mutopia:
766 \version "2.16.0"
736 \version "2.18.0"
553 \version "2.18.2"
519 \version "2.16.1"
300 \version "2.14.2"
186 \version "2.10.33"
184 \version "2.12.2"
176 \version "2.10.3"
156 \version "2.6.0"!!!
Besides KV487 with version 1.9.8, the oldest versions are (with number
of occurances):
1 \version "2.2.0"
41 \version "2.4.0"
1 \version "2.4.1"
7 \version "2.4.2"
1 \version "2.4.6"
4 \version "2.5.21"
156 \version "2.6.0"
12 \version "2.6.2"
9 \version "2.6.3"
51 \version "2.6.4"
4 \version "2.6.4.3"
5 \version "2.6.5"
1 \version "2.7.13"
1 \version "2.7.24"
37 \version "2.7.29"
1 \version "2.7.30"
3 \version "2.7.38"
1 \version "2.7.39"
58 \version "2.7.40"
46 \version "2.8.0"
23 \version "2.8.1"
5 \version "2.8.2"
1 \version "2.8.3"
11 \version "2.8.4"
58 \version "2.8.5"
2 \version "2.8.6"
2 \version "2.8.7"
4 \version "2.8.8"
1 \version "2.9.16"
1 \version "2.9.18"
4 \version "2.9.2"
9 \version "2.9.9"
tl;dr: I would not drop conversion rules unless we know that they fail.
Cheers,
Joram
Re: new procedure with GitLab CI
Am 07.06.20 um 12:30 schrieb Jean Abou Samra: > The real problem merge commits pose in my eyes is that they can > make 'git bisect' more difficult. I'm not an expert here, so I'll > ask the question: would it make 'git bisect' completely unusable? > Or just complicate it only in some specific cases? Git bisect also works with merge commits. There are some tricky situations in which git bisect needs some extra care but it is not unusable in general. Some relevant reading on it might include: https://gist.github.com/canton7/3737126 https://mirrors.edge.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html Personally, I like rebasing for small local commits to keep the history simple and clean. But use merges if that is what is going on, e.g. merging a feature branch (existing on remote) into the main branch. I always found it helpful to reflect in git what actually happens. Cheers, Joram
Re: GSoC 2020: SMuFL glyph name to index lookup
Hi, Am 28.05.20 um 06:44 schrieb Werner LEMBERG: >> This would mean every user would need to learn the new vocabulary if >> they want to reference glyphs in their scheme code. > Definitely not :-) However, I can imagine that LilyPond provides an > option to *also* allow Bravura glyph names (or maybe instead; I don't > have an opinion here) for `\musicGlyph`. > Here is an implementation of the analogous `\smuflglyph`: https://github.com/openlilylib/openlilylib/blob/master/custom-music-fonts/smufl/definitions.ily#L170 And here is the mapping of smufl names to code points: https://github.com/openlilylib/openlilylib/blob/master/custom-music-fonts/smufl/smufldata.ily converted from the json file provided by SMuFL. And here is a mapping of LilyPond names and SMuFL names (not complete but extensive): https://github.com/openlilylib/openlilylib/blob/master/custom-music-fonts/smufl/definitions.ily All taken from OpenLilyLib: https://github.com/openlilylib/openlilylib/tree/master/custom-music-fonts/smufl It is probably not the way to go for GSoC but might be interesting or save some typing work. Cheers, Joram
Re: migration to GitLab
Hi Dan, as far as I understand (from experience with other projects), you can clone anonymously (and fetch without authentication then). If you want to be able to push, you need to authenticate and then you also need to authenticate for fetch or pull. A way around that is to use the ssh urls and use ssh keys. In combination with the ssh-agent, you can then enter your ssh key password only once and push and pull afterwards. As `git remote -v` lists two separate urls for fetch and push I suspect there should be a way around that issue. Cheers, Joram
Re: Frescobaldi distribution packages
Ubuntu 20.04 will come with LilyPond 2.20. Older releases are usually not updated after the release and will keep 2.18. Ubuntu 2.20 will probably be released tomorrow. https://packages.ubuntu.com/focal/lilypond Frescobaldi will be 3.0.0 and not the latest 3.1.2: https://packages.ubuntu.com/focal/frescobaldi Cheers, Joram
Re: What's up with the broken web pages?
Definitely a python2/3 issue. While python2 uses byte strings by
default, strings are Unicode strings in python3 and byte strings need to
be decoded first.
Surely, you know that and the question is: which part of the website
creation is not fully ported to python3.
python2 [2.7.17]
>>> 'abc', u'abc', b'abc', 'abc'.encode()
('abc', u'abc', 'abc', 'abc')
python3 [3.6.9]
>>> 'abc', u'abc', b'abc', 'abc'.encode()
('abc', 'abc', b'abc', b'abc')
Best,
Joram
Re: lilypond.org now serving HTTPS
> My browser complains about mixed content, i.e. http-linked media on the
> page.
>
> Urs
Here (Firefox 73), the only warning is about the "Valid HTML 4.01" image
in the page footer. All other images (on the pages I looked at) have
relative src attributes and are served directly from lilypond.org via https.
Joram
PS: Btw, the only other warning I get is about -moz-border-radius which
was renamed to border-radius (without vendor prefix) in 2011 if I am not
mistaken. I also see commits that changed this in 2015¹, but perhaps
too late for the 2.18 website? Or I don't why the latest css is not served.
¹:
https://github.com/lilypond/lilypond/commit/a6f369ae2efe399ef9644a702d98187e93129a87
diff --git a/lilypond-manuals.css b/lilypond-manuals.css
index 995c217..8bff14a 100644
--- a/lilypond-manuals.css
+++ b/lilypond-manuals.css
@@ -450,9 +450,7 @@ div#search p, div#search form {
text-align: left;
padding: 0;
border: 1px solid green;
- /* Experimental rounded corners */
- -moz-border-radius: 10px;
- -webkit-border-radius: 10px;
+ border-radius: 10px;
margin: 1em;
}
@@ -461,8 +459,6 @@ div#search p, div#search form {
text-align: left;
padding: 0;
border: 1px solid green;
- /* Experimental rounded corners */
- -moz-border-radius: 10px;
- -webkit-border-radius: 10px;
+ border-radius: 10px;
margin: 0.5em 0.5em 2em 3em;
}
Re: Quarter Note Support for All Languages etc.
FWIW, I remember when "français" was introduced. I could not find it in the archives. But I think the consensus was that a correct spelling is better than sticking to ascii and that is why español was added because it was obvious. So without finding the reference, I think you logically complete what was already agreed back then (me saying that without having read the patches). Best Joram
Re: Integration of Guilev2 branches into master
I /think/ it is Unicode in NTFS now, but UCS/UTF-16 and not UTF-8: https://stackoverflow.com/questions/2050973/what-encoding-are-filenames-in-ntfs-stored-as https://en.wikipedia.org/wiki/Universal_Coded_Character_Set#Relationship_with_Unicode Joram
Re: Naming question for get_property, set_property
FWIW, python has getattr and setattr which would perhaps suggest get_prop(grob, "property") and set_prop(grob, "property", VALUE) I am not a fan of "arbitrary abbreviations" and get_property and set_property are only 4 characters longer. So maybe I would choose the latter (modulo your naming conventions w.r.t case) – just as one more data point, feel free to ignore it. Joram
Re: [RFC] weekly dev chats
> Found "Pidgin messenger" installed on my Ubuntu Studio. It purports to > talk AIM, Bonjour, Gadu-Gadu, Google Talk, Groupwise, ICQ, IRC, Simple, > Sametime, XMPP and Zephyr. No idea whether it does screencasts. FWIW, I’ve had positive experiences with Jitsi: https://jitsi.org/ It requires a modern (>2013) browser as it works via WebRTC, platform-independent, open source (according to their website). Audio/video calls and screen sharing is available and works (tried on Ubuntu and Windows). Cheers, Joram
Re: development process
Dear developers, tl;dr: * please continue those discussions to a constructive end * my experience as a non successful contributor after more than a year of (relative) abstinence from LilyPond, I enjoy reading the current drive in both commits and discussions in the aftermath of the Salzburg conference. (I wished I could have been there.) I am not a LilyPond developer, so the following is more an outside perspective. I decided to share it, because "potential new contributors" are mentioned several times. While sometimes there are no two ways about it, there is room for improvements and compromise, I guess. Neither the current dev process and tools are optimal nor is it advisable to change everything. Because I can feel some tension in the recent discussions, I’d like to emphasize that the following is to be read in a very friendly tone. Experience with trying to contribute I am working with software development every day. I wanted to contribute to LilyPond since about 2005. It never happened and there are some reasons: - Even after reading the CG and getting some helpful answers to questions, I never understood how the process works. - tools: - I am used to github+travisCI and to Atlassian/Bitbucket/Jira/Jenkins and I enjoy working with those setups. But I never understood the LilyPond toolchain and especially the path from a commit/issue to the final change in a LilyPond version. - I don’t understand why · there are so many tools involved, lily-git, git-cl and so many accounts required · it seems so hard to compile LilyPond on an ordinary Linux machine i.e. why I need LilyDev · dependencies on clang-format or (for a long time) python3 are frowned upon while the dependencies on guile and GUB look much more complicated to me. - I guess (because I haven’t worked my way through the current tools), several of the already listed tools with better integration of review and/or issue tracking would be an improvement over the current tools. - At some point I needed a Google account which I didn’t want and could not get without a cell phone. - I experienced quite some amount of misunderstandings and in a few cases insinuations which made it very unpleasant to invest the work to get over the technical hurdles. I felt a bit scared away. - According to what I read on lilypond-devel, quite frequently suggestions end up in an undecided state where some are for and some are against a proposal. But that is probably much less the case for patches. That’s my very personal experience. I have some minor local patches, some are made obsolete by recent development. In some months from now, I might make a new attempt to understand how contributing works. Braking things down --- I have the impression that what is currently discussed might be too big to be decided upon at once. There could be some merit in splitting things into smaller decisions. I see at least these points: 1. code style conventions a) checking tools (astyle, clang-format), for scm or python? b) changes only for new code? c) and their level of enforcement (hooks, review process, …) 2. tools for git, review, issue tracking, release management pros and cons have been mentioned for several options, but even if there is nothing new, a systematic assessment could help 3. development process / code of conduct a) number of stages from a proposed patch to a final change b) decision process and who decides what c) formal rules vs. consensus I am sure I missed some important points here. Even if it doesn’t matter at all, my personal choices would be: - tools: github+jenkins, but very open to gitlab and others definitely clang-format over astyle (just my experience) I moved once from trac to github. - less manual work in cherry-picking, testing, linking commits to issues - much more openness towards change - a clearer description how decisions are made and who decides while still preferring to keep a community mindset over a strict rule set. Many thanks to all developers for making LilyPond what it is and I wish that you can see those discussions as a fruitful way to improve things. In my opinion it matters for potential new developers. Cheers, Joram
