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: Python coding style
For automatic PEP8 formatting, there is autopep8: https://pypi.org/project/autopep8/ and yapf: https://pypi.org/project/yapf/ among others. Cheers, Joram
Re: Parsing JSON in C++
>> 1. LilyPond already seems to use some parts of the BOOST library (which >> is kind of the extended C++ STL). > > Not that I know of. > You're right. I just quickly skimmed through a grep and found this: https://github.com/lilypond/lilypond/blob/master/flower/include/yaffut.hh#L2 or a define HAVE_BOOST_LAMBDA in an older version. Cheers, Joram
Re: Parsing JSON in C++
> in C++ I worked with property_trees from BOOST (under the BOOST license): > > https://www.boost.org/doc/libs/1_73_0/doc/html/property_tree.html Two more remarks: 1. LilyPond already seems to use some parts of the BOOST library (which is kind of the extended C++ STL). There should be no license issues. 2. Despite the fact that there is no "json" in its name it works with json files very easily: boost::property_tree::ptree pt; boost::property_tree::read_json(ss, pt); Cheers, Joram
Re: Parsing JSON in C++
Hi, in C++ I worked with property_trees from BOOST (under the BOOST license): https://www.boost.org/doc/libs/1_73_0/doc/html/property_tree.html 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
Re: issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)
Am 26.04.2018 um 12:13 schrieb Torsten Hämmerle: > I hardly dare to admit it, but all I used was Windows' infamous Paint > program :D ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)
Hi Torsten, I've confidence in your algorithm. I just thought I post a situation which I would have neglected at first – without knowing what your algorithm does. Thanks for your explanation! It seems pretty robust and straightforward to me, now. Are the two algorithms the equivalent if you make the green line of the old algo ½ a staff space longer and add the "just touching" case? One more question: How do you produce those images? They look too perfect to be drawn by hand (Inkscape etc.) but they're also too far from music notation that I would want to produce them via LilyPond. Cheers, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
SVG crop
Dear Étienne, I'd like to understand what your contribution related to https://codereview.appspot.com/329990043/ does. Does it mean that after this patch we can automatically crop lilypond snippets created with the svg backend? So we can use and include the lilypond-book-preamble and produce svg snippets with it that are cropped like they would if I used a png backend? Or do I misunderstand what it is about? Best, Joram Am 10.08.2017 um 15:22 schrieb Étienne Beaulé: > I plan to contribute patches related to SVG rendering. > > Thank you! > > Étienne ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Lilypond down
Hi, lilypond.org seems to be downforeveryonenotjustme. Cheers, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: True Hand-engraved Dashed Slurs
Hi, Am 27.06.2017 um 22:34 schrieb tisimst: > Take my vote for having it as the default. It is just my gut feeling and nothing I could prove, but I see (at least) two use cases for dotted slurs: 1. The current default looks like what I would prefer for "optional slurs". I.e. in songs with two different distributions of syllables in the verses, one verse has two notes with two syllabels and the other verse combines them into one note with a slur. http://lilypond.org/doc/v2.18/Documentation/notation/techniques-specific-to-lyrics#divisi-lyrics Here I would like the thickness to change as it would in a normal slur. 2. If it is more a annotation/editorial slur, your constant thickness variant looks more appropriate to me. Do you see some reason for this feeling or did I just happen to see these use cases once or twice like that way? Best, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GSoC 2017
Hi, Am 06.03.2017 um 09:41 schrieb Urs Liska: >> http://lilypondblog.org/2014/01/smufl-fonts-in-lilypond/ >> >> I don't know whether this is still up to date. > Oh, me neither. > Joram? 1. Nathan was coding this, I just included this into oll and wrote the post. 2. I guess it still works. 3. IIUC, this was just a set of overrides and callback functions picking up the correct symbols from a smufl font, doing the mapping by glyph name. So pretty much all you could do without touching lilypond directly. I guess for the GSoC the approach would be quite different and I hope Abraham can point into the right direction. Cheers, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Automatic LyricExtenders (issue 313240043 by perpeduumimmob...@gmail.com)
Hi, Am 06.02.2017 um 20:08 schrieb d...@gnu.org: > https://codereview.appspot.com/313240043/diff/21/scm/define-grob-properties.scm#newcode188 > > scm/define-grob-properties.scm:188: (collapse-length ,ly:dimension? "An > automatically generated > collapse-width maybe? Length is more like a list length? The original idea for a name was "minimum-length". Then there was a lengthy (no pun intended) discussion, because it's different from what happens at hairpins, leading to "collapse-length". While I understand the width/length reasoning from a programming point of view. In the score, I would still call it a length of an extender line and not a width. Because a line width is sth. different. (Native speakers please correct me.) Cheers, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders
> As extender events are generated automatically now it probably is a > good idea to tell yacc / bison to recognize but ignore "__" tokens. I don't know at which level the __, \overrides and the automatic extenders interact. But would it make sense to use __ now, to force an extender e.g. on a single long note? __ would probably look nicer than the much longer \override. One drawback might be, that old scores have forced extenders then (if not treated by convert-ly - but without convert-ly other things are wrong, too). Cheers, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function to be included somewhere in scm/*
Hi, I tested the patch on my scores now (SATB choirs) and it works perfectly. I applied the 0001-Automated-lyric-extenders.patch and it adds the extenders where I had put them by hand before and a few other reasonable places. Before, I made a per-syllable-decision whether I put it or not. Now, a given minimum-length is much more consistent troughout the piece. 1.5 is a reasonable default value in my scores. Explicit __ extenders are printed no matter if it is too short or not. Is that expected? (It makes sense but looks ugly :) But ok, if the users insists.) So, I could not find any drawbacks. It works. The questions about how many properties are needed and how they are called, are going into a good direction, I think. Thanks for your work, Alexander and Knut et al.! Cheers, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function to be included somewhere in scm/*
Am 16.12.2016 um 17:38 schrieb Alexander Kobel: > [2] Side Note: other proposed names for minimum-length so far: > > (1) minimum-space > (2) show-length > (3) hide-below-length > (4) hide-if-shorter-than > (5) minimum-visibility > (6) visibility-threshold > (7) printing-threshold > (8) extender-threshold At a first glance, the property is still the same, just the behaviour for shorter extenders changed: before: shorter extenders are prolonged after: shorter extenders are not visible But at a second glance, the minimum-length for LilyPond grobs usually means that the object is visible and the length is at least minimum-length (for glissandi, etc.). Using it to hide a shorter object feels inconsistent, IMHO. So I agree with Werner. But I have no favourite naming, all of them sound wrong to me - a slight preference for (6). Cheers, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function to be included somewhere in scm/*
Hi Alexander, in your example, the last line is just a mockup, isn't it? It is not done by the proposed function? The extender after "We" in the last line is unexpected for me. Cheers, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stepping down and moving on
Dear David, I have nothing to add to what others have written here. But I want to repeat it from my side: Thank you so much for your work on LilyPond! Thank you for new functionality, for cleaner code, for easier input syntax, for leading discussions with insightful contributions and LilyPond facts and for the help for so many on this list! I was kind of shocked when I read the mail subject from your address. But I am convinced that it is a good decision for your finances and your future - I feared it would happen earlier. I wish you a good start in your new position. Hopefully, we will see you from time to time on these lists. Cordially, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Code examples in docs
Hi Urs, a very uneducated guess: Could it be that the html pages are only generated if the input has changed and as you change the generating code and not the doc-input, the generation is skipped? It is still strange that it works if you empty the file. Cheers, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How to create complex chord
Hi Larry,
some comments first:
a) This is a mailing list for Lilypond development (changing the program
itself), please use the lilypond-user list for user questions.
b) If you reduce your code to the absolute minimum, you may find the
issue yourself and you are more likely to find someone looking into it
and help you: http://lilypond.org/tiny-examples.html
Concerning your question: I reduced your example a bit below. What you
need are the lines marked with comments (%). If it is not clear please
search in the manual for change staff and voices ("I hear voices").
HTH,
Joram
\version "2.18.2"
\language "english"
global = {
\key e \major
}
right = \relative c' {
\global
\change Staff = "left"% you need to change into the lower staff
\voiceOne % and make this voice the upper one
\tuplet 3/2 { e,8 gs cs }
\oneVoice % change back
\change Staff = "right"
}
left = \relative c, {
\global
\voiceTwo % if there would be shorter notes with stems
% this part should be the lower voice
1
\oneVoice % back to normal mode: only one voice in
this staff
}
\score {
\new PianoStaff <<
\new Staff = "right" \right
\new Staff = "left" { \clef bass \left }
>>
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lose the tagline (permanently)
>> I'm fine with making it classier rather than flashy. But removing it is >> not doing us a favor. >> > > Even though I don't love having print by default, there are times when I do > leave it and having it classier is a wonderful idea. Classier sounds good. My proposal stands [1]: LilyPond 2.XY – lilypond.org Not because I insist on this version but to narrow the discussion a bit to actual proposals – "classier" is a quite wide range ;) Cheers, Joram [1]: http://lists.gnu.org/archive/html/lilypond-devel/2016-02/msg00139.html (the 'www.' was criticized) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Music function for arrow directions in arpeggios
Hi Simon, Am 24.02.2016 um 21:50 schrieb Simon Albrecht: > On 23.02.2016 22:22, Noeck wrote: >> the names \arpeggioUp and \arpeggioDown are still free and >> would me much more lilypondish. > > More imprecise, really. It’s really only the direction of the arrow > that’s changed, not the direction of the whole grob. Well the rest of the grob is invariant to rotations so you can't really tell ;) While this is true for the current \arpeggioArrowUp and Down commands, the proposed tweaked arpeggios would need names like \arpeggioWithArrowUp and \arpeggioWithArrowDown to be really precise. If you insist on the distinction from things like \slurUp \slurDown, a comparable situation could be \upbow \downbow. So how about \uparpeggio \downarpeggio? My term 'lilypondish' was not related to the name but to the fact that the tweaked arpeggios are written as postfix and do not need to surround the note. Cheers, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Music function for arrow directions in arpeggios
Am 24.02.2016 um 00:08 schrieb Dan Eble: > Is this a case where attaching an arpeggio to a chord with ^ or _ should make > a difference, or do I misunderstand the point of those characters? That was also discussed in the old thread. Not conclusive but with more insights than I have: https://lists.gnu.org/archive/html/lilypond-user/2015-01/msg00365.html ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Music function for arrow directions in arpeggios
Hi, > I like this a lot and I feel like I've seen this exact discussion > before, but it didn't result in any core changes. https://lists.gnu.org/archive/html/lilypond-user/2015-01/msg00908.html > Dev Team, > > Any reason \arpeggioArrowUp and \arpeggioArrowDown can't be defined this > way from the beginning? Is there a use-case where the "\arpeggioArrowUp > \arpeggio" way is necessary? I think at first it was just a property that could be set with an override. Then this was put into a command for convenience http://lilypond.1069038.n5.nabble.com/grand-predefined-command-thread-td109680.html#a109692 However, the names \arpeggioUp and \arpeggioDown are still free and would me much more lilypondish. Best, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lose the tagline (permanently)
Hi,
>> 1) It is in *English* ...
>
> So let's try cutting it down to something language independent and
> short. Like
>
> 턵 www.lilypond.org
What is the tiny symbol in front of the url? A time signature but why?
>> 2) In general such a phrase looks *unprofessional* to me ...
>
> Shrug. Professional and unheard of does not help us.
I agree with that.
>> % for online distribution the www part can be dropped, it is intended
>> % for printed scores which don't profit from the link.
>
> The fate of PDF is to be printed. Particularly those who have never
> heard of LilyPond are rather likely to receive a piece of paper rather
> than a PDF file.
Yes, that's why I mostly (always?) keep the website. On the other hand,
people are used to enter search terms in their browser to find out more.
so it is more an invitation ("you can/will find more online") than
really required information.
Cheers,
Joram
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lose the tagline (permanently)
Hi Am 23.02.2016 um 15:00 schrieb David Kastrup: > I do agree that it should be unobtrusive, but I > think that the LilyPond tagline meets that bar. As I wrote in my other mail, I would vote to drop the "music engraving with" part as it is not language independent and does not provide more information (you can probably see from the score that it is about music). Cheers, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lose the tagline (permanently)
Hi Abraham,
I agree with you. I always change it or remove it for the following reasons:
1) It is in *English* and would be the only English part in my otherwise
German score – that looks just unprofessional. That's the most important
part for me.
2) In general such a phrase looks *unprofessional* to me – more like
some crappy shareware from old times (that Apple does it with "sent from
my iPhone" doesn't make it better).
3) People might be *scared away* because of this. And as people know
this from demo versions, some think you can not or are not allowed to
remove this line they don't like.
What I usually do is to set the tag line to "LilyPond 2.19" or the thing
below [1]. That is a) language independent b) short c) contains all
relevant information.
Cheers,
Joram
[1]:
tagline = \markup
\with-url #"http://lilypond.org; \line {
"Lilypond"
#(string-join
(map (lambda (x) (if (symbol? x)
(symbol->string x)
(number->string x)))
(list-head (ly:version) 2))
".")
"– www.lilypond.org"
}
% for online distribution the www part can be dropped, it is intended
% for printed scores which don't profit from the link.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Define French as a separate input language (issue 288290043 by v.villen...@gmail.com)
Hi, 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)? Cheers, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: hyphen syntax
Hi Simon, > You should have come back to the entire quote: ‘And I think the double > items suit the advanced functionality better (advanced in comparison to > printing a hyphen character from a font).’ I didn’t mean ‘advanced’ in > the sense of ‘only for advanced users’ or ‘rare’. I know. I'm sorry to misuse the quote a bit. Your sentence just made me want to write what I was thinking before – even though it did not fully fit to your statement. > But three characters versus four characters to type doesn’t seem enough > of a difference to justify the change. That might well be true. I am undecided myself. I think I like the single hyphen (syl - la - ble) still ;) Cheers, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: hyphen syntax
Hi,
Am 17.02.2016 um 17:54 schrieb Simon Albrecht:
> And I think the double items suit the advanced functionality better
I thought about this when Dan wrote his first mail, but I wanted to keep
my comment short. I think many of you know the fun you can have with
backslashes and escaping (as in http://xkcd.org/1638/). So it is a good
idea to use rare expressions for special functionality to avoid escaping
to get back to the original thing (\ or -).
But the hyphen is just the most natural thing in a lyricmode
environment. People asked on this list about it and also in scores
online I see people using single hyphens because they are just natural.
Some try 'a - b', realize it uses 3 notes and then go for 'a- b'.
Technically, soft hyphens would be nice (U+00AD) but who wants to enter
that (and its invisible in the code).
My impression of LilyPond is: The core functionality is very cleverly
designed and very concise, just think about { a4:16-.->\f( }. One could
have invented something like \notemode {
a1/4\tremolo{1/16}\staccato\accent\dynamic{f}\startSlur }. This was only
obtained by defining the reasonably shortest syntax for the most
frequent items.
So I agree with the sentiment I read from Dan's first mail: The single
hyphen would be natural to separate syllables. For the rare case of a
literal single hyphen, I think "-" is a fair way to get it. Or to come
back to the quote I started with: IMHO a lyric hyphen is not advanced.
Just my comment.
Joram
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: hyphen syntax
Hi Dan,
Am 14.02.2016 um 20:41 schrieb Dan Eble:
> Are there technical limitations that require typing a double hyphen to
> hyphenate lyrics? Why not just one?
Because this way, a single hyphen keeps its function as an ordinary
character and a double-hyphen is not a really used/required item, I
guess? If that's true, the question is in which cases a single hyphen as
a syllable is really needed ("-" would probably work, too).
Joram
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: lilypond-book/pdflatex: LaTeX Error: Environment lilypond undefined.
Both the test file and the issue text show wrong syntax like
\end\lilypond} or \end{lilypond\ and the test file includes a file2
which we do not have. If I correct that it works for me (Ubuntu).
So in order to make this reproducible and trace it down, complete and
correct files would be good to have, to make sure such typos are not the
reason for it.
Cheers,
Joram
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Super and sub
Hi, to follow the instructions given on http://lilypond.org/doc/v2.19/Documentation/contributor/git_002dcl I need a Rietveld account. I have a sourceforge account for testlilyissues, is that equivalent to an Allura account? Do I need someting more to use git-cl correctly? Best, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Super and sub
> To login on Rietveld ... Perhaps I should rather ask: where is Rietveld? I found this https://codereview.appspot.com/search?base=http://git.savannah.gnu.org/gitweb/?p=lilypond.git/trunk/ and tried to sign in. But Google wants my phone number, I guess I am out :( Best, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: lilypond-book/pdflatex: LaTeX Error: Environment lilypond undefined.
Here is the corrected input file.
I ran
lilypond-book testbook.lytex
pdflatex testbook.tex
without errors which produces a correct (though strangely aligned) pdf file.
Cheers,
Joram
% test
\documentclass[a4paper]{article}
\usepackage[utf8]{inputenc}
%
\begin{document}
\begin{center}
\begin{LARGE}
\textbf{Test}
\vspace{1em}
\end{LARGE}
\end{center}
\noindent
Das ist der Text...
\begin{lilypond}
\version "2.18.2"
\include "deutsch.ly"
\header {
title = "La Paloma"
poet = "Helmut Käutner"
composer = \markup \center-align {"Werner Eisbrenner"
\small "nach"
"Sebastian Yradier"
\small "(1809 - 1865)"}
enteredby = "Ulrich Windl"
}
papersize = "a4"
melody = \context Voice = "melodie" \relative c' {
\clef violin
\key a \major
\time 2/4
\repeat "volta" 2 {
r4. e8 | e2 ( |
\times 2/3 { e8 ) cis d } e fis |
\times 2/3 { gis a fis } gis e |
d2 |
r4. e8 |
b'2 ( |
\times 2/3 { b8 ) cis a } b gis |
\times 2/3 { a gis fis } e8. d16 |
cis2
}
\repeat "volta" 2 {
\times 2/3 { a'8 a a } a gis |
\times 2/3 { b b a } gis fis |
fis e4. ( | e2 ) |
\times 2/3 { gis8 gis gis } gis fis |
\times 2/3 { fis e e } e8. fis16 |
e d cis4. ( |
cis2 )
}
\repeat "volta" 2 {
\times 2/3 { r8 e e } \times 2/3 { e fis dis! } |
e2 |
\times 2/3 { r8 e e } \times 2/3 { e e fis } |
gis4 b ( |
\times 2/3 { b8 ) cis a } \times 2/3 { b gis a } |
\times 2/3 { fis gis a } \times 2/3 { cis4 b8 } |
\times 2/3 { b, cis d } \times 2/3 { fis4 e8 } |
}
\alternative { {cis2} {a2} }
}
harmony = \chords {
\germanChords
\repeat "volta" 2 {
r2 a r r e r e:7 r r a
}
\repeat "volta" 2 {
r r e r r e:7 a r
}
\repeat "volta" 2 {
r r r e:7 r r h4 e:7 a2
}
}
textA = \lyricmode {
Ein Wind weht von Süd und zieht mich hi- naus auf See.
Mein Kind, sei nicht trau- rig, tut auch der Ab- schied weh!
Mich trägt die Sehn- sucht fort in die blau- e Fer- ne,
un- ter mir Meer, und ü- ber mir Nacht und Ster- _ ne,
Auf, Ma- tro- sen, oh- é! Ein- mal muß es vor- bei sein.
Nur Er- inn'- rung an Stun- den der Lie- be bleibt noch an
Land zu- rück.
}
textB = \lyricmode {
Mein Herz geht an Bord, und fort muß die Rei- se gehn,
dein Schmerz wird ver- gehn, und schön wird das Wie- der- sehn.
Vor mir die Welt. So treibt mich der Wind des Le- bens.
Wein' nicht, mein Kind, die Trä- nen, sie sind ver- ge- _ bens!
See- manns Braut ist die See, und nur ihr kann er treu sein.
Wenn der Sturm- wind sein Lied singt, dann winkt mir der gro- ßen
Frei- heit _ Glück.
}
\book {
\score {
<<
\new ChordNames {
\harmony
}
\new Voice {
\autoBeamOff
\melody
}
\new Lyrics \lyricsto "melodie" \textA
\new Lyrics \lyricsto "melodie" \textB
>>
\header {}
\layout {}
\midi {
\context {
\Score
tempoWholesPerMinute = #(ly:make-moment 60 4)
}
}
}
\markup {
\column {
\line{Wie blau ist das Meer, wie groß kann der Himmel sein?}
\line{Ich schau' hoch vom Mastkorb weit in die Welt hinein.}
\line{Nach vorn geht mein Blick, zurück darf kein Seemann
schaun.}
\line{Kap Horn liegt auf Lee, jetzt heißt es auf Gott
vertrau'n.}
}
}
}
\end{lilypond}
Mehr Text
%\lilypondfile[quote,noindent]{file2.ly}
Das war's.
\end{document}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reasons why a LilyPond-to-MEI conversion should be developed
Hi Urs, possible advantages could be: a larger user base and maybe contributions from more (academic/professional/knowledgeable) people to the engraving quality of LilyPond. Offering a high quality engraving solution for an already existing community. And other synergy effects and perhaps funding. As the input is further disentangled from the output, users could use any input tool that supports MEI and still can get LilyPond output. That way we could have a GUI input method (which I presume exists for MEI) for free. That's what comes to my mind. Me personally, I don't see the point in creating MEI files. I like the LilyPond input language. It is a concise and human readable representation of the music. I can use version control (git). I don't see what MEI would improve for me. I guess MEI is rather less readable and auto-generated ly code likely, too (therefore I don't use Denemo). My desired output format is pdf – so I have what I need. Perhaps if freely available databases with MEI encoded music would exist, it could get interesting to convert these to ly for further tweaks. So, I support the idea but I see no personal advantages. Cheers, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Auto-generated code, (was Re: Reasons why a LilyPond-to-MEI conversion should be developed)
Dear Richard, first I want to emphasize that this was not against you or Denemo, just a connection between my favoured workflows and the tools I use. I don't understand 'traverse the staffs' in your sentence: > It *does* provide a > default LilyPond output, but you can just as easily traverse the staffs > you have entered generating the output you would prefer If I used Denemo and I wanted to do tweaks in lilypond code, I would have to work within auto-generated ly code, wouldn't I? Best, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guitar right-hand fingering
Hi Peter, these letters are defined around line 2191 of scm/define-grobs.scm Adding (not replacing x) the c there turns every unknown number to c. But perhaps you can find your way from there. Even though I havn't seen anything else besides pima, I think your point about completeness is right and c is better than x. Do you have a reference for that? I found some occurences of c on the web but also e: http://guitaralliance.com/p-i-m-a-unleashed/pima-in-detail/ Cheers, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Misplaced staccato dots on beams
I conclude from the patch mail, that this is going to be fixed soon. PUSH: Keith OHara: staccato moves to avoid ledge on opposite side of staff http://code.google.com/p/lilypond/issues/detail?id=4184 If that is true, it is amazing how quick you are! Thanks, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3286: add single-C time signature style (issue 164830043 by nine.fierce.ballads at gmail.com)
Hi, If I needed to set the Schubert Op90n3, which looks like 4/2 to me, I might notice a single-C style in the manual, figure out how to use it, wonder why the c's are not barred where Schubert has them barred, look into the code, be confused, decide to use markup like I should have in the first place. that was my main objection some mails back in the mailing list. The only use diverging from the default style I encountered was a 4/2 timing denoted as ¢. And this is not covered by the new rules (you would have to use 2/1). That’s why I suggested to use the denominator to choose the symbol because as a general rule it come closer to the historic use of the ¢ sign, imho. However, (as also stated before) I can not see a fixed and historically used rule here and rather would prefer a *simple way* to choose the symbol and the timing with optional arguments: For the tempo we have: \tempo Allegro 4 = 120 (and no rule turning speeds (4=120) into words (Allegro) - this case is different but also similar if you consider the following.) I would suggest this for times: \time 4/2 C and similar symbols for existing time signature symbols, like (C|, CC, C|C| or c, ¢, if you like to allow such special symbols, or S and $ etc.). Then it would be clear and easy for the user to choose a time and a symbol without scheme code. If there is a fixed and consistently used rule in history, including ¢ and ¢¢ etc., I like the idea of such a rule. Cheers, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3286: add single-C time signature style (issue 164830043 by nine.fierce.ball...@gmail.com)
I haven’t implemented the double-C cases yet.
This is what I think would be best:
* leave the default style alone
* add to the C style: 4/2 - CC, 2/1 - cut-CC
This would end the equivalence of default and C styles. Does that seem like
a bad idea to any seasoned Lilypond developers? I would prefer to hear it
now than to implement it first and hear about it in code review.
My reasoning is that the CC and cut-CC time signatures seem too obscure to be
enabled by default, but too closely related to the C and cut-C time
signatures to deserve a separate style. The new time signatures would make
sense within this matrix:
numberedsingle-digit
C single-C
Hi Dan,
it is not my intention to bother you, but I would like to understand
this. Is this your plan?
style
defaultc¢ 2/4 2/1 4/2 8/4 3/4 6/8
C c¢ 2/4 ¢¢ cc 8/4 3/4 6/8 ---
single-C c¢ 2/4 ¢c 8/4 3/4 6/8 ---
numbered 4/4 2/2 2/4 2/1 4/2 8/4 3/4 6/8
single-digit 42224836
With this meaning:
- I indicate the C symbols with c and ¢
- a mono space font needed
- default means the current C style
- C means your C style
Will single-digit be renamed to single-number?
Source for showing time signatures:
\version 2.18.2
%http://www.lilypond.org/doc/v2.18/Documentation/internals/time_002dsignature_002dinterface
music = {
\time 4/4 s1 \time 2/2 s
\time 2/4 s2
\time 2/1 s1*2 \time 4/2 s \time 8/4 s
\time 3/4 s2. \time 6/8 s2.
}
\new Staff { \override Staff.TimeSignature.style = #'default
^default \music }
\new Staff { \override Staff.TimeSignature.style = #'C
^C\music }
%\new Staff { \override Staff.TimeSignature.style = #'single-C
^single-C \music }
\new Staff { \override Staff.TimeSignature.style = #'numbered
^numbered \music }
\new Staff { \override Staff.TimeSignature.style = #'single-digit
^single-digit \music }
\new Staff { \override Staff.TimeSignature.style = #'mensural
^mensural \music }
\new Staff { \override Staff.TimeSignature.style = #'neomensural
^neomensural \music }
Cheers,
Joram
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Suggestion about input languages
Dear developers, [tl;dr: how about ISO language codes for input language selection?] some time ago, I suggested to add French (français) to the list of note-name languages as an alias to italiano. This is the current state, español was also added. The discussion back then was about some inconsistencies: - the language for commands is English, these keywords are in different languages: \language deutsch ^ English ^ German - problem: français needs a utf8 char ç - espanol is a valid note-name language, francais isn’t *Summary*: special characters are needed for some languages to spell them correctly, this is because no international system is used here Now I have a new suggestion: We could use ISO 639-1 language codes for the input language specification: http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes Advantages: - international standard - widely adopted and known for language selection - the user language doesn't matter (no need to decide between French and français) - no special characters (plain ascii) - it is short The current language names could be kept for backwards compatibility. This would mean, the current alias list scm/define-note-names.scm:968 would be extended like this: - '((espanol español) - (italiano français))) + '((espanol español) + (italiano français) + (nederlands nl) + (catalan ca) + (deutsch de) + (english en) + (espanol es) + (italiano fr) + (italiano it) + (norsk nb) + (norsk nn) + (portugues pt) + (suomi fi) + (svenska sv) + (vlaams vls))) ; unclear* * I have no good proposition for vlaams as the language code is nl like Dutch/nederlands. The ISO 639-2 code is vls, another option might be nl-BE? What do you think? Cheers, Joram ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
