Re: Google Code shutting down
David Kastrup wrote Monday, May 04, 2015 11:30 AM Anyone evaluated/tested/whatever Kallithea? URL:https://kallithea-scm.org/. It seems aligned to the Software Freedom Convervancy, so maybe we could get Savannah to support it if it does the job. Kallithea doesn't seem to have a native issue tracker, which is the feature we're about to lose. They use BitBucket for their own issue tracker. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Google Code shutting down
Federico Bruni wrote Monday, May 04, 2015 2:53 PM Interesting! https://forge-allura.apache.org/p/allura/wiki/Features/ I think that the main alternatives are Launchpad (Affero GPL) and Apache Allura (Apache License). Launchpad provides also the hosting, while Allura should be deployed on Savannah. Both are free software so we can move where we wish and avoid any 3rd party trap. Allura is the engine used by SourceForge. There's quite a lot of information there, including the APIs. Here's the tracker API. http://sourceforge.net/p/forge/documentation/Allura%20API/#tracker It seems it accepts attachments, but I don't know if there is a means of displaying these in the tracker. The trackers are also configurable: http://sourceforge.net/p/forge/documentation/Tickets/ And we are eligible to use sourceforce, I believe, so this looks worthy of a closer look. For example, it's not clear how we would transfer out existing issue DB, but a custom script using the API should be able to do that. Ah, wait .. sourceforce have an importer from GoogleCode. I had to register to see it, but that's easy. After that, it's here https://sourceforge.net/p/import_project/google-code/ It says it will import Wiki pages, source code (SVN, Git or Hg), Downloads, and Issues. Before I try it, are there any objections or gotchas? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Google Code shutting down
David Kastrup wrote Monday, May 04, 2015 5:21 PM Wasn't Savannah's main system Savane a fork of SourceForge's proprietary software version? Anybody have more of a clue about the relations between the various versions and what that might mean for our chances of getting this system adopted by Savannah? It seems SourceForge adopted Allura around 2011/2012. One of their news items, dated 19 Jun 2012, says, Also, our new Allura platform has many core features ... If we have a really viable migration path out of non-Savannah hosting, it seems like putting our eggs not in too many outsourced baskets might save us from some future headaches like the Google code one. Not sure Allura itself includes the data migration tool. It has a GoogleCode Wiki importer as an add-on, but I can see nothing else. I suspect the full importer is a SourceForge app. Even so, Allura looks the best bet so far. Not least because SourceForge must have knocked out most of the bugs by now. We just need an OS host. Allura give a list of deployments, but it's pretty short: https://forge-allura.apache.org/p/allura/wiki/Allura%20Deployments/ None seems suitable for LP. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Google Code shutting down
Carl Sorensen I'm fine if we can get everything on Savannah, but it seems to me that in the past, there was a feeling that Savane's bug tracking was significantly inferior to Google Code. I don't know, because I never used it. Just as a reminder, we had a very helpful interchange with the Savannah devs 6 weeks ago: http://lists.gnu.org/archive/html/lilypond-devel/2015-03/msg00143.html They extracted all our issue data from GoogleCode and provided it as a static html page. Not what is needed of course, but they were responsive and helpful. But then they asked for some help with their php code to take it further, and when no one stepped up the discussion stopped. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Google Code shutting down
Trevor Daniels wrote Monday, May 04, 2015 10:01 PM OK, I've created a project on SourceForge and started downloading the issues DB from GoogleCode. [snip] You can see the progress here: https://sourceforge.net/p/testlilyissues/tickets/ Update: (one ladder, two snakes) 1. I now see that some attachments, viz .png's and jpg's at lease, are imported and displayed :-) It seems they are imported asynchronously, as those for Issue 1313 are now present. 2. I've just received an email saying the import has failed. No reason given. :-( I'll check with the SF Engineering Team, as they are called. 3. James has just reported a 403 error on the url. AFAICS any user, even those not logged in, should have read access, so I'm mystified ATM. I'll keep looking. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Google Code shutting down
Carl Sorensen wrote Monday, May 04, 2015 8:40 PM So perhaps it would be a good idea to test Allura on SourceForge, and see if we like it. If we do, then we could let the Savannah people know, and maybe they'd be willing to use it as their issue tracker. OK, I've created a project on SourceForge and started downloading the issues DB from GoogleCode. First, it's gonna be slow - 70 in first 20 minutes, ~200 in first hour. Second, jpeg attachments are displayed (see issue 1313, where I manually added one of the originals, but they are not imported from GoogleCode.) Here's more of what I see so far: Copied OK Issue number and Title Status (but doesn't seem to figure in searches until issue is edited ??) Discussion (but not ref numbers - there is a link field, though, for future reference) Stars - Up votes Not copied Labels (some are, needs more investigation) Owner Blocking Attachments (when we exported before we had to extract the attachments separately, so this is a GoogleCode limitation. However, there isn't even a marker, so there's no way the attachments could be added later.) You can see the progress here: https://sourceforge.net/p/testlilyissues/tickets/ Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Is GridLY the future?
Janek Warchoł wrote Sunday, May 03, 2015 12:53 AM The behaviour that discouraged me from working on LilyPond for some time was not obviously unacceptable (i.e. it wasn't some ad hominem attack, nor anything else unanimously condemned by others). Rather, it was the general attitude of some people who sometimes seem to oppose changes only because they personally don't like them (or think they're not important), without even suggesting reasonable alternatives. Hi Janek I think quite a high proportion of the LP developer community have gone through this at some stage, often more than once ;-) It's hard when others oppose one's cherished opinions - I know from experience! But that's how open source works - the community is judge and jury. Often it seems that just one individual is opposing you, rather than the community, but that's often because silence is the way of indicating satisfaction with the way the discussion or indeed the proposal is going. We don't want the list flooded with +1's. Anyway, many of us have returned (in my personal case more understanding and wiser, I hope) so welcome back! We missed you! Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Just some short feedback
I'd like to second everything that Carl writes below, and add my thanks to you, David. Trevor Carl Sorensen wrote Monday, April 27, 2015 11:07 PM On 4/27/15 3:09 AM, David Kastrup d...@gnu.org wrote: As things currently stand, I suspect that the current mechanism for creating Scheme engravers with their own variables (namely providing a function creating an engraver description) does not have likable performance characteristics and, more importantly, does not really work reasonably at all with regard to registering Scheme engravers like C++ engravers so that they can be called by name and documented in the same manner. I'm totally supportive of developing a way to register Scheme engravers so they can be documented and be full members of the LilyPond family. I'll probably come up with something GOOPS-related eventually and the closure mechanism for creating Scheme engravers will be deprecated. At any rate, I am starting over _again_ but I think that I am now at the stage where my plan of execution is nicely streamlined and Listeners from both C++ and Scheme level (as well as their creation from the bowels of the respective engraver types) are quite straightforward to deploy and debug and don't rely on all the C level macro hackery. That sounds like a great thing. Like so much of your work, it makes a huge difference in maintainability and future development. Maybe not so much difference in the current function (perhaps none at all), but a huge difference in going forward. We are so fortunate to have you working on this kind of thing. So in short, I've been tending the most important resource a good programmer should have in his possession: the wastebasket. And I expect people to ultimately be glad about all the code I have thrown away once I get to throwing away the current code we work with. I'm looking forward to having you throw away some code and replace it with much more easily-maintained and -extended code. Thanks for your hard work! Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [wish] Remove \skip duration in Lyrics
Abraham Lee wrote Monday, April 27, 2015 5:39 PM
I've seen lately a handful of users using (and suggesting to others) the
single underscore _ syntax to skip syllables in lyrics instead of \skip
X, which I think is a mistake when it's obvious they did not intend to
make a melisma. It works, except the lyrics get left-aligned to the first
note.
Yes. I've actually not seen many recently, and the manuals advise against it,
for the reason you give.
I am wondering if anyone has a better suggestion for a pure skipped
syllable to replace \skip X since the duration X doesn't matter at all.
It's easy enough to create a replacement macro like:
I usually suggest using , if just one or two syllables are involved.
OR, it could use the number to say *how many syllables to skip* instead of
a duration. I'm thinking about the instances where I've seen (and used)
something like:
skipFour = \repeat unfold 4 { \skip 4 }
For longer durations I know of no alternative. What you suggest seems
sensible in a Lyrics context, but it would break backwards compatibility.
And it has been suggested before:
https://code.google.com/p/lilypond/issues/detail?id=1330
Trevor
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES: Countdown for April 6th 2015
James Lowe wrote Saturday, April 04, 2015 9:27 AM On 04/04/15 08:49, David Kastrup wrote: If we freeze patches only on countdown state and nothing else I hope not to curb the holiday rush of activity too much. Would people be ok with that? If not, I'll try to compile a shortlist of patches I'd like to see delayed this evening in order to give them proper attention and let the rest pass normally. What I can do, so as to not put of people submitting patches in the meantime, is to continue test/review/countdown and just not go through to the push stage until the 8th (Wednesday) review. So things sit on 'countdown' until then. Thanks James, I agree with doing that. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New page on website
Urs Liska wrote Saturday, April 04, 2015 3:03 PM I would like to add a companion page to examples.html on lilypond.org (in theory extending the existing page would be good too, but that would definitely become too long, I think). This page would show a number of idiomatic engravings using a selected range of the new alternative fonts, which I'm collecting right now. We *do* offer that feature now, so it should be quite prominently visible, as it is something that potential (and of course existing) users will find interesting. But before I put significant effort in this I'd like to get an idea if that would encounter significant headwind. Just encouragement from me; sounds a sensible enhancement. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Generating music from a list of identifiers
Hi Schemers I'm struggling to find how to do the following: I have a list of the identifiers of variables which contain either music or #f and I'd like to generate the parallel music of all of them which contain music. I can do this by listing the identifiers explicitly, like this: AllMusic = #(if DescantMusic DescantMusic) #(if SopranoMusic SopranoMusic) ... #(if PianoLHMusic PianoLHMusic) But I'd like to do the same thing without listing each one explicitly, using a list like this, which is generated algorithmically: #(define AllMusicNames (list DescantMusic SopranoMusic ... PianoLHMusic)) TIA Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Generating music from a list of identifiers
Thanks Jan-Peter That's put me back on course! Trevor - Original Message - From: Jan-Peter Voigt jp.vo...@gmx.de To: lilypond-devel@gnu.org Sent: Wednesday, April 01, 2015 12:45 PM Subject: Re: Generating music from a list of identifiers Hi Trevor, I compiled a short example, that should give you some hints. HTH Jan-Peter Am 01.04.2015 um 13:18 schrieb Trevor Daniels: Hi Schemers I'm struggling to find how to do the following: I have a list of the identifiers of variables which contain either music or #f and I'd like to generate the parallel music of all of them which contain music. I can do this by listing the identifiers explicitly, like this: AllMusic = #(if DescantMusic DescantMusic) #(if SopranoMusic SopranoMusic) ... #(if PianoLHMusic PianoLHMusic) But I'd like to do the same thing without listing each one explicitly, using a list like this, which is generated algorithmically: #(define AllMusicNames (list DescantMusic SopranoMusic ... PianoLHMusic)) TIA Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Generating music from a list of identifiers
David Kastrup wrote Wednesday, April 01, 2015 8:36 PM Trevor Daniels t.dani...@treda.co.uk writes: I'm struggling to find how to do the following: I have a list of the identifiers of variables which contain either music or #f and I'd like to generate the parallel music of all of them which contain music. I can do this by listing the identifiers explicitly, like this: AllMusic = #(if DescantMusic DescantMusic) #(if SopranoMusic SopranoMusic) ... #(if PianoLHMusic PianoLHMusic) But I'd like to do the same thing without listing each one explicitly, using a list like this, which is generated algorithmically: #(define AllMusicNames (list DescantMusic SopranoMusic ... PianoLHMusic)) Untested: #(simultaneous-music (filter ly:music? (map (lambda (x) (ly:parser-lookup parser x)) (map string-symbol AllMusicNames Thanks David. I must be gaining some small facility with Scheme now, as I can understand this immediately and appreciate its elegance! It was using simultaneous-music that was escaping me, so thanks to you (and Jan-Peter) for pointing that out to me. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Building identifiers algorithmically
LilyPond Schemers,
I'm gradually getting the hang of Scheme, but I'd like some help with one
frustrating issue. I'd like to build an identifier from two strings and use it
to reference a LilyPond variable.
In other words, I have several Lily variables defined like this
SopranoMusic = \relative { ... }
and I'd like to reference them from Scheme code using the strings Soprano and
Music. The only way I've found is to build an alist of all of them using
#(set! index (assoc-set! index SopranoMusic SopranoMusic))
and then retrieve the music with
#(define music (assoc-ref index (string-append Soprano Music)))
(In my real-use case of course some of the strings are variables.)
Now while this works it seems rather clunky, so I'm wondering if there is a
more elegant way of doing this. Symbols look like they might help, but so far
I've failed to make anything work. I've also failed with macros, but that's
likely because I don't understand them yet.
TIA, Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building identifiers algorithmically
Thanks Urs, that what I needed!
Trevor
- Original Message -
From: Urs Liska u...@openlilylib.org
To: lilypond-devel@gnu.org
Sent: Saturday, March 21, 2015 10:44 PM
Subject: Re: Building identifiers algorithmically
Hi Trevor,
hey, that's what I just learned :-)
What you need is (ly:parser-lookup parser 'SopranoMusic) inside a music
function.
Then create the 'SopranoMusic symbol from two strings and you're good to go.
\version 2.19.18
SopranoMusic = {
c' d'
}
getMusic =
#(define-music-function (parser location label1 label2)
(string? string?)
(ly:parser-lookup parser
(string-symbol
(string-append label1 label2
\score {
\new Staff \getMusic Soprano Music
}
HTH
Urs
Am 21.03.2015 um 23:29 schrieb Trevor Daniels:
LilyPond Schemers,
I'm gradually getting the hang of Scheme, but I'd like some help with one
frustrating issue. I'd like to build an identifier from two strings and use
it to reference a LilyPond variable.
In other words, I have several Lily variables defined like this
SopranoMusic = \relative { ... }
and I'd like to reference them from Scheme code using the strings Soprano
and Music. The only way I've found is to build an alist of all of them
using
#(set! index (assoc-set! index SopranoMusic SopranoMusic))
and then retrieve the music with
#(define music (assoc-ref index (string-append Soprano Music)))
(In my real-use case of course some of the strings are variables.)
Now while this works it seems rather clunky, so I'm wondering if there is a
more elegant way of doing this. Symbols look like they might help, but so
far I've failed to make anything work. I've also failed with macros, but
that's likely because I don't understand them yet.
TIA, Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Google Code shutting down
Federico Bruni ha scritto Monday, March 16, 2015 8:01 AM Subject: Re: Google Code shutting down I had much better experience with Redmine (Ruby on Rails). You can see an example here: http://darktable.org/redmine/projects/darktable Redmine looks rather overkill for our purposes, comprehensive and impressive as it is. http://www.redmine.org/projects/redmine/wiki Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Attachment downloader?
Assaf, you wrote Sunday, March 15, 2015 3:53 AM On 03/14/2015 01:57 PM, Trevor Daniels wrote: I confirm this works, at least for the one instance I tried. I guess now we need to write a script which parses the JSON file to find the attachment parameters and then to wget them using the assembled url. I think I understand now what type information is available form google-code, now I'll need to go look into the savannah code. If I understand correctly, the timeline allows projects to keep using google-code issues until August 2015, at which point it will be come read-only? Correct This doesn't leave us a lot of time (especially that there aren't many volunteers working on savannah code...). I'll try to work on it (among all the other things), but it will be good to also look at fall-back options. if you do examine some other known bug-trackers solutions, would you mind sharing your options with savannah people? In my opinion, especially following the recent experience of Google, we should move to an open-source system. There are few others apart from Savannah (Gerrit is one) but I'm not aware that anyone in the LilyPond project is exploring any of them at present. As our source code is based at Savannah that seems an obvious place to keep our issues DB, but the decision will be on how well our needs and desires can be accommodated. Your response means we're off to a good start! As a side note, to better understand the exported JSON format, I wrote a small script which generate a static HTML from the JSON and also download the attachments - producing a static local copy. It's ugly but it (mostly) works. If you're interested, you can see the results here: http://gcissues.housegordon.org/p/lilypond/ Or download all the files here: http://gcissues.housegordon.org/ This is excellent progress! Thanks for taking the trouble to do this. We can now confidently assume all the data and all the images can be extracted, at least in a usable read-only form. I see the size of the tarball of the issues DB is 111Mb. Not sure how big the DB would be when extracted, but it will be large compared to a text-only issues DB. Would the size be a problem for Savannah? if there are LilyPond developers willing to help with hacking the savannah php code, please send an email to savannah-hackers-pub...@gnu.org and we'll continue the discussion there. I'm not really a hacker (my main contribution is LilyPond documentation), so I'm hoping some of the others on the LilyPond developers list will pick up on this. There is a lot to do to either tailor the Savannah interface to accommodate our established scripts and workflow, or develop a new one based on the Savannah facilities. To what extent are the various fields in the Savannah issues interface tailorable on a project-specific basis? I explored the website for details, but failed to find any. Perhaps I looked in the wrong places. Thanks again for your help! Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Attachment downloader?
Thanks Han-Wen and Chris I confirm this works, at least for the one instance I tried. I guess now we need to write a script which parses the JSON file to find the attachment parameters and then to wget them using the assembled url. Good; it's work, but at least there is a means now to extract all our issues data. Where we put it is another matter. Thanks again, Trevor Han-Wen Nienhuys hanw...@gmail.com To: lilypond-devel lilypond-devel@gnu.org Sent: Saturday, March 14, 2015 5:30 PM Subject: Fwd: Attachment downloader? -- Forwarded message -- From: Chris Smith chrsm...@google.com Date: Sat, Mar 14, 2015 at 3:46 PM Subject: Re: Attachment downloader? To: Han-Wen Nienhuys han...@google.com Cc: google-code-shutdown google-code-shutd...@google.com Hello, We do not have an automated issue attachment downloader, however we do mirror public issue attachments in Google Cloud Storage. You can get an attachment (without needing the token from code.google.com) using a URL like follows: http://storage.googleapis.com/google-code-attachments/issue-export-test/issue-4/comment-1/misc_file2.txt That is: http://storage.googleapis.com/google-code-attachments; + / + project_name + /issue- + issue_number + /comment- + comment_number + / + file_name Cheers, -Chris On Sat, Mar 14, 2015 at 5:09 AM, Han-Wen Nienhuys han...@google.com wrote: Hi there, the issue export tool doesn't seem to download issue attachments, see http://lists.gnu.org/archive/html/lilypond-devel/2015-03/msg00126.html is that a missing feature, or is there some other tool to do it? I wrote some instructions for the project how to do this semi-manually, but it would be nice if there were a little tool. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Generating variable containing spacer rests
Hi Not being very experienced in Scheme I'm struggling to create a variable containing a spacer rest or rests with a total musical length equal to the music contained in another variable. Can anyone help? TIA Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Generating variable containing spacer rests
David Kastrup wrote Saturday, March 14, 2015 6:14 PM Trevor Daniels t.dani...@treda.co.uk writes: Not being very experienced in Scheme I'm struggling to create a variable containing a spacer rest or rests with a total musical length equal to the music contained in another variable. Can anyone help? #(define newvar (skip-of-length oldvar)) Thanks David, I'm hoping that might provide a stop-gap solution to the satb.ly in release 2.19.16 problem. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Google Code shutting down
David Kastrup wrote Friday, March 13, 2015 11:51 AM Subject: Re: Fwd: Google Code shutting down Graham Percival gra...@percival-music.ca writes: In addition to moving the issues, the issue handling scripts would need to be updated. Things like git-cl, patchy, and the whole patch-submission system. That will be a non-trivial effort. You bet. It would appear like Rietveld will stick around for longer, but of course moving away from this Subversion-centric piece of our infrastructure would also make sense. But at least we have a different time frame for that. AFAIK the issues database and associated comments are the only part of Google Code that we, the LilyPond community, use. It is vital we don't lose this. Two questions: (a) how do we take a copy of this data base to keep it safe, including all the follow-up discussions? Making a CSV copy just seems to download the index. (b) Is Google Code open-source or proprietary? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Google Code shutting down
Han-Wen, you wrote Friday, March 13, 2015 1:45 PM
On Fri, Mar 13, 2015 at 1:37 PM, Trevor Daniels t.dani...@treda.co.uk wrote:
Two questions:
(a) how do we take a copy of this data base to keep it safe,
including all the follow-up discussions? Making a CSV
copy just seems to download the index.
have a look at
https://code.google.com/p/support-tools/wiki/IssueExporterTool
That is quite useful, thanks. I've exported the LilyPond Issues
DB to a JSON file on my laptop. 5Mb. It seems complete as far
as the text goes, but images do not seem to be included, as least
for the one issue I've inspected in detail (Issue 4005). All
the JSON file says for the image is:
attachments : [ {
attachmentId : 40050007000,
fileName : Screenshot.png,
fileSize : 137527,
mimetype : image/png
} ]
but I don't see any attachments anywhere in the download.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feedback request: website home page revision
Paul Morris wrote Sunday, March 01, 2015 7:00 PM Based on the feedback so far (from two people, thanks Kevin and Joram!) I have combined aspects from the previous proposals into two new ones. (Don't forget to remove the space in the URL.) 3F. http://clairnote.org /lilypond-web-demo3/index3F.html 3G. http://clairnote.org /lilypond-web-demo3/index3G.html Let me know what you think. (My preference is 3G, so unless I get significant feedback against it and/or for 3F instead, I will plan on turning 3G into a patch after this Wednesday March 4.) I'm happy to go with 3G too. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Some more possible tweaks to the appearance of the website
Hi Paul I'd be happy to go along with your index3C version, as linked below, but I'd like to see comments from others before the changes are adopted. These preferences can be very dependent on the individual's artistic sense. Trevor - Original Message - Paul Morris wrote Friday, February 20, 2015 7:07 AM I couldn't resist... I have another mock-up to share. Curious to hear what you and others think: http://clairnote.org /lilypond-web-demo3/index3B.html As you suggested this one has smaller text and the separate read more bit (as on the current site). It also puts the news items into boxes that are like those used on the rest of the site, which I think works well for them. This also frames the main focal area well and helps the page not look as stark and text-heavy. Here's another version where the only difference is that pondings and quick links are switched: http://clairnote.org /lilypond-web-demo3/index3C.html The advantage is that quick links always has a fixed height, while pondings does not. So this has a more compact ragged-bottom sidebar (rather than ragged-middle). P.S. previous version is still here for comparison: http://clairnote.org /lilypond-web-demo3/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Some more possible tweaks to the appearance of the website
Paul Morris Wednesday, February 18, 2015 6:43 AM I have some more changes to propose for the website. You can see two mock-ups at the links below (just remove the spaces in the URLs). One uses the current green color for the background, and in the other I tried out a blue background which offers more contrast. Individually comments below. Most I like, but a couple I don't. Thanks for doing this - I'm well aware of the effort involved and the difficulties of achieving good artistic design (usually by my failing!) Trevor 3. current green background color: http://clairnote.org /lilypond-web-demo3/ 4. blue background color: http://clairnote.org /lilypond-web-demo4/ Definitely more contrast, but also definitely not an improvement. Below is a list of the main changes. Let me know what you think and if you like one version better than the other. SITE BACKGROUND - The background color that fades in at the top left corner also fades in at the top right. This complements the horizontally centered site design and provides greater symmetry (especially noticeable on wider monitors where the background color falls more outside of the main content area than behind it). Like - Rather than the background color fading to pure white and the boxes that contain the site’s content having a slightly off-white background (as on the current site), the background fades to off-white and the content boxes are pure white. This way the foreground/content is slightly brighter than the background, which helps the eye focus on the content. Like HOME PAGE - Simplified by removing two graphical elements — the “squiggle” and the “What is LilyPond?” green bar that fades out horizontally — both of which are unlike any other visual elements on the site and so they don’t “tie in” well with the overall design. (IMHO they don’t add much and actually distract from the nice big image with the lily and music notation. They both had pure white backgrounds, so that’s why I’m proposing this change to go with the background changes.) Don't like. The new apearance is cleaner, but also, I think, too stark. I also rather liked the separated text and link to read more. It looks far more inviting. - The summary text is larger. I agree the original text is a little small, but this changed text looks too large for my eyes. - For each news item the horizontal dividing line comes before the title, rather than after it, which makes it easier to tell them apart. (See also the introduction/examples page, which uses the same css class for some reason.) Like OTHER PAGES - The boxes containing the site content have slightly rounded corners to match the rounded corners of the navigation bar, for greater visual consistency. Like - The spacing of the headers on these boxes is adjusted slightly so the words are more vertically centered. Like ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Issue 4293 in lilypond: Patch: Various fixes/improvements in connection with Smob allocation
Comment #3 on issue 4293 by lemzw...@googlemail.com: Patch: Various fixes/improvements in connection with Smob allocation https://code.google.com/p/lilypond/issues/detail?id=4293 David, in such cases please proceed immediately! +1 Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \displayLilyMusic and default durations
David Kastrup wrote Wednesday, February 18, 2015 6:00 PM
More seriously, currently \displayLilyMusic deals badly with
{ c4 c4 8 8 4 } which gets rendered as { c4 c 8 8 4 } and does
consequently not recreate its input. It would be rather tricky to fix
that since by the time the 8 is printed, c and the following space have
already been produced. Instead of making things even more complex here,
I consider it saner to become less clever and just print what's in the
data, never mind whether it's possibly redundant.
Opinions?
Agreed. It would be nice if \displayLilyMusic produced a canonical
form (using the preferred notation meaning) but we're a long way
from that. In the meantime, producing correct LilyPond input is far
more important.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
satb built-in template [was Re: Grand Advanced Stylesheet Project (GASP)]
Johan Vromans wrote Monday, January 19, 2015 4:02 PM There is a built-in template almost exactly like this in LilyPond already I does, indeed, use a very similar approach. It doesn't provide for guitar chords and (automatic) metronome track but I could add that. Improvements would be very welcome, but there are some defects also which Devon Schudy and I attempted to fix almost a year ago, but the patch attracted comments which caused it to stall. For the background, see issues 3777 and 3799 and https://codereview.appspot.com/51230043 Perhaps I should pick out the non-contentious parts and post a patch for just those. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Change default MIDI file extension to '.mid'
Phil Holmes wrote Monday, January 05, 2015 2:35 PM From: Davide Liessi davide.lie...@gmail.com I think that LilyPond should use the most widely accepted '.mid' as default extension for the MIDI files it produces, instead of current '.midi'. This is the default on my Windows Vista PC system. Don't know why, but that's what appears when I create midi output. The default MIDI file extension used to be .midi on all platforms, but it was changed to .mid for Windows systems only in 2.11.60, released in Sep 2008. See committish 2e740abdcd601e8d2148a35d48bd3c8ca5acfc99 Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Possible tweaks to the appearance of the website
Phil Holmes wrote Sunday, January 04, 2015 4:10 PM The major issue is that the nav bar is not present in IE. I understand IE9 is out of date, but many people use and prefer it over later versions, and for some applications you can't upgrade and have them still work. So we do need a web site that works in IE9. In chrome, I prefer the little Lily icon, and we seem to have lost the music image in the background, which I also quite liked. I agree with Phil on all these points. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Essay - Add Elaine Gould's book Behind Bars (issue 187860043 by address@hidden)
Villum Sejersen wrote Wednesday, December 10, 2014 4:06 PM Hello Trevor and whoever took the trouble to write thge entry (I simply can't find the name anywhere) It was James I believe. Yes. concise enough. Personally, although I don't like 'The definitive...'; 'An exhaustive...' is much more to my liking. The Definitive Guide to Music Notation is actually the sub-title of the English edition, so we can't change this. What about adding a reference to the german translation (2014)? It is not that often reference works are translated so early after the publication of the original, so I think it ought to be mentioned. Good idea. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB and mpfr/mpc
David Kastrup wrote Monday, December 01, 2014 3:25 PM I thought that I had at one time proposed something to be changed (as part of some issue?) order to deal with possible memory corruption, but a quick look through the log messages does not turn up either a commit from me or a commit message ringing a bell. Is this worth a look? de75ed87c50519b702a936512df0a665686a59d8 Author: Joe Neeman joenee...@gmail.com 2012-07-22 15:24:34 Committer: Joe Neeman joenee...@gmail.com 2012-07-22 15:24:34 Follows: release/2.15.41-1 Precedes: Fix memory corruption bug in skyline. Trevor ___ 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 164830043by nine.fierce.ballads at gmail.com)
Joram wrote Monday, November 03, 2014 9:09 AM 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. I quite like this suggestion, although it would need to be backed up by some validation to refuse to accept, or at least warn about, inconsistent combinations like \time 7/8 C|. But as an alternative to setting the 'style property this seems quite an attractive syntax, and considerably easier to remember and type than looking up a suitable glyph. N could mean numeric, maybe, to override the default C, and SN, single-numeric. But can we have an optional last argument? If not, it could be a second optional argument after the optional 'beatStructure, as it has a different predicate. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: suprising touch of rest with accidentals
Werner LEMBERG wrote Sunday, November 02, 2014 7:03 AM
[release/2.19.15-1-13-gdd5a6e7]
with this input
\relative c' {
gis' cis e8[ r fis gis dis' e gis cis]
}
I would expect that there is at least a tiny distance between the rest
and the sharp, but it seems that they directly touch – is this
expected? Having such a dense setting for a situation where lilypond
isn't forced to squeeze at all is bad IMHO.
I'd call this a bug. The manual beam over the rest is necessary to provoke it.
The bug was introduced during the 2.15 develoment cycle - in 2.14.2 it
displays nicely, but compresses in 2.15.95.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Time signature markups
Dan Eble wrote Sunday, October 26, 2014 12:34 AM time-signature.cc http://time-signature.cc/ has a comment at the top saying, “This file should go; the formatting can completely be done with markups.” Can anyone point me to a good example of that, or is it a unique idea? Well, that comment was placed in the file by Han-Wen in Sep 2003, so doing it doesn't seem excessively urgent. See 6b0464424f51e8b4cb6e1bdac3ff21bd610ba28b, although there are no further clues there to indicate what Han-Wen had in mind. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Issue 3066 in lilypond: tie in TabStaff (using q) displays one of the unisone notes in a chord
Comment #16 on issue 3066 by d...@gnu.org: tie in TabStaff (using q) displays one of the unisone notes in a chord https://code.google.com/p/lilypond/issues/detail?id=3066 As I have several other tie patches on the backburner that may or may not interact with this one, and this patch has already passed a review in its broken state, I'd lean towards pushing this rather speedily. Fine by me. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Where to put new Scheme engravers?
Urs, you wrote Sunday, September 28, 2014 10:38 AM Am 28.09.2014 11:36, schrieb Trevor Daniels: Most of the engravers are written in C++ and each is a separate file in the lily/ directory. There's a little above engravers here: http://www.lilypond.org/doc/v2.19/Documentation/contributor/engraver-tutorial Yes, I've seen that, and as you say this only gives information about C++ engravers. But I do have an engraver written in Scheme (not by me) that I find very useful. I could make it available in openlilylib, but I think it's a very common notation that should be available in LilyPond itself (printing double barlines before time signature changes). Do you want to say that it's inappropriate to add Scheme engravers to LilyPond and that it should be rewritten in C++ for that (which I couldn't? Ah, sorry, I missed the keyword Scheme in your original post. Currently there is just one Scheme engraver in the LilyPond codebase. It is in scm/scheme-engravers.scm, and was added as part of issue 2445. You may find it useful to read through that issue: https://code.google.com/p/lilypond/issues/detail?id=2445 It would be sensible to add your engraver to to same file. Later, if many more Scheme engravers appear, it might be better to separate them out into individual files. And by then the documentation problem mentioned by David might have been fixed. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: LM - correct @example for Tweak Command (issue 140630043 by pkx1...@gmail.com)
James, you wrote Monday, September 15, 2014 5:52 PM
On 15/09/14 16:04, d...@gnu.org wrote:
[snip]
which, uh, points to @var{value} being quite in the minority, and the
text @var{value} is a Scheme object, which is why it must be preceded
by further muddifies the distinction between # being part of the
override/tweak syntax and part of the value.
Also Documentation/notation/changing-defaults.itely contains quite a
few old-syntax overrides.
I have to admit that putting @var{value} here alone will not help
consistency: this would need a more sweeping revision that replaces
must be preceded by # with will usually be a Scheme value
introduced with # unless it is a LilyPond-native construct like a
markup.
Do you have any particular preference this being the Learning Manual and
all?
I'd keep the # for this amendment and raise a new doc issue to cover the
points David makes above.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Die, instrumentSwitch. (issue 133390043 by k-ohara5...@oco.net)
Keith, you wrote Sunday, August 31, 2014 7:36 PM On Sun, 31 Aug 2014 01:06:46 -0700, tdanielsmu...@googlemail.com wrote: A few minor comments below, but I don't see how we can just remove the instructions for setting up InstrumentSwitch without some replacement. InstrumentSwitch is used by \cueDuring and friends. \cueDuring itself does not use InstrumentSwitch; we were manually creating a temporary cueVoice just before the \cueduring. [snip] So the replacement for this use of InstrumentSwitch _\markup\italic\teenyTuba is covered by the markup docmentation The history is long. [snip] Ah, I'd totally forgotten that history. As I'm not sure what I did this morning I have no chance of remembering things that happened 4 years ago. Thanks for the reminder. So if you're happy now with using let's try again! Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: indclude notnames bn, etc., in English (issue 133840043 by k-ohara5...@oco.net)
Dan, you wrote Tuesday, August 26, 2014 10:25 PM On Aug 26, 2014, at 07:13 , tdanielsmu...@googlemail.com wrote: LGTM, assuming users of English note entry are in favour. Since you asked, I think having multiple names for the same pitch creates its own problems. I have no difficulty using the current names. If people want a variant, how about keeping \language “english” what it is and calling this variant something else? That will both prevent people from confusingly mixing the two variants in the same input file and also help explain the situation to a unfamiliar person reading a snippet written with the new note names. Well, \language english already has multiple names for the same pitch. If you look at NR 1.1.1 Note names in other languages, you'll see that B-flat can already be written as bf or bflat and similarly for sharps. So adding one more variant doesn't add much to the confusion, if confusion there is. I've not noticed much confusion caused by the current variants among \language english users on the lists. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds incipit section to NR (issue 108270043 byphilehol...@googlemail.com)
Phil, you wrote Thursday, August 21, 2014 3:18 PM And this is the nub of the discussion. There's nothing actually _wrong_ with my patch: it's just you don't like how it looks. I very much do. This time I've attached a centre-aligned and a right-aligned example, and much prefer the latter. And if you say right-aligned is wrong, you should also write to Elaine Gould to correct her. The only mention of incipits that I can find in Elaine Gould's book is on page 433. She says nothing there about alignment of instrument names, but the image of the incipit has them left-aligned, above the staff showing the ancient music. On page 509 she shows two alternatives for instrument labels in general: traditional-style in which the labels are centered and alternative-style in which the labels are right-aligned. The accompanying text says, Instrument labels may be centered in the margin space - this is the most traditional layout. Alternatively they may be justified right or even justified left. Have I missed something? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Open counterpoint text, thanks to devs
Hi Jonathan Nice to see you back. I can sympathize with your RSI wrist problems - I too have to be quite careful how much computer work I do for the same reason. Your textbook looks really interesting, not only for the use of LilyPond and the inclusion of mp3 files but also for sight of the book itself, which is new to me. I'm enjoying reading it! Thanks for sharing! Trevor - Original Message - From: Jonathan Kulp jonlancek...@gmail.com To: lilypond-devel@gnu.org Sent: Sunday, March 16, 2014 7:36 PM Subject: Open counterpoint text, thanks to devs Hi folks, it's been a long time since I was actively contributing to Lilypond documentation but I have been lurking and following certain threads in the dev mailing list. I'm still around but it still have wrist problems, helped quite a bit by some pretty cool Linux speech recognition software developed by a friend of mine. I wanted to send a brief note of thanks to everyone who has done so much for Lilypond development. Recently I've been working on a major project, which is to take a public domain counterpoint textbook and overhaul it for use as an electronic textbook. It is done in responsive, mobile-friendly HTML (there will also be an epub version) and I'm using Lilypond to typeset the musical examples. Not only will there be images of all the examples, but I also wrote a bash script that uses Lilypond's midi output to generate mp3 and ogg files for html5 audio players. Finally a music theory textbook where you can click to play the examples instead of having to find a keyboard! You can see the LilyPond source code for any example simply by clicking on the image. I'm very happy with how it is turning out so far, and constantly amazed at what is possible with lilypond. If you would like to see the work in progress, follow this link. http://jonkulp.net/350/Goetschius/goetschius.html It will probably be quite some time before I'm done with all of the examples, but I plan to use the textbook when I teach counterpoint again next spring. My current students have been very enthusiastic as I showed them the progress I've made so far. Best wishes to all, and thanks again for a most excellent tool. Jonathan -- Jonathan Kulp http://jonathankulp.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fw: Guile 2 for Lilypond
Forwarding to -devel as this looks serious. Trevor - Original Message - From: spuhler tho...@btspuhler.com To: lilypond-u...@gnu.org Sent: Thursday, March 06, 2014 1:55 AM Subject: Re: Guile 2 for Lilypond Now that Mageia4 is out with Lilypond-2.18.0. We are working on the next version to be release around Christmas 2014. Lilypond is now the only package that requires Guile 2.0. I have built Lilypond-2.19.3. That said, Guile-1.8 gets more and more difficult to build and I am afraid it's going to be dropped from our next Distribution release and as a result Lilypond will not be in the next release by the end of 2014 unless it will build and work with Guile-2. Is there a time-line for Lilypond with Guile-2? Will it be before November 2014? If not I am not going spend my time to put Lilypond-2.19.x into Cauldron (the Mageia development version) Thomas -- View this message in context: http://lilypond.1069038.n5.nabble.com/Guile-2-for-Lilypond-tp144973p160148.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-u...@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Automated engraving benchmarks
Urs Liska wrote Thursday, February 27, 2014 8:44 AM Hi, I just had an idea. I suggest creating a set of benchmark scores and putting them somewhere on the website. But of course we should then have default scores like a classical piano piece, a string quartet and a moderately complex orchestral score. Plus an SATB score with piano reduction (for rehearsal only) What do you think? Go for it! Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Ubuntu and LilyPond from scratch
James wrote Sunday, February 23, 2014 5:48 AM On 21/02/14 16:55, Trevor Daniels wrote: No sure if this is of interest to anyone, but I have just successfully installed Ubuntu 12.04.4 from scratch, followed by git, and the LilyPond repository. Following the CG, I then ran autoconf and configure, apt-got the missing packages, and successfully ran make all and make doc. I've never done this before from scratch - previously I used Lily-dev - and was surprised how easy it was. I don't know how to build a 'liveCD' from other distributions and the tool that I used for lilydev is no longer being developed and while it works for 13.10 it still produces huge ISO files (2GB in size). I've been trying to find a way to build a _small_ ISO file for a new lilydev but time and experience are alluding me. But we could just update the CG (I thought Eluze had done that, but am obviously mistaken) based on that tracker I referenced above. Well, the CG's instructions as far as I've gone (up to make all and make doc) are absolutely fine (except that the instructions for building the docs are found only under 'compiling'). I used to use LilyDev under Windows but found it affected my 'normal' work too much when the VM was running on my 2Gb laptop. As a spare laptop became available I decided to install ubuntu there just to try it out. Not sure I'm going to do any serious LilyPond work there though - I'll still do any doc work on my usual machine under Windows. So from my experience, using LilyDev in a VM under Windows is only viable if you have a pretty substantial host available. In which case the large memory requirement might not be so much a problem, as long as the instructions make that requirement clear. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Ubuntu and LilyPond from scratch
No sure if this is of interest to anyone, but I have just successfully installed Ubuntu 12.04.4 from scratch, followed by git, and the LilyPond repository. Following the CG, I then ran autoconf and configure, apt-got the missing packages, and successfully ran make all and make doc. I've never done this before from scratch - previously I used Lily-dev - and was surprised how easy it was. Some minor comments: I had to apt-get autoconf to enable the autoconf script to run and configure then required dblatex (a surprise - I thought this was no longer used?) and texlive-lang-cyrillic. That's all. Quite easy. make all and make doc then ran perfectly to completion. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Ubuntu and LilyPond from scratch
David Kastrup wrote Friday, February 21, 2014 5:06 PM Trevor Daniels t.dani...@treda.co.uk writes: I had to apt-get autoconf to enable the autoconf script to run and configure then required dblatex (a surprise - I thought this was no longer used?) and texlive-lang-cyrillic. That's all. Quite easy. make all and make doc then ran perfectly to completion. You can probably just do apt-get build-dep lilypond to get the dependencies: I don't think they changed since Ubuntu 12.04. It's conceivable that texlive-lang-cyrillic was not in that set (I think Ubuntu 12.04 would have carried LilyPond 2.14 but am not sure). I should have been more explicit. I did apt-get build-dep lilypond first. That installed quite a lot. The two dependencies I mentioned were then left unresolved. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Point-and-Click has wrong default value and ref to SVGoutput needs adding (issue 61630045)
pkx1...@gmail.com wrote Sunday, February 16, 2014 6:51 AM Looking at the TexInfo page for @acronym https://www.gnu.org/software/texinfo/manual/texinfo/html_node/_0040acronym.html It doesn't seem to give us anything that useful and perhaps (as it also says in the link above): - In general, it's not essential to use either of these commands for all abbreviations; use your judgment. Text is perfectly readable without them. So unless anyone has strong feelings - and we can have a new tracker - I think I'll leave them unformatted. I agree. New doc writers are hard to come by and can be easily put off by the complexity of TexInfo. We should not complicate things unnecessarily by yet more rules. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Emergency call. Or not.
David Kastrup wrote Sunday, February 16, 2014 2:45 PM I find that I'm currently dead-locking in decision-making with a somewhat tedieous task. Here is what it boils down to: basically git checkout -b translation origin/translation git log --reverse --no-merges origin/translation..origin Documentation The list of changes contains 117 changes. Huh, that seems actually too much to do in an hour or so even if one drops most of those commits. I don't think it makes sense to do this in a rush. So maybe we just punt for now and let Phil release 2.18.1, and then we try doing this leasurely until 2.18.2, in 6 weeks or so. In that case, the translators have a chance to catch up, too. And then we can just leave it alone, move the translation branch over to 2.19 and focus on it for good. Agreed. Relax. Let Phil issue 2.18.1 as is and plan a doc 2.18.2 release in a few weeks. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stencil.scm: add make-path-stencil function (issue 54050043)
Paul Morris wrote Thursday, January 23, 2014 10:44 PM This second patch set appeared successfully on Rietveld, but it looks like the automatic test to confirm that it passes make, make check, and make docs was not triggered: http://code.google.com/p/lilypond/issues/detail?id=3818 So how to handle this? Is there something I can do at this point to get Patchy to do its thing? Yes. Go to the issue tracker 3818, click in the box at the bottom to enter a comment, and set the label Patch-countdown to Patch-new, and save. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Issue 3818 in lilypond: Patch: stencil.scm: addmake-path-stencil function
Comment #3 on issue 3818 by paulwmor...@gmail.com: Patch: stencil.scm: add make-path-stencil function http://code.google.com/p/lilypond/issues/detail?id=3818 Attempting to change label to new to trigger automated tests. I don't see any interface for editing labels, just this comment field and a link to attach a file. (Maybe I don't have sufficient privileges to edit labels?) Maybe you just enter them as text here in the comment? Here goes, but I doubt this will work, except maybe for comic effect... Labels: -Patch-countdown Patch-new It seems you're not authorised to change the labels, so I've done it for you. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: python/convertrules.ly: Use bare rhythms after ties for simplecases (issue 49470049)
tdaniels wrote Friday, January 10, 2014 8:39 PM It would seem that when you added the respective template lines, you should have updated the version number of the file as well. With hindsight. But we never do that when editing doc files as a rule. Now of course, in analogy to the last conversion, I should exempt the learning manual from this automatic conversion. But you still should fix the version header to 2.18.0 or so, assuming that no other rules applied. OK. I'll do that. Actually this seems to be a consequence of not bumping _all_ version numbers to the current release. Before, when editing doc files, we always assumed Lily code being added should use the syntax of the current release in master. But now this assumption may trigger inappropriate conversions, as here. This needs to be thought through again. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add Changes entries for bare rhythms and \beamExceptions (issue47850043)
d...@gnu.org wrote Monday, January 06, 2014 3:27 PM Maybe one should not try finding a term at all? One might write something like Durations can now be written in music expressions without an immediately preceding pitch or chord. In the score, the missing pitches will be taken from the last preceding note or chord. Yes, and even simpler: Durations can be written in music expressions without an immediately preceding pitch or chord --- the missing pitches will be taken from the last preceding note or chord. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Announcing 2.18.0 widely?
David Kastrup wrote Thursday, January 02, 2014 2:54 PM Apart from a note about the convert-ly accident, does anybody see a reason not to announce 2.18.0 presently to a wide audience? Or should we wait until 2.19.0 is out? I _think_ that the web site should be fine currently. I think it's pretty solid. In any case the expectation is that a .0 release will be quickly followed by a .1 release which fixes all the oversights. Go for it! BTW, are the number of downloads recorded anywhere? It would be interesting to track this for stable releases. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond 2.18.0 released
David Kastrup wrote Monday, December 30, 2013 4:50 PM We are proud to announce the release of GNU LilyPond 2.18.0 - the new stable release. Congratulations, David! Well done! Thanks for driving this through. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: note-spacing: stretch somewhat uniformly; issue 3304 (issue 36830045)
On Mon, Dec 16, 2013 at 2:28 AM, Mike Solomon m...@mikesolomon.org wrote: On Dec 16, 2013, at 10:24 AM, k-ohara5...@oco.net wrote: Reviewers: MikeSol, Message: On 2013/12/16 07:42:52, MikeSol wrote: If you understand this stuff, could you put a comment in lily/include/spring.hh as to what inverse_compress_strength and inverse_stretch_strength are? They are the stretchability and compressibility of the space. Next time I have linux up I'll put a comment, or just change the names. Ok - try to explain the relation between things (min distance, ideal distance, and these two constants). You should try the patch on your music. You probably have a lot of staggered timing in the style of 3-against-2 hemiola, which should be aligned more evenly with the patch. I’d say Trevor Bača is an even better candidate (cc’d to this e-mail) - he has π on *e* hemiolas in his music. Hi all, Just now read through this thread. (Thanks for point me to it, Mike!) I haven't followed the details of this change. But it is true that I have a large number of differently tupletted rhythms written against each other in most of my scores (though, alas, no ratios in terms of transcendental numbers ;) What I can say is that I've downloaded and run each of 2.17.95, 2.17.96 and 2.17.97 against all of my recent scores (and also against a sizable battery of related regression tests) and the horizontal spacing has been excellent in the output coming from all three release candidates. I suppose it's important to note that all of my scores use proportional notation everywhere. So I imagine that most of the horizontal spacing improvements don't actually impact my scores. (The recent spacing changes optimize Lily's *default* spacing, correct?) In fact I've been amazed at how consistently correct horizontal spacing turns out from one version of LilyPond to the next when proportional notation is turned on. [As an aside (but hopefully a helpful one), proportional notation was one of the first things that brought me to Lily years ago. Han-Wen and I built the specification for proportional notation together and he did the implementation (way back in 2005, IIRC). Since that time I've used proportional notation in every score I've written. (And I've since seen a number of other composers who favor more-or-less complicated rhythmic divisions in their own music doing the same.) And I'd like to report something quite wonderful: in *many* of the first rehearsals of performances of my music that I've been to, it's been the case that one or two of the musicians will take me aside during a break and say something like this regular spacing thing that you're doing here: it helped me tremendously when I was trying to figure out how all these rhythms are working; is there any chance you could convince other composers to do the same thing. (!) So it was a (very gratifying) surprise to learn that players have been as much of a fan of the feature over the years as I have. And, actually, quite unexpected.] So all of that is just to point out that I may very well not see the results of recent spacing optimizations for reasons of proportional spacing. Trevor. -- Trevor Bača trevorb...@gmail.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: note-spacing: stretch somewhat uniformly; issue 3304 (issue 36830045)
On Fri, Dec 27, 2013 at 1:28 AM, Keith OHara k-ohara5...@oco.net wrote: On Thu, 26 Dec 2013 22:47:41 -0800, Trevor Bača trevorb...@gmail.com wrote: I suppose it's important to note that all of my scores use proportional notation everywhere. So I imagine that most of the horizontal spacing improvements don't actually impact my scores. (The recent spacing changes optimize Lily's *default* spacing, correct?) This patch does concern the default method of horizontal spacing. The bug that this is meant to fix (http://code.google.com/p/ lilypond/issues/detail?id=3304) can be seen even with proportionalNotationDuration, if there are interleaved rhythms on a line that is stretched or compressed. Probably, though, you also set 'uniform-stretching', which removes the problem. Correct: I set uniform-stretching every time proportional notation is turned on. This patch makes the default spacing case stretch/compress more like it does with uniform-stretching, while keeping the detailed spacing adjustments in response to things like neighboring stem directions that 'uniform-stretching' would normally skip. Nice. I've always thought that sort of hybridization of classical spacing and proportional spacing would eventually become a new norm. -- Trevor Bača trevorb...@gmail.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG organization (Git)
Urs, you wrote Sunday, December 22, 2013 8:55 AM Subject: CG organization (Git) I'm somewhat confused about the organization of the CG chapters about Git and patch review. The CG has never been properly revised and reorganised, with many sections added without considering the effect on others. This was a deliberate policy to permit the easier addition of material, so ensuring it was at least captured in the manual. Maybe it's now time (during release 19) to begin this revision. In the meantime, follow the present policy and dump your offering in whichever place seems easiest or most appropriate to you. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG organization (Git)
Urs Liska wrote Sunday, December 22, 2013 9:40 AM Am 22.12.2013 10:29, schrieb Trevor Daniels: The CG has never been properly revised and reorganised, with many sections added without considering the effect on others. But I'm still more confused because this contradicts 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? from a week ago. Well, the previous 4 times were quite some time ago, and a lot has been added since then. Your recent questions are evidence that more consolidation is needed. Big job, though. Graham and I have both experienced it reorganising the NR. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3718 in lilypond: Patch: Web: Reword contactUsAbout macro
Urs Liska wrote Friday, December 20, 2013 9:28 AM Am 19.12.2013 11:32, schrieb lilyp...@googlecode.com: Patch counted down - please push What should I do now? The CG says I should send the patch to my mentor, but obviously this isn't applicable. Create a git format patch, post it on -dev and ask if anyone can push it for you. And I have a few more general questions that don't seem to be covered in the CG: 1) origin/master has moved in the meantime. I can rebase my patch without conflicts in this case, but what is the general task at this point? - rebase my branch on origin/master - if that works, create a patch with patch-format - send it - where? See above 2) What to do if the rebase would require changes to resolve conflicts? Wouldn't the changed patch have to be reviewed first? (possibly causing a loop with the next rebase ...) This occurs rarely. Up to you to resolve the conflicts. Make a judgement if a further review is then justified. 3) What to do if my branch contains more than one commit? Should I squash them so the patch is one (big) commit? I wouldn't like that, for example because I would separate commits that move stuff (e.g. to other website nodes) from commits that change text (so translators have easier work)? No, leave them as separate commits and merge them into staging. 3b) Commit messages haven't been part of the review process, right? So basically I'm responsible that commit messages of my (multi-commit) patch are accurate. Is that right? Yes. If yes, I think that should be documented in the CG (I can do a few improvements in the CD, along getting acquainted with the process) :) Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3718 in lilypond: Patch: Web: Reword contactUsAbout macro
Urs Liska wrote Friday, December 20, 2013 9:48 AM Am 20.12.2013 10:45, schrieb Trevor Daniels: 3) What to do if my branch contains more than one commit? Should I squash them so the patch is one (big) commit? I wouldn't like that, for example because I would separate commits that move stuff (e.g. to other website nodes) from commits that change text (so translators have easier work)? No, leave them as separate commits and merge them into staging. Should I merge to staging and _then_ create the git format-patch from there? Or should I leave the branch open, create the patch set and send it to -devel? Ah, good question. The latter I think. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Simplified version of Trevor Daniels' SATB framework. (issue 38720045)
Carl Peterson wrote Thursday, December 19, 2013 2:49 AM And if it is a technical question (going back to your comment about the bottom of the bass being cut off), I would want to dig into why that is---what is it about this score block as opposed to an instrumental block that causes this?---rather than sticking a band-aid on it by arbitrarily adjusting the margins. I looked further into this, and my problem with the bottom of the bass line and the tag line being cut off seems to be a problem with Frescobaldi, or at least Frescobaldi on my computer/printer. I have only recently started using Frescobaldi so as yet I am unfamiliar with its behaviour. The pdf it produces looks fine on the screen, both in Frescobaldi and in a separate viewer, and the pdf prints correctly from a separate viewer. It is only when I print it from within Frescobaldi that there is a problem with the bottom being cut off. So I'll pursue that separately. As far as the template goes, I'm now content to leave out the paper block, as the pdf and print (although not quite as I would like it) is perfectly acceptable when using the LilyPond default settings. @Devon So, Devon, how shall we proceed with the remainder of the review? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Simplified version of Trevor Daniels' SATB framework. (issue 38720045)
Carl Peterson wrote Wednesday, December 18, 2013 10:54 PM I'm not sure I agree. I think for maximum utility, the template should define as little as possible regarding the physical dimensions of the page and margin, so that the user can use whatever style they want. But if the user is going to define his/her own \paper block the defaults will be overridden anyway - having them would do no harm nor cause more work for them. For instance, I use a 1/4 inch margin on a half-letter format normally, but a 3/4 inch margin or so on a full letter size page. If the point is to simplify vocal scores, do the minimum required to produce the vocal score and leave the rest alone. Well, the point is rather to enable the user to do the minimum required to produce a vocal score. LP already has an A4 default output, so setting margins by default to suit that, rather than _requiring_ a user to learn about \paper would definitely help newcomers. (The NR section on \paper is pretty daunting for a newcomer! And it's not even mentioned in the LM.) Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
Werner LEMBERG wrote Sunday, December 15, 2013 9:07 AM raw/final would be shorter than pure/unpure. I like that. At least for me this is easier to understand from a conceptual point of view. pencil/ink. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website questions: GSoC
Urs Liska wrote Thursday, December 12, 2013 1:27 PM Question: Should the ideas on that page be preserved as ideas for future development? This could be on the tracker or on some other page. Most if not all of Janek's work is preserved in the LilyPond git repository under various incomplete branches with 'Janek' in the name. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: branching
Mike Solomon wrote Wednesday, December 11, 2013 10:22 AM On Dec 11, 2013, at 11:36 AM, David Kastrup d...@gnu.org wrote: As opposed to me, Graham excelled at organizing and maintaining community efforts like this which makes his leaving an even larger loss. His leaving is a huge loss, and as he has stated several times, one big reason is the lack of sense of community. devel-list quarrels and the thaws that come from them have real impacts on LilyPond - I can’t emphasize enough that we need to stop marginalizing this issue and tackle it head on. Modularity, while perhaps a good long term solution, is a long ways away. How are we going to deal with this in 2014? Actually, I think there is a great sense of community within the LilyPond project. Why else would people comment so favourably on the responses they receive on the various mailing lists; why else would people on the bug squad, Phil on releases, James on managing reviews, etc devote their time to mundane tasks? Why else would people, even those no longer active in LilyPond development, continue to read the lists? No, we are a great community and it is greatly enjoyable to belong to it! Also we are extremely fortunate to have so many brilliant developers willing to spend their time augmenting, fixing and improving our baby. That differences arise from time-to-time is inevitable - from the nature of this project our community includes people covering a wide range of temperament. Artists, artisans and engineers all figure prominently. They have different viewpoints and approaches, but this is an advantage not a problem - providing we can find a way to live and work together without stress levels getting too high. How are we going to deal with this in 2014? I would recommend Mike and David both consider privately what they might have done differently to avoid this situation arising. Not what the other should have done, but what they themselves might have done. If they'd like to share those thoughts with the list that would be good, but that is not essential. But they must share them with each other and try to culture a mutual respect and understanding for the other's position. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
Keith OHara wrote Tuesday, December 10, 2013 8:36 AM Most of the increase in time to set this score happened between 2.17.0 and .1 2.16.2 2m 30s 2.17.0 2m 28s 2.17.1 4m 06s so it is probably the issue 2148 patch, use of outlines instead of boxes for layout. I did speed-test that patch, but under Linux. Maybe the system calls to the font server, to get outlines for the glyphs, take longer under Windows. Could be. I've noticed that changing fonts under pure Windows programs like Excel takes a surprisingly long time. That's under Vista Home Premium. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Suggestion: Keep original breaks
Urs Liska wrote Wednesday, November 27, 2013 10:30 AM I would like to suggest an enhancement in the handling of line breaks that is useful for copying scores from existing models. I suggest a command line option -dkeep-original-breaks for this switch. That way the user can add that option for a compilation or write #(ly:set-option 'keep-original-breaks) in the input file. Does this switch cause manually inserted \break etc commands to be inhibited? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [translations] Re: 2.18 release plans (again).
Werner LEMBERG wrote Saturday, October 26, 2013 8:07 PM I've now pushed stable/2.18 and synchronized translations to it. Thanks for your hard work! Indeed! Much appreciated, David! Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our workflow with better tools - let's test things.
Joseph Rushton Wakeling wrote Monday, October 21, 2013 6:50 AM On 21/10/13 06:13, Carl Sorensen wrote: What me drives crazy is the structure of the main git repository. If you follow github style, the graph gets littered with zillions of `merge request' commits, one per pull request, which makes it quite hard to follow the development IMHO. It's true it can get annoying if you have lots of one-commit contributions. On the other hand it lends itself to being able to split your contributions into multiple separate commits for which the main git history simply gets a summary (the merge commit). I still think it's ultimately worth it for the discipline of No one pushes directly to master, which helps enforce a requirement that everything gets tested and reviewed, even stuff by core developers. The vast majority of my contributions are single-commit, and I suspect most other contributions are the same. They are easy to manage and generate a clean history with merge commits appearing only when they are appropriate. Our git repository was not always managed in this way, so the advantages of a clean history are obvious, at least to me. Our current workflow already enforces: No one pushes directly to master. Why is it ultimately worth it to lose a real advantage only to regain something we already have? Having worked with Carl for some years I respect his opinion, and for me his bottom line: I'm seriously thinking of junking Gitlab because the benefit seems to be more promised than realized, based on his experience of actually using Gitlab on a real project clinches the matter. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add documentation for the music function \alterBroken to the NR. (issue 15060044)
From: david.nales...@gmail.com https://codereview.appspot.com/15060044/diff/1/Documentation/notation/changing-defaults.itely#newcode4396 Documentation/notation/changing-defaults.itely:4396: Should there be a warning about not using \break to enforce line breaks? The command will work if the break isn't forced. The \breaks elsewhere are only a consequence of the minimal examples. If you think there might be confusion, I could possibly add a comment to one of the \break lines. \break added to force a line break on a short line. \alterBroken does not require forced breaks. What I had in mind was a warning that if an explicit \break is not included the break may occur at a different place following changes, and the values may no longer be appropriate. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR imports and version numbers?
Phil Holmes writes Saturday, September 28, 2013 2:19 PM From: David Kastrup d...@gnu.org Phil Holmes m...@philholmes.net writes: There is a question in my mind as to what a) should bump the version to: i) current version; or ii) version that the update related to. Simplest is probably i). Uh, i) is what's currently happening and it's _exactly_ what causes this annoyance. Any file imported from the LSR (which is at 2.14 or similar) that gets changed at all gets bumped up to current. Since the imports are a one-way street, we just get an increasingly larger number of files getting bumped up to current on each import. Ah - OK - I understand now. I'd forgotten that we always start with old files, rather than the most recent updated file. Yes, if we can make option ii) work, it would solve this problem. I'm in favour. Option (ii) looks the more sensible one to me too. Any snippet, not just those in LSR, is more useful if version references the earliest version of LilyPond that can correctly compile it. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: no critical: 2.18 is close?
David Kastrup wrote Friday, September 27, 2013 1:33 PM I think after letting 2.17.27 settle for a few days, we are ready to create the branch. We still might make another 2.17 release afterwards to get some exposure to final fixes (like the \fill-line markup), but it better not have any syntax changes requiring convert-ly rules unless they are going to end up in 2.18 as well. Issue 3566 is a candidate for this may or may not make it threshold. But I think having a release of 2.18 ready in about three weeks seems possible enough that we should try. Good. I'll start to think about the doc changes which should go into 2.19 :) Suggestions welcome. (I stopped making changes to the docs a while ago so translators had a clear target to aim for.) Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Issue 3566 in lilypond: Grace notes should beautobeamed
Comment #6 on issue 3566 by d...@gnu.org: Grace notes should be autobeamed I don't think the current state warrants a convert-ly rule: it does not seem like the previous behavior is used to any reasonable degree, and it can always be reverted by removing the engraver. Anything that has been explicitly beamed before will stay that way. Sounds fine to me. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stem direction snippet
Phil Holmes wrote Friday, September 27, 2013 8:54 PM I've added a snippet (http://lsr.dsi.unimi.it/LSR/Item?id=751) to master that explains how to set stem direction based on surrounding notes. Anyone object to my adding it to selected snippets in http://www.lilypond.org/doc/v2.16/Documentation/notation/inside-the-staff#stems - I think it makes a useful piece of information. LGTM Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
Phil Holmes wrote Thursday, September 26, 2013 3:11 PM - Original Message - From: Joseph Rushton Wakeling joseph.wakel...@webdrake.net On 26/09/13 15:04, David Kastrup wrote: How many substantial patches would you expect yourself to be contributing in the wake of such a move per month to LilyPond? Don't know. Most of my potential contributions to Lilypond are likely to be documentation -- among other things I'd like to revisit and finish up the Contemporary Music section. That would be something that we desperately need. The NR documentation on Contemporary Notation is shockingly poor. I would be prepared to accept almost any form of input from you with the words that improve that section of the NR and would be happy to type git cl upload on your behalf, in order to get the patches reviewed. Almost exactly what I was about to reply, but Phil beat me to it! In fact I think I remember helping you add the Contemporary music headings some time ago, or was it someone else? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: one space vs. two spaces after full stop
On Sep 15, 2013, at 4:41 AM, Werner LEMBERG w...@gnu.org wrote: This is slightly off-topic, but maybe you enjoy the reading :-) http://www.heracliteanriver.com/?p=324 However, the above holds for printed output. For input files, I think that two spaces after a full stop makes sense regardless of aesthetic considerations. In particular, it helps editors (like Emacs) navigate sentence-wise. Thanks, Werner. I loved it! Me too! Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Windows tutorial
Phil, you wrote Thursday, August 15, 2013 1:21 PM Over 30 people have looked at this page and I've had no comments, so I'm going to prepare a patch for review on the assumption that people are broadly OK with the proposed changes. I think you should. I looked at the page and it seemed fine to me, but I didn't study it carefully enough to give it unqualified support. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds bar line section to LM (Issue 3408) (issue 12724043)
Phil, you wrote OK - I suggest I don't change my patch as you've suggested, because the way I did it was to copy the original, and so it currently follows the style for that section. I'll raised an issue to change all instances of @subheading to @unnumberedsubsubsec in the LM and do that once this patch is pushed. That sound OK? Yup. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Vertical spacing tutorial (Issue 2809) (issue 11966043)
Phil Holmes wrote Wednesday, July 31, 2013 6:04 PM From: tdanielsmu...@googlemail.com Documentation/learning/tweaks.itely:2472: property. Spacing them away from the staff which they relate to Sorry to be pedantic, but I'm of an age that still prefers to see to which in print. https://codereview.appspot.com/11966043/ I will change it before pushing, but up with which I will not put is relevant? Not really. Churchill probably never said this. His command of English was impeccable:: The conditions of the Transvaal ordinance under which Chinese Labour is now being carried on do not, in my opinion, constitute a state of slavery. A labour contract into which men enter voluntarily for a limited and for a brief period, under which they are paid wages which they consider adequate, under which they are not bought or sold and from which they can obtain relief on payment of seventeen pounds ten shillings, the cost of their passage, may not be a healthy or proper contract, but it cannot in the opinion of His Majesty's Government be classified as slavery in the extreme acceptance of the word without some risk of terminological inexactitude. ;-) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3457: Add snippet `Using \partcombine with lyrics'. (issue 11328043)
markpole...@gmail.com wrote Friday, July 19, 2013 7:10 AM
On 2013/07/18 20:47:05, dak wrote:
So what would be a nice and natural user interface, and
what pieces are missing from it?
\new Staff \with { printPartCombineTexts = ##f }
\new HiddenVoice = voiceForLyrics \sopranoNotes
\new Voice {
\key g \major
\partcombine \sopranoNotes \altoNotes
}
\new Lyrics \lyricsto voiceForLyrics \words
HiddenVoice could also be LyricsVoice I suppose, but
HiddenVoice seems more sematically flexible.
So yes, I would save untold hours if I had this feature. I
can't speak for anyone else, but we might ask the other
choral-music typesetters among us for their opinion.
I agree entirely. A Voice context that did not take part
in layout or midi would be a great help in choral music.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: workaround for \partcombine limitation, how to add to docs?
Mark Polesky wrote Monday, July 15, 2013 9:50 PM In NR 1.5.2 Multiple voices - Automatic part combining, this appears in the Known issues: All \partcombine… functions can only accept two voices and are not designed to work with lyrics; such that when one of the voices is explicitly named in order to attach lyrics to it, the partcombiner will stop working. http://lilypond.org/doc/v2.17/Documentation/notation/multiple-voices#Known-issues-and-warnings-82 I have found a workaround, detailed below. What is the best way to include this in the docs? Hi Mark Add it as a snippet, suitably tagged. This is neat, but I think it is too much of a hack to reference it explicitly in the documentation text. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: References to publications in the docs
Phil Holmes wrote Saturday, July 13, 2013 12:39 PM Subject: References to publications in the docs We currently refer to Gardner Read and others in the NR under the very sparsely populated Contemporary Music section of the NR: http://www.lilypond.org/doc/v2.17/Documentation/notation/further-reading-and-scores-of-interest It strikes me that this would be better at the end of section 1 of the LM: http://www.lilypond.org/doc/v2.17/Documentation/learning/overview-of-manuals Further reading, plus adding at the very least Elaine Gould's book. Does anyone disagree? Fine by me, Phil. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make format for key changes consistent; minor formatting corrections for affected regtests (issue 10868043)
d...@gnu.org wrote Tuesday, July 02, 2013 1:07 PM
Ok, here is a true can of worms followup item: in the case where the
\key statement is followed by more material on the same line, it would
make sense to have a _double_ space before the following material.
git grep '\\key [a-z]\+ \\[a-z]\+ [^ {}]'
throws out a whole lot of candidates for that. We don't do this sort of
double spacing with other constructs, but in the case of \major I find
the resulting progression in the line badly readable.
I agree the legibility of this example is bad, but rather than introducing
a double space I think I'd prefer to see any material following
\clef bass \key es \major
moved to a new line. If the material contains notes, as it does in the
quoted example, then that would be definitely be my preference.
But as Phil suggests, this should be the subject of a new issue.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Documentation policy
David Kastrup wrote Sunday, June 16, 2013 12:27 PM
Phil Holmes m...@philholmes.net writes:
the music
c'2
c'16 c'16 c'16 c'16
\tuplet 5/4 {
c'16 c'16 c'16 c'16 c'16
is repeated 3 times in the single snippet.
Well, I see nothing wrong with using a music variable here. We are
rather careful in the tutorial not to introduce material before it has
been explained, but I think that we don't have similarly stringent
linearity rules for the NR.
Exactly so. The NR is intended to be a reference document, not a
linear read like the LM.
A music variable would be fine here.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stencils: let some stencils carry a box-extent; issue 3255 (issue 9295044)
d...@gnu.org wrote Wednesday, June 12, 2013 6:42 AM I disagree. There is harm in having both since it makes people think about which to use in which situation. Since we have \pad-x and \pad-y, \pad-around makes more sense to keep. Not only does the name help with knowing just what is padded, but also we don't tend to put markup in command names redundantly. If we don't like convert-ly, we can just keep an undocumented compatibility function. Or document it as exists only for historical reasons and is the same as pad-around. I agree. Leave it available but documented as David suggests only in code comments. https://codereview.appspot.com/9295044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Path to LilyPond 2.18
David Kastrup wrote Wednesday, June 05, 2013 5:07 PM So for better or worse, we need to start wrapping up what we are going to call our next stable release. I propose calling the next developer release 2.17.95 to send out the message that finish-up work is called for: those translators who don't have the resources for following all changes during a development cycle _now_ really should try catching up. We need to get the latest regressions under wraps, and we need to get users trying and reporting their experiences with the current version in order to get the rough edges out and have a chance, where called for, to better tune the default settings for new knobs to production-ready settings. Sounds GTM. I shall not make any further changes to the documentation in 2.17 to give translators a chance to catch up. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3223 in lilypond: Document known issue with Ottavabracketin one voice
Phil Holmes wrote Wednesday, May 08, 2013 6:12 PM Hmm. If I delete all the @googlemail contributors, save the list, add them again as @gmail, save the list, they re-appear as @googlemail. Can't get rid of that address. See previous comment about raising a bug report? I'm not sure a bug report is appropriate. It might be the way our user preferences in Google code are set up. My username display was set to Obscured email address. I've changed it now to Google Account username. Could you please try reloading the contributors again? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3223 in lilypond: Document known issue with Ottava bracketin one voice
Phil, you wrote Wednesday, May 08, 2013 2:43 PM As Graham said, I could do it if I knew what it is. It might be worth raising this as an issue on the Google code tracker? I'm not sure what problem James is encountering, but it might be the same as mine, or at least they might both be fixed in the same way. In the Owner: pulldown list on the Google tracker my email address is listed as tdanielsmu...@googlemail.com. If you could change this to tdanielsmu...@gmail.com I believe my problem would be solved. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3223 in lilypond: Document known issue with Ottava bracketin one voice
Phil, you wrote Done that. For me too :-). Let's hope it works. ?? Looks like there's more to it than that then. The pulldown still shows googlemail for me, you, and some others. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3223 in lilypond: Document known issue with Ottava bracket in one voice
@Trevor - for some reason (discussed previously on dev) the tracker doesn't like emails with googlemail.com but is ok with gmail.com (so I have to manually change it each time for those that still have the googlemail.com address). I am sure someone can go and edit the 'valid owner' list but I don't know who has those permissions. I wish someone would! I have to manually change tdanielsmu...@googlemail.com (which is in the list, but not accepted) to tdanielsmu...@gmail.com (which is not in the list, but is accepted) every time I post to the tracker. And if I get it wrong the issue gets assigned to Adam, as he is the default first in the list. Does anyone apart from Graham have permissions to change this? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Replace transposition example (3159) (issue 8622047)
gra...@percival-music.ca error: old chunk mismatch. Could you re-upload? Done; what causes this? Did I forget to rebase maybe? https://codereview.appspot.com/8622047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES: Countdown for April 20th 2013 - 19:00 GMT
Hi James I just wanted to tell you how invaluable these summaries are when one has several patches in the pipe-lines! I don't think I could keep track of them all without it. Thank you! Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Issue 1698 in lilypond: Slurs and ties are notcorrect over repeats
Comment #65 on issue 1698 by m...@mikesolomon.org: Slurs and ties are not correct over repeats http://code.google.com/p/lilypond/issues/detail?id=1698 These are all good observations. If the patch gets reverted, I'll wait till 2.19 is out before tackling all this. Otherwise, I'll tackle it now. What is the general feeling? Do we want to revert this patch or not before 2.18? Looks like we'd prefer reverting it, Mike - in the interests of getting 2.18 out in a reasonable timescale. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stable release state
David Kastrup wrote Saturday, April 06, 2013 10:07 AM it is clear that master has stopped being suitable for turning into a stable branch. There are several ways forward, none of them particularly endearing. a) cut the stable branch before the last batch of changes and accumulate only bug fixes of simple nature and/or regression fixes into it from now on. This is the option I prefer. The problem with that approach is that we have a _lot_ of outstanding bug fixes, partly because we have not a single developer who could be bothered about catering even for trivial documentation fixes like URL:http://code.google.com/p/lilypond/issues/detail?id=3151 (dormant for two months after reporting, and we have quite a few of that class pending). That basically means that I'll be responsible for fixing all of the Frog-class bugs necessary to get into release state, and also cherry-pick all of those bugs. Not necessarily; with a new stable in the offing doc writers usually knuckle down and try to catch up. Writing documentation while things are unstable can be frustrating. Also developers will be reluctant to see their their work holding up a new stable because of unfixed bugs. The key is to make a start by branching off. There won't be useful input from users of master since master is allowed to seriously diverge and those changes will capture the attention of testers more than long-standing small fixes. Candidate releases should be used for encouraging testing. And I agree with Werner - I'd be happy to see you take overall control of the branched-off stable; leaving master to continue on as before. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: suggestion: change OctavateEight name to ClefTransposition -opinions?
David Kastrup wrote Saturday, April 06, 2013 10:44 PM I think I'd like ClefModifier. Something like +1 Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Suggestions for participating institutions?
Han-Wen Nienhuys wrote Tuesday, March 26, 2013 10:52 AM On Tue, Mar 26, 2013 at 9:52 AM, David Kastrup d...@gnu.org wrote: I met a former colleague in the bus to Chemnitz, and he is at least knowledgeable about EU research programmes. Do people here have ideas about possible institutions who could be made to participate? I think Take in mind that EU research programmes come with an incredible amount of burocracy and require both academic and industry partners, the more the merrier. The projects that get funded are buzzword compliant, but often nobody knows what they set out to do, except divert EU money into the partnering institutions. Have a look at Indeed. When I was involved in bidding for EU research funding in what now seems to be a previous life the process involved many meetings with potential and later actual partners, who have to come from, I believe at least 3 separate countries, plus presentations in Brussels, all involving lots of international travel. And at the end of that expense of time, effort and money we were unsuccessful. This is not like bidding for an Arts grant. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows slurs to break at barlines. (issue 7424049)
m...@mikesolomon.org wrote Monday, March 25, 2013 7:29 AM On 25 mars 2013, at 07:10, k-ohara5...@oco.net wrote: Conceptually, of course, there *are* two pieces. The other piece is probably at the other end of the repeat. The automatic behavior is quite good, so fortunately we will rarely need to look up whatever name the committee approves for the command to make a broken slur. It'd be a shame for this to get stuck in the pipes because we can't figure out a good name. I am indifferent and I don't mind \broken or whatever really. Yes, let's move this on now. If we want the name to apply to the slur as a whole then \broken or \split look good. I'd be happy with that. But as the function is being applied to an end point of a slur, not the whole slur, I actually prefer \free( and \free), to be vocalised as free opening slur and free closing slur, or possibly \floating. But I'll accept anything now to move this on :) Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DS al Fine
Phil Holmes wrote Sunday, March 24, 2013 2:12 PM In the command index of the NR, we have an entry for DS al Fine: http://lilypond.org/doc/v2.17/Documentation/notation/lilypond-index#lilypond-index_cp_letter-D However, it's not mentioned at all in the manual. Should we delete the index entry? It points to a section that describes how to add the Segno sign, which is the target of DS. Could be improved though, I agree. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
