Re: LilyPond 2.18.0 released
On Mon, Dec 30, 2013 at 10:26 PM, Janek Warchoł janek.lilyp...@gmail.com wrote: Thanks and congratulations to everyone! Likewise: congratulations on a job well done! I’ve been closely following the latest versions, and I must say working with 2.18 does offer some great improvements over the previous stable releases. I wish I’d been more personally involved these past few years, but even as a mere spectator LilyPond’s progress never ceases to amaze. Special thanks to David for his proficiency and availability, and Janek for his seemingly endless enthusiasm! There again, people like you two are (in your own very different ways) a model to me and I wish I had your energy and endurance. And good luck Wilfred for keeping track with Frescobaldi, what you’re doing is *very* impressive and has ( as far as I’m concerned) nothing short of revolutionized how a LOT of people use LilyPond. (Scratch that: if it weren’t for you they wouldn’t use it, period.) A Happy new year to all, and see you on the other side! Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond 2.18.0 released
Hi Valentin, 2013/12/31 Valentin Villenave valen...@villenave.net: Special thanks to David for his proficiency and availability, and Janek for his seemingly endless enthusiasm! You're welcome! There again, people like you two are (in your own very different ways) a model to me and I wish I had your energy and endurance. Two years ago i would never think that it would be you talking like this about me - instead of the other way round :P And good luck Wilfred for keeping track with Frescobaldi, what you’re doing is *very* impressive and has ( as far as I’m concerned) nothing short of revolutionized how a LOT of people use LilyPond. (Scratch that: if it weren’t for you they wouldn’t use it, period.) I see that you must have already started New Years Eve celebrations and the party must be really hardcore, considering how you misspelled Wilbert's name ;-) Happy New Year to you all! Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: NR 2.4.1 - add Hammer/Pull snippets (issue 46730043)
LGTM, apart from a couple of nits
https://codereview.appspot.com/46730043/diff/1/Documentation/snippets/new/hammer-on-and-pull-off-using-chords.ly
File Documentation/snippets/new/hammer-on-and-pull-off-using-chords.ly
(right):
https://codereview.appspot.com/46730043/diff/1/Documentation/snippets/new/hammer-on-and-pull-off-using-chords.ly#newcode8
Documentation/snippets/new/hammer-on-and-pull-off-using-chords.ly:8: is
drawn. However @q{double arcs} are possible by using the
by setting the
https://codereview.appspot.com/46730043/diff/1/Documentation/snippets/new/hammer-on-and-pull-off-using-chords.ly#newcode9
Documentation/snippets/new/hammer-on-and-pull-off-using-chords.ly:9:
@code{doubleSlur} property to true.
doubleSlurs (with an s)
https://codereview.appspot.com/46730043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond 2.18.0 released
... and to prove that 2.18 has arrived, here is perhaps the first published score typeset with it: http://imslp.org/wiki/8_Solos,_Op.1_%28Stanley,_John%29#IMSLP309222 I have had to update Denemo to use the new \bar syntax, but otherwise everything went smoothly. Congratulations on the new release. Richard On Mon, 2013-12-30 at 17:50 +0100, David Kastrup wrote: Some of you might have seen this on the lilypond-announce list, but I repeat it here since not everybody may read the announce list. The big announcement to all the non-LilyPond lists will happen in a few days if we don't get major complaints. Here it goes: We are proud to announce the release of GNU LilyPond 2.18.0 - the new stable release. LilyPond is a music engraving program devoted to producing the highest-quality sheet music possible. It brings the aesthetics of traditionally engraved music to computer printouts. Among the numerous improvements and changes, the following might be most visible: * Many items are now positioned using their actual outline rather than a rectangular bounding box. This greatly reduces the occurrence of unsightly large gaps. * Sets and overrides can now use a simpler syntax * Triplets with a given group length can now be written using a more user-friendly syntax A full list of noteworthy new features is given in: http://lilypond.org/doc/v2.18/Documentation/changes/index.html Great thanks go to the large number of LilyPond enthusiasts whose financial backing enabled one core developer, David Kastrup, to focus exclusively on LilyPond during the entire development cycle. LilyPond 2.18 has been brought to you by Main Developers: Bertrand Bordage, Trevor Daniels, Colin Hall, Phil Holmes, Ian Hulin, Reinhold Kainhofer, David Kastrup, Jonathan Kulp, Werner Lemberg, John Mandereau, Patrick McCarty, Joe Neeman, Han-Wen Nienhuys, Jan Nieuwenhuizen, Graham Percival, Mark Polesky, Neil Puttock, Mike Solomon, Carl Sorensen, Francisco Vila, Valentin Villenave, Janek Warchol Core Contributors: Aleksandr Andreev, Frédéric Bron, Torsten Hämmerle, Marc Hohl, James Lowe, Andrew Main, Thomas Morley, David Nalesnik, Keith OHara, Benko Pál, Anders Pilegaard, Julien Rioux, Johannes Rohrer, Adam Spiers, Heikki Tauriainen Documentation Writers: Frédéric Bron, Federico Bruni, Colin Campbell, Urs Liska, James Lowe, Thomas Morley, Jean-Charles Malahieude, Guy Stalnaker, Martin Tarenskeen, Arnold Theresius, Rodolfo Zitellini Bug Squad: Colin Campbell, Eluze, Marc Hohl, Phil Holmes, Marek Klein, Ralph Palmer Support Team: Colin Campbell, Eluze, Marc Hohl, Marek Klein, Kieren MacMillan, Urs Liska, Ralph Palmer Translators: Federico Bruni, Luca Rossetto Casel, Felipe Castro, Pavel Fric, Jean-Charles Malahieude, Till Paala, Yoshiki Sawada and numerous other contributors. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cleanup of ugly MI and SOL shaped noteheads (issue 45160043)
On 2013/12/24 23:22:00, Carl P. wrote: This may well need to happen. As I said, I've tried a few times over the last 8 or 9 months to inquire about the mi head particulary, with no response. If you're the only person on the lists who cares, then you should be able to have it the way you want it. I'm curious, though, about the usage in chords. In particular, it seems that chords in Walker notes can't possibly line up, since do is centered on the stem. Are chords commonly used in shape notes? Every reference I've seen has no chords -- only single notes. I'm fine to have this pushed if nobody else objects. But I do like David K.'s suggestion of a message on -user with before and after shapes. Thanks, Carl S. https://codereview.appspot.com/45160043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
Hi, 2013/12/12 Graham Percival gra...@percival-music.ca: On Wed, Dec 11, 2013 at 01:48:54PM +0100, Janek Warchoł wrote: PS ccing to Graham because he might be interested to know that Someone(TM) is doing Something(TM) to help new contributors! Sorry, this awoke Grumpy Graham. I should have expected that. Quite frankly, when i read your reply 3 weeks ago, i got irritated, but fortunately i didn't have time to answer ;-) and now - after calming down - i have to admit that you make some good points. My proposal was not good enough (and i certainly failed to express myself clearly, because it seems you had slightly misunderstood me). Anyway, there are two parts to this cg cleanup: 1) removing obsolete info 2) reorganizing things. 1) is a no-brainer, and i'll do it now (and push after patchy confirms it isn't broken). 2) will have to wait till i have more time (summer?). After a good deal of thinking, here's how i think CG should be structured. More thinking and discussion than we had the previous 4 times we reorganized the CG? Quite frankly, i'm pretty sure that i gave CG more thought than all of us combined since Waltrop 2012 ;-) Also, times change and stuff like CG gets out of date - even if it was ok after previous reorganization, it doesn't mean that a new reorganization isn't warranted, don't you think? Anyway, guess what? +1 for Graham! :-) cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cleanup of ugly MI and SOL shaped noteheads (issue 45160043)
On Tue, Dec 31, 2013 at 12:29 PM, carl.d.soren...@gmail.com wrote: On 2013/12/24 23:22:00, Carl P. wrote: This may well need to happen. As I said, I've tried a few times over the last 8 or 9 months to inquire about the mi head particulary, with no response. If you're the only person on the lists who cares, then you should be able to have it the way you want it. I'm curious, though, about the usage in chords. In particular, it seems that chords in Walker notes can't possibly line up, since do is centered on the stem. Are chords commonly used in shape notes? Every reference I've seen has no chords -- only single notes. Depending upon the style sheet, shaped notes have varying usage in chords. Even in single-note formats (Sacred Harp, Southern Harmony, etc.), there are examples of two notes being given for one part (optional octaves or providing a second note to complete the chord, typically SOL). For my own work, notes are nearly always written in chords, unless the notes are less than a third apart or there is a difference in rhythm. LilyPond's implementation of chords with Walker is to center the stem if the notehead nearest the stem is DO or to act normally otherwise. I'm fine to have this pushed if nobody else objects. But I do like David K.'s suggestion of a message on -user with before and after shapes. I have sample PDFs I generated showing before and after, both singly and in chords. I haven't yet had time to convert/compress those examples to smaller file sizes for sending to -user, but hope to in the next couple of days. In the meantime, I'll probably take the patch off the countdown. Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Guile 2 support
Fantastic work everyone with getting version 2.18 out of the door. When I saw the release notice, I immediately wanted to update the Homebrew formula (Homebrew is a package manager for Mac OS X). However, I was told by the maintainers that an update would not be accepted, unless Lilypond would compile with the default Guile which is currently 2.0.9. I know that there have been plans of bumping to Guile 2 for a long time now. Is this something that is planned for the next release? If not, that's fine too, I'm just curious. All the best -- Sven Axelsson ++[+ -].+..+.+.-.+... +++.-.++..++.++.... ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guile 2 support
Sven Axelsson sven.axels...@gmail.com writes: Fantastic work everyone with getting version 2.18 out of the door. When I saw the release notice, I immediately wanted to update the Homebrew formula (Homebrew is a package manager for Mac OS X). However, I was told by the maintainers that an update would not be accepted, unless Lilypond would compile with the default Guile which is currently 2.0.9. Where is the point in not allowing an upgrade from one version requiring GUILE 1 to another one requiring GUILE 1? I know that there have been plans of bumping to Guile 2 for a long time now. Is this something that is planned for the next release? Oh, definitely. It's not like it wasn't planned for 2.16 and 2.14. But somebody has to do the heavy lifting. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guile 2 support
On 12/31/13 4:30 PM, David Kastrup d...@gnu.org wrote: Sven Axelsson sven.axels...@gmail.com writes: Fantastic work everyone with getting version 2.18 out of the door. When I saw the release notice, I immediately wanted to update the Homebrew formula (Homebrew is a package manager for Mac OS X). However, I was told by the maintainers that an update would not be accepted, unless Lilypond would compile with the default Guile which is currently 2.0.9. Where is the point in not allowing an upgrade from one version requiring GUILE 1 to another one requiring GUILE 1? I think the Homebrew forumula actually doesn't work that well (at least, I couldn't make it work) because Homebrew wants to have Guile 2.0, not 1.8. But I haven't spent the time to really follow it through. I know that there have been plans of bumping to Guile 2 for a long time now. Is this something that is planned for the next release? Oh, definitely. It's not like it wasn't planned for 2.16 and 2.14. But somebody has to do the heavy lifting. Is there someplace you know that describes the current status of 2.0 migration? A search on the google tracker for Guile 2.0 shows up issues 3364, 1826, 1780, and 1055. I also found issue 2026. Issues 2026 and 1780 show up as abandoned. Issue 1055 has nothing happening since February 2011. Issue 3364 will supposedly not be a problem once we use Guile 2.0. Issue 1686 claims to have fixed the guile compilation problem with Guile 2.0 What yet remains to be able to run lilypond with Guile 2.0? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guile 2 support
On 1 January 2014 00:30, David Kastrup d...@gnu.org wrote: Sven Axelsson sven.axels...@gmail.com writes: Fantastic work everyone with getting version 2.18 out of the door. When I saw the release notice, I immediately wanted to update the Homebrew formula (Homebrew is a package manager for Mac OS X). However, I was told by the maintainers that an update would not be accepted, unless Lilypond would compile with the default Guile which is currently 2.0.9. Where is the point in not allowing an upgrade from one version requiring GUILE 1 to another one requiring GUILE 1? Good question. They have probably gotten stricter regarding there dependency policies. Or maybe this particular maintainer just had a bad day. Except for the Guile dependency, which is easily solvable, the Homebrew formula works just fine. I know that there have been plans of bumping to Guile 2 for a long time now. Is this something that is planned for the next release? Oh, definitely. It's not like it wasn't planned for 2.16 and 2.14. But somebody has to do the heavy lifting. Of course. Any idea how heavy this lifting would be? I guess a thorough understanding of the Lilypond code base is needed, so it requires a real athlete. But if a mere weakling such as myself can do anything to help, I'd be more than willing. ☺ Happy new year everybody! -- Sven Axelsson ++[+ -].+..+.+.-.+... +++.-.++..++.++.... ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guile 2 support
David Kastrup: Sven Axelsson sven.axels...@gmail.com writes: ... I know that there have been plans of bumping to Guile 2 for a long time now. Is this something that is planned for the next release? Oh, definitely. It's not like it wasn't planned for 2.16 and 2.14. But somebody has to do the heavy lifting. There don't seem to be many guides how to do the upgrade 1.8 - 2.0, the only thing I found was the 1990 first lines of: http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=NEWS;h=b53386a0bcfa3e67acf5f63e501ccf84c8242557;hb=958a28e9fec33ebb4673294308a82ccd18cc6071 and the problems reported by: http://code.google.com/p/lilypond/issues/list?can=2q=guile+2.0colspec=ID+Type+Status+Stars+Owner+Patch+Needs+Summarycells=tiles from which I get the picture that 1.8 and 2.0 is basically the same but 2.0 have a stricter adherence to R5RS and it also have a byte compiler which makes lazy binding troublesome. /// Peter Brett has a guide how to work with mult. guile versions: http://blog.peter-b.co.uk/2011/06/geda-and-guile-compiling-against.html Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Swap 'polite' and 'l2r' variable definitions (issue 42000044)
The old variable definitions followed the corresponding words in the options. I see the bug in the old code, so left-to-right did not behave symmetrically to right-to-left. If the actual behavior fits the chosen options with your change, then good enough. https://codereview.appspot.com/4244/diff/1/lily/axis-group-interface.cc File lily/axis-group-interface.cc (left): https://codereview.appspot.com/4244/diff/1/lily/axis-group-interface.cc#oldcode739 lily/axis-group-interface.cc:739: || (directive == ly_symbol2scm (left-to-right-polite))); The original l2r meant that one of the two left-to-right-* options was chosen. Below, it means the objects closer to the left end of a line are placed before those further right, so the items on the left tend to go closer to the staff when there are overlaps. https://codereview.appspot.com/4244/diff/1/lily/axis-group-interface.cc#oldcode790 lily/axis-group-interface.cc:790: if (x_extent[LEFT] = last_end[dir] polite) The old polite meant that if we are about to place an object that would overlap one just placed, ask this object wait politely until we first to place all objects that fit without overlap. Placing each object on the first pass was called greedy. (The old logic here was not quite right, because if we are placing from right to left -- the old 'ltr==false' -- then the test for overlap concerns the x_extent[RIGHT] of the object we are about to place. It should have been x_extent[ltr?LEFT:RIGHT] and the converse below. As it is, the loop is quadratic, but does not hurt too badly because it handles objects in just one after-breaking line.) https://codereview.appspot.com/4244/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
CG: basic cleanup (issue 46120044)
looks fine https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/source-code.itexi File Documentation/contributor/source-code.itexi (left): https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/source-code.itexi#oldcode729 Documentation/contributor/source-code.itexi:729: @end example I have often looked in Downloading Individual Branches hoping to find the command to download a new branch (such as dev/janek/spacing or release/2.18) that has appeared on the repository. This seems to be the only such example of that command, so maybe keep just this example in this section. https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/source-code.itexi#oldcode2162 Documentation/contributor/source-code.itexi:2162: Git works under Windows (I used it successfully for some documentation patches before getting around to installing Linux). You might want to keep the text down to here, as a pointer for one option that new contributors might want to consider. https://codereview.appspot.com/46120044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG: basic cleanup (issue 46120044)
LGTM
https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/source-code.itexi
File Documentation/contributor/source-code.itexi (left):
https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/source-code.itexi#oldcode729
Documentation/contributor/source-code.itexi:729: @end example
On 2014/01/01 05:44:44, Keith wrote:
I have often looked in Downloading Individual Branches hoping to
find the
command to download a new branch (such as dev/janek/spacing or
release/2.18)
that has appeared on the repository.
As far as I understand, as long as you began with a git clone (which we
started recommending 1 or 2 years ago, for this reason), you
automatically download the branches. To see the actual files on your
computer, you just need to checkout the new branch.
(the whole downloading individual branches thing arose because in 2005
or so, I wasn't familiar with git and was paranoid about wasting my
bandwidth. No joke, I read slashdot using lynx back then to avoid
loading images)
If that info is correct, the CG should be changed so that it contains
and is easy to find that info.
https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/source-code.itexi
File Documentation/contributor/source-code.itexi (right):
https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/source-code.itexi#newcode123
Documentation/contributor/source-code.itexi:123: command-line version of
Git 1.7 or higher.}
just curious, what changed in git 1.5 vs. 1.7 that's important to these
instructions?
https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/source-code.itexi#newcode1390
Documentation/contributor/source-code.itexi:1390: @emph{How to resolve
conflicts} in @command{git merge} man page.
I think this is likely to confuse / discourage most new contributors,
but it's certainly an improvement on the previous this is a stub
material.
https://codereview.appspot.com/46120044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
On Tue, Dec 31, 2013 at 06:35:36PM +0100, Janek Warchoł wrote: 2013/12/12 Graham Percival gra...@percival-music.ca: Sorry, this awoke Grumpy Graham. I should have expected that. Yes, you should have. :P Happy new year, BTW. Anyway, there are two parts to this cg cleanup: 1) removing obsolete info 2) reorganizing things. Not quite. 1) is obvious, but equally important is 1.5) update incorrect info. Remember this latest iteration of interest in the CG happened because one or two new contributors tried to follow the published (incorrect) info, got into trouble, and understandably were irritated. Reorganizing is a seductively easy thing to propose, but it's dangerous. It's easy to have opinions about how things should be structured, so it's a huge bike-shed debate. Any proposal to change the chapters and sections in the CG will involve at least two weeks of debate on -devel. Can you honestly say that another argument like that would not reduce your motivation? It would be a shame if a bunch of good suggestions got lost (or delayed by a few months) because they were wrapped up in a reorganization patch. Just look at the proposed website changes from a week or two ago. As an added bonus, if you make dozens of obviously good updates to the CG over weeks and months, then people will gradually recognize you as an authority on the subject. Then if/when you propose some reorganizations, they'll be less skeptical. More thinking and discussion than we had the previous 4 times we reorganized the CG? Quite frankly, i'm pretty sure that i gave CG more thought than all of us combined since Waltrop 2012 ;-) and before Waltrop, I spent 100x more timeeffort on the CG than you did. Your point? Also, times change and stuff like CG gets out of date - even if it was ok after previous reorganization, it doesn't mean that a new reorganization isn't warranted, don't you think? Not really. We still have contributors who need encouragement and an overview of development. We still (I think) have lilydev, and that's still (I think) no easier way to get started. We still have documentation, a website, programming in C++ and scheme, etc. Granted, the previous plans about having mentors fell apart, so those parts of the CG should be removed. But other than that, I think a reorganization would mostly be a distraction away from fixing incorrect info. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
