Re: Lyric alignment
On 2/12/11 6:39 AM, Phil Holmes m...@philholmes.net wrote: and go to Spacing of non-staff lines and then mod that a bit, we get the attached file (it's a bit long for in-line, IMO). This produces the output attached. Don't think that's what we should get. Does the team think this is a bug replacing 1161? Well, I don't think this is a code bug. It's a documentation (or understanding) bug. If you replace 3 verses of lyrics with 4, then you will have 1 verse with UP, 2 with CENTER, and 1 with DOWN. Under these conditions, you'll see that CENTER doesn't (and shouldn't) mean to center lyrics between staves. I'm working on some settings that will produce the behavior you'd like to see. I hope to have a snippet posted later today. In the meantime, rather than a new issue, I'd suggest you just post the new code as a comment on 1161. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lyric alignment
On 2/12/11 6:39 AM, Phil Holmes m...@philholmes.net wrote: and go to Spacing of non-staff lines and then mod that a bit, we get the attached file (it's a bit long for in-line, IMO). This produces the output attached. Don't think that's what we should get. Does the team think this is a bug replacing 1161? I've attached a .ly file and its output. I think it gives the desired output. I'd welcome any comments. We could add the music function to ly/music-functions-init.ly, if you think we should. Alternatively, we could add it as-is to Documentation/snippets/new. Thanks, Carl LyricSpacing.ly Description: LyricSpacing.ly LyricSpacing.pdf Description: LyricSpacing.pdf ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1294 - Lyric ties
On 2/12/11 2:55 PM, Phil Holmes m...@philholmes.net wrote: TBH, I'd be disappointed if this issue prevented a release of 2.14. I think it's a regression, but I also think it's a minor feature, and the alternatives are acceptable: stick with 2.12 if you really need lyric ties; or update if you can live with lyric ties that look a little odd. I think that this is equivalent to Graham's news item that says Lyric ties are no longer supported. However, I do believe we shouldn't consign it to the heap of priority-high issues that'll never get looked at. My guess is that Graham won't like this suggestion, but I'd like to accept Patrick's offer to look at this as a serious issue, but I don't think we should raise it as critical-release blocking. If Patrick can't see a way of fixing it, we go with option 2. I'm with Graham on this. If it's a regression, it's Critical, and it's release-blocking, unless we say the regression is intentional. I'm unhappy about the prospects of delaying 2.14, but I'm even more unhappy about telling somebody who cares about lyric ties Use 2.12 instead of 2.14. Once we get to 2.14, we should be able to tell *everybody* Use 2.14 instead of 2.12. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lyric alignment
On 2/16/11 9:31 AM, Trevor Daniels t.dani...@treda.co.uk wrote: Carl Sorensen wrote Saturday, February 12, 2011 9:09 PM I've attached a .ly file and its output. I think it gives the desired output. I'd welcome any comments. Looks useful. What about adding a third argument so 'staff-affinity becomes set within the function too? \setLyricSpacing #25 #3 #DOWN etc I did that in a later version, but then I did even more work. I'm not sure it's needed. I'll put more work out later. We could add the music function to ly/music-functions-init.ly, if you think we should. Alternatively, we could add it as-is to Documentation/snippets/new. I'd prefer to see it as a snippet for now. I suspect it might take a little while for the new spacing controls to settle down, and we might have further thoughts after seeing more real user comments. I agree. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR and docs
On 2/16/11 11:15 AM, Phil Holmes m...@philholmes.net wrote: One of my first jobs hereabouts was adding snippets to the LSR and tagging them with docs. Could someone explain a) the significance of this and b) how snippets are imported from the LSR into the LM and NR? I'm assuming the two are linked, but not sure how. When makelsr.py is run, snippets are created from the LSR into Documentation/snippets. Individual snippets are included in the documentation by a @lilypondfile command. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
On 2/17/11 1:34 PM, Felipe Gonçalves Assis felipeg.as...@gmail.com wrote: Hi Carl, The denominators are not implicit. They are set in the file scm/lily.scm via the call to ly:set-default-scale. Also see lily/scale.cc, lily/include/scale.hh and lily/pitch.cc:89 for how this is implemented. Ahh, OK. Now I understand. I think that the arguments to make-scale should not have implicit steps (which they currently do). They should be lists instead of pairs (or else they should be (step . alteration) pairs. And the value of each number in the list should correspond to the weights in the values list. ((0 0 0) (1 0 0) (2 0 0) (3 -1 0) (4 -1 0) (5 -1 0) (6 -1 0) (6 0 0)) (1 1/2 1/4) That way there is a one-to-one correspondence between the pitch declarations and the weightings. As long as we're adjusting things, I think we ought to be consistent. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
From: lilypond-devel-bounces+c_sorensen=byu@gnu.org [lilypond-devel-bounces+c_sorensen=byu@gnu.org] On Behalf Of Benkő Pál [benko@gmail.com] Sent: Tuesday, February 22, 2011 2:11 PM To: Felipe Gonçalves Assis Cc: lilypond-devel@gnu.org Subject: Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044) Felipe, I'm still far from digesting the whole, but this is really great work! 2. int vs Rational Why not use a sequence of Rationals (rather than ints) to represent the alteration? If we use rational numbers, we can maintain backward compatibility. The re-scaling of the alterations is interesting but unnecessary. They could still be rationals. That is a very reasonable idea. Its main advantage would be, as pointed, in more robust backwards compatibility, as well as ease of implementation. If you decide for that, I can work on a new patch. Further considerations of mine might be found below question 1.1 in http://lists.gnu.org/archive/html/lilypond-devel/2010-12/msg00729.html and after the last quote in http://lists.gnu.org/archive/html/lilypond-devel/2010-12/msg00737.html I'm wholeheartedly for Int's, both as mathematician and as musician. math: if rationals are used, I'd expect to be able to use not only 1/2 but 3/5 etc. mus: I don't care too much for quarter tones, but I do care for e.g. meantone tuning, where graphical output is the same, but MIDI manipulations are very different: the enharmonic interval gis-as is a bit more than half of g-gis. Using hard-coded 1/2 is plain ugly, OTOH I know that 1 is just the coefficient of the augmented prime (aka chromatic half-note). as a programmer: since we switch from numbers to pairs, users using exotic constructs ouside FLAT or SEMI-SHARP should anyway think carefully about converting to the new representation. p ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: MF fonts
On 2/26/11 4:18 AM, James Lowe james.l...@datacore.com wrote: Hello From: lilypond-user-bounces+james.lowe=datacore@gnu.org [lilypond-user-bounces+james.lowe=datacore@gnu.org] on behalf of Tim Sheasby [t...@sheafpublishing.co.za] Sent: 26 February 2011 10:07 To: lilypond-u...@gnu.org Subject: MF fonts mi up nicely with the DO. Can produce appropriate glyph but how do I compile just the final Emmentaler fonts? Tim, First, to answer your question, before doing make, do rm mf/out/* Then do make This will do a full compile, but nothing but the font will need to be recompiled,. Next, you should know that the wider mi was requested by the shape note community in the US to obtain a better optical balance between the different shapes. Not that this means you should use it, but you should know it's not just accidental. If you want to use a narrower mi, it would be nice if you would define an additional mi (maybe miNarrow) and *add* it to the sources, rather than replacing the existing mi. That way we can support you as well as the other people who want the wider mi. Finally, regarding your question about scaling note heads. It is possible to scale a note head differently in x and y if you are using it in a markup, but as far as I know, there is no way to scale it differently in x and y as a note head in the music. Hope this helps, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: MF fonts
On 2/26/11 9:45 AM, Xavier Scheuer x.sche...@gmail.com wrote: On 26 February 2011 17:11, Carl Sorensen c_soren...@byu.edu wrote: Finally, regarding your question about scaling note heads. It is possible to scale a note head differently in x and y if you are using it in a markup, but as far as I know, there is no way to scale it differently in x and y as a note head in the music. I'm not a dev but it should be possible to scale all the note heads (i.e. not only the mi) by using ly:stencil-scale , I think. If one wanted to scale *all* of the note heads, one could do that, by overriding the stencil property of NoteHead. \override NoteHead #'stencil = #(lambda (grob) (ly:stencil-scale (ly:note-head::print grob) x-scale-factor y-scale-factor)) Note that I have *not* tested this code, so it may be slightly wrong in some detail. But the general idea is right. However, this doesn't solve Tim's original problem, I think. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Is it possible to get the code coverage of scheme in lilypond
On 3/4/11 3:39 AM, James Lowe james.l...@datacore.com wrote: Zhang From: zhangxy [mailto:zhangxy290626...@gmail.com] Sent: 04 March 2011 06:55 To: James Lowe Subject: Is it possible to get the code coverage of scheme in lilypond Dear James, Now I want to analyze the test coverage of lilypond. I use gcov for c++, but I couldn't find an effective tool for scheme. Did you have ever done this before? According to the Contributors' Guide, section 9.7, we have scripts designed to test code coverage. I have never used these scripts. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: build system work
On 3/4/11 10:31 AM, Colin Campbell c...@shaw.ca wrote: On 11-03-04 05:55 AM, Phil Holmes wrote: - Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: Lily devel lilypond-devel@gnu.org Sent: Friday, March 04, 2011 12:50 PM Subject: Re: build system work On 3/4/11, Phil Holmes m...@philholmes.net wrote: I'm wondering whether we should actually start with a real Wiki - like the one used for the regtests. Doing this would mean that any work done would be immediately visible, rather than having to pull git and make docs, which would save me oodles of time (a technical phrase). I dislike wikis; it's yet one more markup format to learn, I can't easily edit them with my normal text editor, they rely on having an internet connection, there's no permanent record, and they don't fit into the current development skills used for lilypond. Also, once you've built the docs once -- and if there's no build system changes from the translations -- then rebuilding the CG is really fast, since the CG doesn't include any @lilypond example. However, if you and Colin would find it easier to work on a wiki, then by all means do so. There's no point adding artificial constraints to this task; it's hard enough as it is. But please move material into the CG from time to time (say, once a month?), otherwise we'll lose whatever documentation you two write. I'll wait for Colin's thoughts. I'm the noob here, so I'll defer to greater wisdom. A couple of thoughts do occur, though: using the CG to collect discoveries, insights etc. has the virtues Graham points out, those of permanence and use of existing technologies, but it risks limiting contributions from those who don't build docs more than once. A wiki has the advantage of possibly wider input and access, but requires separate infrastructure. As a somewhat in between approach, I think we should try to keep the discussion visible to the devels and Frogs as much as possible, so they can feel free to chime in. That suggests a special subject line on postings to -devel, or perhaps a separate list (Google group?), with filters on local e-maiul clients, if desired. Patches can go to reitveld, again with a special subject line. Work would be done in a new branch of the git repo. Perhaps Phil would take the lead on the project, and coordinate updates to the CG and git master. My preference would be to have an issue on google code, with a priority of low, under which one-time users could post their experiences. I'd prefer *not* to put patches for the CG on Rietveld; I'd rather just see them pushed. I think there's no sense discussing them at this point. Better just to capture them. I don't think we need a different branch. We have a different section in the CG, so this won't mess up master. By putting the changes in master, they'll automatically build daily on kainhofer, so if we have some who don't have build capability on their machines, they can still see updated docs. The main difficulty I see with Graham's original proposed workflow is that not everybody has git push access, so we need somebody who will volunteer to push patches from those without access. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: build system work
On 3/4/11 11:09 AM, Colin Campbell c...@shaw.ca wrote: On 11-03-04 10:54 AM, Carl Sorensen wrote: On 3/4/11 10:31 AM, Colin Campbellc...@shaw.ca wrote: I'm the noob here, so I'll defer to greater wisdom. A couple of thoughts do occur, though: using the CG to collect discoveries, insights etc. has the virtues Graham points out, those of permanence and use of existing technologies, but it risks limiting contributions from those who don't build docs more than once. A wiki has the advantage of possibly wider input and access, but requires separate infrastructure. As a somewhat in between approach, I think we should try to keep the discussion visible to the devels and Frogs as much as possible, so they can feel free to chime in. That suggests a special subject line on postings to -devel, or perhaps a separate list (Google group?), with filters on local e-maiul clients, if desired. Patches can go to reitveld, again with a special subject line. Work would be done in a new branch of the git repo. Perhaps Phil would take the lead on the project, and coordinate updates to the CG and git master. My preference would be to have an issue on google code, with a priority of low, under which one-time users could post their experiences. I'd prefer *not* to put patches for the CG on Rietveld; I'd rather just see them pushed. I think there's no sense discussing them at this point. Better just to capture them. I don't think we need a different branch. We have a different section in the CG, so this won't mess up master. By putting the changes in master, they'll automatically build daily on kainhofer, so if we have some who don't have build capability on their machines, they can still see updated docs. The main difficulty I see with Graham's original proposed workflow is that not everybody has git push access, so we need somebody who will volunteer to push patches from those without access. I think this project goes beyond just updating the docs, Carl: the build system itself is in need of a complete rebuild, particularly for the doc section, but even the main part has its . . . peculiarities. It seems that the project *will* require a separate branch from master, because we'll be working on the actual build process, not just describing it. I absolutely agree. But Graham's proposal was that we *not* start working on the build process yet. The proposal was to start by documenting what the build system does. And he estimated that the documentation process would take 50 hours of development time. My comments are only about the documentation process, which I think is a healthy way to start. Once we are ready to start the revision to the build system, whether it's cleaning up the existing system, or moving to waf or scons, or something else entirely, we'll certainly need a separate branch, and we'll need patches on Rietveld. But I don't think that project needs any visibility on frogs -- it's way over the head of frogs. Anybody who is contributing to build system revision is clearly a developer, IMO. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: build system work
On 3/4/11 1:05 PM, Graham Percival gra...@percival-music.ca wrote: On Fri, Mar 04, 2011 at 11:38:19AM -0700, Carl Sorensen wrote: On 3/4/11 11:09 AM, Colin Campbell c...@shaw.ca wrote: On 11-03-04 10:54 AM, Carl Sorensen wrote: On 3/4/11 10:31 AM, Colin Campbellc...@shaw.ca wrote: [subject: wiki or not?] I'm the noob here, so I'll defer to greater wisdom. Ok, for the record: we're still gathering opinions about wiki vs. CG. The most important opinions come from the people offering to actually do the work, of course. So far, that means Colin and Phil. My preference would be to have an issue on google code, with a priority of low, under which one-time users could post their experiences. Please no. We'll be gathering approximately 15 pdf-pages of docs; having that amount of info as a series of comments on google code wouldn't work. (unless I'm misunderstanding this comment...?) I think you're misunderstanding this comment. Absolutely we should not have a google code issue for the main discussion of the new CG content. However, if there were somebody who had a problem with the build system (not somebody who was trying to fix it), they'd have a place to make a comment. That way we would capture their input without them having to patch the CG. The proposal was to start by documenting what the build system does. And he estimated that the documentation process would take 50 hours of development time. Yes. But I don't think that project needs any visibility on frogs -- it's way over the head of frogs. Anybody who is contributing to build system revision is clearly a developer, IMO. Yes and no. The only two volunteers so far clearly *are* Frogs. But by the time they are ready to *fix* the build system, they won't be, because they will have spent enough time working on the documentation of the build system they'll be experts, albeit in one area of contribution. But many of us are experts in only one or two areas of contribution. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: shortened flags affair, part 3 - 32nds stem length
On 3/4/11 4:42 PM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: Hi, Therefore i call for shortening 32nd unbeamed notes by 0.25 ss. Do you agree? I can't see any downside to the proposal. So I agree. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: shortened flags affair, part 4 - downstem 8th flag
On 3/5/11 4:12 PM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: Hi, Short question: do you agree to make downstem 8th flag shorter, as in single downstem proposed.png? This way it won't blend into notehead. This would be consistent with looks of other flags, see gaps.png. I know that many fonts have flags sticking into the noteheads, but: - these flags are usually thinner than ours and therefore make different impression, - if they stick into noteheads, they always do so, - in my opinion score is easier to read when there is a gap between flag and notehead. I've seen a finale user complaining about it too. I recommend reading http://forum.makemusic.com/default.aspx?f=6=209535=209731#m209729 http://forum.makemusic.com/default.aspx?f=6m=209535g=209731#m209729 - we can learn something from his post. I prefer the current. It is consistent with Read's recommendations. But I don't feel strongly about it. As far as the comments he has about his music, I'd like to see his source code. It looks to me like he's forcing a non-optimal layout; the note close to the bar line in measure 6 is not something that LilyPond will do by default now (and I doubt it did in 2.10.33, either). Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: shortened flags affair, part 4 - downstem 8th flag
On 3/6/11 2:44 AM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: 2011/3/6 Carl Sorensen c_soren...@byu.edu: bars 8,9,11: ugly slurs, bad placement in bar 8 I agree with 9 and 11 having ugly slurs -- too sharply peaked. I've changed the slur scoring so that it doesn't try to move slurs away from staff lines. It cleans up the ugly slurs, at the expense of letting the slurs touch the line. I've attached a pdf with those changes. Looks great! And in fact these slurs don't touch staff lines, there is a small clearance. I printed it and it looks ok (however, my printer prints *very* badly and shaky now, so it should be double-checked). I've looked at very large magnifications; the slurs in measures 8, 9, 10, and 11 all touch on one end. I don't think 8 is an ugly slur, or that the placement is bad. Can you tell me what is ugly about it, and why the placement is bad? I'm not sure. Perhaps the left end is too high. I attach output from finale 2008 demo, i'd say that something between this and current Lily output would be optimal. Looking at this comparison reminds me of how much I prefer the rounded ends of the LilyPond slurs to the pointed slurs of Finale. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Using #(define fonts) gives me an ill-looking feta font
On Mar 9, 2011, at 12:14 AM, James Lowe james.l...@datacore.com wrote: Hello, I am using Mac OS X (in case that matters) and I am having an issue where using the following construct in a \paper block: myStaffSize = #24 #(define fonts (make-pango-font-tree Baskerville Optima Courier (/ myStaffSize 24))) Should be (/ myStaffSize 20). HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond mensural notation
On 3/10/11 10:39 AM, Benkő Pál benko@gmail.com wrote: Dear Mr Klein, forwarding your request to the development community. Could I ask you for other improvement? I need two new mensural clef glyphs, which you can see in this picture: http://gregoriana.sk/gg/wp-content/uploads/p1020924.png The G and C clefs are what I am interested in. If you could do it, I can offer you to pay for it. Would it be possible? Sorry, but I'm not a font guru; to me the existing petrucci clefs are close enough. I understand the font system well enough that I could probably create fonts for the desired clefs. However, on the scan you sent, I'm not sure which glyphs are the desired clefs. If you could get a closer shot of the desired clefs, I'd be happy to have a discussion with you about how much you're willing to pay for the clefs. Thanks, Carl Sorensen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: shortened flags affair, part 7 - downstem full-length 64th and 128th flags
On 3/15/11 3:24 PM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: Hi, there is quite a lot of space between flag and the notehead in case of downstem 64th and 128th notes (at least compared to 16th and 32nd flags). I *suppose* these flags were made this way because they were intended for use with both shortened stems and full-length stems, and if the gaps were smaller, the flags would look bad on shortened stems. However, we are going to have dedicated flags for shorter stems soon, so maybe we want to tweak the design of 64th and 128th downstem flags to something roughly like suggestion.png? I prefer the new ones to the old ones, but I think that all of them need further adjustment. In the words of Read (p. 80) For each additional flag beyond two, the stem is extended by two staff degrees [1 staff space -- my addition], and the new flag is drawn parallel to the previous one(s), with the additional curved line joining the curved line of the first flag. In the 64th and 128th flags currently in the Feta font, the lines are not parallel at all, and I think that makes the flags look unbalanced. Thanks, Carl P.S. Janek, Amazon has used copies of Read in paperback for $9.97. At that price it may be worth purchasing. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: shortened flags affair, part 7 - downstem full-length 64th and 128th flags
On 3/18/11 5:23 AM, Phil Holmes m...@philholmes.net wrote: Janek, I prefer the newer ones, although I doubt I'll use them too often in real music! However, I was looking at my Gardner Read and think that, strictly, all the flag shapes are a little wrong according to his rules. The quaver flag is too short, and the shorter note flags don't join the stem properly. To be honest I'm not too bothered, but wondered what other people think. Please see the attached scan from his book, which is a few excerpts from pages stuck together. I think Read's example flags are very inconsistent, so it's hard to decide what the details of the flags should be. I've looked throughout his book, and the flags change from occurrence to occurrence. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Removing parser DIGIT (was: PATCH - DOC: Added @knownissue to NR for fingering
On 3/22/11 11:20 AM, David Kastrup d...@gnu.org wrote: Graham Percival gra...@percival-music.ca writes: On Sat, Mar 12, 2011 at 12:48:21PM +0100, David Kastrup wrote: Perhaps i'll aim for obliterating DIGIT altogether. I certainly can't think of any case in which we actually need/want a DIGIT. I see that DIGIT was added in release/0.1.49, back in 1998-03-17, as part of the initial version of lexer.ll and parser.yy. Maybe it was just part of some template code that they used? Certainly a lot has changed in the past 13 years. :) I definitely think it's worth investigating what happens if we remove DIGIT entirely. This. URL:http://codereview.appspot.com/4311041 Please improve/discuss. This looks totally insane but does not actually change the existing absurd realities for single-digit unsigned numbers. I consider this patch the wrong way and hope everybody agrees, but it _mirrors_ the current behavior for single-digit unsigned numbers. Well, if there is no other way, then I could see that we could torture this to make it work properly. I'm way over my head in understanding the lexer and the parser, so my input is probably worth even less than you've paid for it, but would it be possible to create a finger_event as one of the post_event class and remove it from gen_text_def? To my untrained eye, it seems that that might solve the problem of making the fingering event from the assignment operator. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond and visually impaired accessibility
On 3/24/11 7:11 AM, m...@apollinemike.com m...@apollinemike.com wrote: I got this response from Haipeng (who currently has to rely on LilyPond's playback to catch errors) and I get the sense that the best option would be creating a primitive form of lily - musicxml conversion. Even if this cannot encapsulate the full richness of LilyPond, I think that it is the best solution that can help the most people. I think that a lily - musicxml conversion would be very helpful. And if it started out primitive, it could certainly be enhanced. You're certainly a much more productive programmer than me, given all the changes you've made in lilypond. But I can't imagine having any kind of musicxml output in 10 hours. Please go for it! Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: List of all lilypond keywords
On 3/25/11 6:02 AM, Matthias Neuhaus matthias.neuh...@googlemail.com wrote: Hi everyone, i'm new to this list, and i hope to find a little bit of help here. I am using lilypond for a while now, mainly on ubuntu. Because my main OS is windows, i was searching for a simple lilypond-editor on windows, but i didn't find anything. Therefore i decided to write a new, simple editor for windows or at least create a plugin for an existing one (like Notepad++ e.g.) with syntax highlighting. What i need for this, is a list of all lilypond keywords, commands etc. I read through the contributors manual and a few others, but i didn't find anything like a script or so, that would extract all the keywords from the source code. So, is there any simple way to do this? There is a file containing the keywords that is used for the emacs mode, at [LILYPOND]/elisp/out/lilypond-words.el where [LILYPOND] is the base directory where lilypond is installed. This list is automatically-generated during the build process, but I've never tracked down how. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: using the feta font in a GPL2 application
On 3/28/11 7:06 AM, Florian Jung florian.a.j...@web.de wrote: Hi we'd like to use the feta font, or actually single glyphs rendered to png-files, in a muse2, a GPL2 linux sequencer. i've added a score editor to the sequencer, however it's using the feta font, and we don't know if we may use a GPL3-ed font in our GPL2 application. may we :)? You can certainly use the older version of feta in a GPL2 app (it was licensed under GPL2). The change was made 2009-11-25. As far as permission to use it the current font under GPL2, I think Han-Wen and Jan need to give that permission. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: using the feta font in a GPL2 application
On 3/28/11 12:48 PM, Florian Jung florian.a.j...@web.de wrote: Am 28.03.2011 20:21, schrieb Han-Wen Nienhuys: On Mon, Mar 28, 2011 at 11:08 AM, Graham Percival gra...@percival-music.ca wrote: As far as permission to use it the current font under GPL2, I think Han-Wen and Jan need to give that permission. i assume Han-Wen and Jan also read that mailing list, so i'm asking for permission to use the current font :) I believe that *everybody* who has worked on the feta fonts would need to give that permission. You can find this list by looking at the git changelog messages for those files, but I do not recommend going further with this. I really recommend that you either use the old GPLv2 feta fonts, or use GPLv3 (possibly 3+) for your application. It's unfortunate that copyright law gets in the way like this, but it does. Well, only if anyone decides to make an issue of this, and it's not like we claim any sort of rights over images of the font when we put them on paper or screen. I think you can just go ahead with muse2. I'd recommend using freetype for the rendering instead btw, as you'll be more flexible wrt symbol sizes on screens of different device resolutions. may i read that as a feel free to use the font, if someone decides that he doesn't like that, he will kindly ask you to use another font instead of killing you immediately :)? I am not a lawyer, but it seems to me that the font could be GPL3 and the rest of the package could be GPL2, because the font is separable from the rest of the package. The font isn't the program, it's a tool used by the program. So I don't know why you couldn't distribute Feta under GPL3 along with muse2 under GPL2. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: using the feta font in a GPL2 application
On 3/29/11 12:10 PM, Han-Wen Nienhuys hanw...@gmail.com wrote: On Mon, Mar 28, 2011 at 3:48 PM, Florian Jung florian.a.j...@web.de wrote: As far as permission to use it the current font under GPL2, I think Han-Wen and Jan need to give that permission. i assume Han-Wen and Jan also read that mailing list, so i'm asking for permission to use the current font :) I believe that *everybody* who has worked on the feta fonts would need to give that permission. You can find this list by looking at the git changelog messages for those files, but I do not recommend going further with this. I really recommend that you either use the old GPLv2 feta fonts, or use GPLv3 (possibly 3+) for your application. It's unfortunate that copyright law gets in the way like this, but it does. Well, only if anyone decides to make an issue of this, and it's not like we claim any sort of rights over images of the font when we put them on paper or screen. I think you can just go ahead with muse2. I'd recommend using freetype for the rendering instead btw, as you'll be more flexible wrt symbol sizes on screens of different device resolutions. may i read that as a feel free to use the font, if someone decides that he doesn't like that, he will kindly ask you to use another font instead of killing you immediately :)? This reads as: please stop fussing over tiny differences in GPL versions; if you have a good idea, just do it. I don't think we can claim GPL rights over bitmaps of the font anyway. Then again IANAL, and neither is anyone else on the list. I did however, write the biggest portion of the feta code over which we are agonizing. According to the FSF, this is correct. The font face is not copyrightable. But outlines may be. http://www.fsf.org/blogs/licensing/20050425novalis Sounds like Han-Wen's answer is perfect. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: reference-point example needs updating
On 4/7/11 4:08 PM, Mark Polesky markpole...@yahoo.com wrote: Carl (et al.), I think your commit a3b2f9e changed the appearance of the image in NR 4.4.1 that demonstrates reference points: http://lilypond.org/doc/v2.13/Documentation/notation/flexible-vertical-spacing -within-systems#within_002dsystem-spacing-properties The reference points for ChordNames and NoteNames used to be the baseline. If this has changed, the source code for the image (and its accompanying documentation) needs to be updated, I think. I don't have time to do it myself, but I thought I'd point it out. The baseline hasn't changed, but the fact that by default, non-staff contexts reserve vertical spacing. You're right. The source code needs to change. The non-staff contexts above the staff needed to have their affinities set to DOWN. pushed in 5e9d7b07e1da Thanks, Carl git com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: branching
On 4/15/11 8:29 AM, Graham Percival gra...@percival-music.ca wrote: On Fri, Apr 15, 2011 at 11:08:08AM -0300, Han-Wen Nienhuys wrote: On Fri, Apr 15, 2011 at 7:30 AM, m...@apollinemike.com m...@apollinemike.com wrote: this issue was exposed due to a (seemingly innocuous) one-line change by Mike. Can I ask that you branch off the 2.14 branch so the release candidate does not get disturbed by other one-liners with unintended effects? If you don't branch off a stable branch, 2.14 will never get finished. The beauty of branching off is that nobody needs to hold off anything. You just continue to put stuff in master (2.15.0), and cherry-pick whatever needs to go to 2.14. But I suppose we can come back to that debate later. For now, who is volunteering to handle the cherry-picking? I will cherry pick. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: branching
On 4/15/11 9:23 AM, Graham Percival gra...@percival-music.ca wrote: On Fri, Apr 15, 2011 at 08:33:20AM -0600, Carl Sorensen wrote: On 4/15/11 8:29 AM, Graham Percival gra...@percival-music.ca wrote: But I suppose we can come back to that debate later. For now, who is volunteering to handle the cherry-picking? I will cherry pick. Great! I'll make another unstable release tomorrow and merge it into stable/2.14, and thereafter you can cherry-pick at will. I'll make all future 2.13 releases from stable/2.14. Just to be sure I understand correctly, the only things I will cherry-pick into stable/2.14 will be bugfixes for critical bugs. Let me know if this isn't right. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: branching
On 4/15/11 9:23 AM, Graham Percival gra...@percival-music.ca wrote: On Fri, Apr 15, 2011 at 08:33:20AM -0600, Carl Sorensen wrote: On 4/15/11 8:29 AM, Graham Percival gra...@percival-music.ca wrote: But I suppose we can come back to that debate later. For now, who is volunteering to handle the cherry-picking? I will cherry pick. Great! I'll make another unstable release tomorrow and merge it into stable/2.14, and thereafter you can cherry-pick at will. I'll make all future 2.13 releases from stable/2.14. How shall we report issues with the unstable development version? I think that's the major problem I see with branching stable. Should a bug report be filed with a tag unstable, and a commit instead of a version? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: branching
On 4/15/11 12:32 PM, Matthias Kilian k...@outback.escape.de wrote: [random notes from soneone who is *not* actively hacking on LilyPond, so feel free to ignore it ;-)] On Fri, Apr 15, 2011 at 03:29:52PM +0100, Graham Percival wrote: The reason that I'm pessimistic is that we racked up a huge amount of technical debt (i.e. bugs) during 2.11 and the early phase of 2.13. I'm concerned that if we don't have regular releases, the unstable branch is going to accumilate bugs. Well, I think I've written this a few months ago: (stable) releases *must* happen more often (at least one or two times a year) if you want to be able to cope with stable and unstable. I am also too tired to fight over it right now, but I also think that this is the wrong model of branching. There's basically two ways: 1. keep master in a ready-to-release mode at all times; any serious bug gets reverted or fixed ASAP. Unstable development happens on separate branches, which are merged to master when they're ready. 2. toss whatever garbage you want onto master, and make a stable branch where a bunch of poor suckers cleans up the branch until it's ready for a release. 1. is the way to go. Sure, it would put some pressure on people working on big changes, which kind of sucks (it could even slow down implementing cool new stuff). On the other hand, it enforces smaller steps towards new features, which is good (easier to track down regressions, easier to *understand* what's going on). This is what we've been doing for the past 4 months or more. How do we define the difference between stable development and unstable development? It seems to me that stable development means we pass the regtests -- we've been doing that for at least a couple of years. But we still end up with regressions when users test the code beyond what the developers have tested. As long as we have a policy that any regression will delay a stable release for two weeks, it seems to me that we *must* stop adding features in order to get a stable release. We can't prevent unintended regressions. OTOH, if the standard for ready-to-release were make check succeeds and no segfaults have been identified, then we've been ready to release a stable version for a long time now. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stable/2.14 and fixed_2_x_y
On 4/16/11 5:02 AM, Graham Percival gra...@percival-music.ca wrote: stable/2.14 has been branched. Carl is the only person who should touch that branch, other than me making release announcements and updating the version number. All future 2.13.x releases will be made from stable/2.14. If you fix something in the issue tracker, mark it fixed_2_15_0. Carl will add fixed_2_13_61, _62, _63, _64, etc., when he cherry-picks the patch to stable/2.14. Also, please set the status to Started, rather than Fixed. I'll set it to Fixed when I cherry-pick it to stable/2.14. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: branching
On 4/16/11 12:50 PM, Han-Wen Nienhuys hanw...@gmail.com wrote: On Fri, Apr 15, 2011 at 11:29 AM, Graham Percival gra...@percival-music.ca wrote: The beauty of branching off is that nobody needs to hold off anything. You just continue to put stuff in master (2.15.0), and cherry-pick whatever needs to go to 2.14. I am pessimistic about this, but let's ask for volunteers. Who wants to cherry-pick stuff? The reason that I'm pessimistic is that we racked up a huge amount of technical debt (i.e. bugs) during 2.11 and the early phase of 2.13. I'm concerned that if we don't have regular releases, the unstable branch is going to accumilate bugs. I am also too tired to fight over it right now, but I also think that this is the wrong model of branching. There's basically two ways: 1. keep master in a ready-to-release mode at all times; any serious bug gets reverted or fixed ASAP. Unstable development happens on separate branches, which are merged to master when they're ready. We are doing this, with the ready-to-release criterion being the regtest passing. I propose we stick to this schema. My proposal is that ready-to-release still is not strict enough for stable, so 2.14 version should be coming from something which moves slower than the master branch. So does this mean we need three branches? stable (currently 2.12.x) stable beta (currently stable/2.14) development (currently 2.13.x) stable beta and development should pass regtests. stable beta will be ready-to-release when there are no critical bugs left. After some publishing of stable beta with no new critical issues, stable beta will become stable. At this point, stable beta will be the release candidate for the next stable version. Any patches that don't eliminate old syntax and don't break regtests can be cherry-picked onto stable beta. It seems to me that we ought to have three releases available: stable -- demonstrated to work properly stable beta -- all syntax from stable works, passes regtests, but not demonstrated to be critical regression free. Should be acceptable for general release, but not for production work. development -- passes regtests. Recommended for developers and adventurous users, but possibility exists for syntax changes. Does this seem feasible? Carl -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stable/2.14 and fixed_2_x_y
On 4/17/11 2:33 AM, Graham Percival gra...@percival-music.ca wrote: On Sat, Apr 16, 2011 at 12:01:43PM -0600, Carl Sorensen wrote: On 4/16/11 5:02 AM, Graham Percival gra...@percival-music.ca wrote: If you fix something in the issue tracker, mark it fixed_2_15_0. Carl will add fixed_2_13_61, _62, _63, _64, etc., when he cherry-picks the patch to stable/2.14. Also, please set the status to Started, rather than Fixed. I'll set it to Fixed when I cherry-pick it to stable/2.14. I disagree; for example, look at http://code.google.com/p/lilypond/issues/detail?id=1609 If we only mark it started, then it will still show up in the general open bugs list, and in the patches left to review list. Instead, I think we should mark something as fixed if the patch is in git master, but add a backport label. You will remove that label when you actually do backport it, and I'll check to see if there's anything with backport before making any releases. OK, I like this idea. But I reserve the right to remove the backport label if I don't feel like it's best to backport a given patch. One consequence of this is that the bug squad's verify step becomes more important, but at least it doesn't drive a huge spike through normal development and bugs. Verify can't happen until it's backported. So we'll have a large number of issues that are fixed but not verified. I'm OK with that; I can do a grid view of issues to verify to see what needs to be dealt with. But it would be nice if the Bug Squad could verify any issues that are fixed pre 2.13.61 so that the list of issues to verify is the backport candidates. NB: I'm still using Carl's policy unless he changes his mind. When making the patches countdown or looking at the existing Critical items, I can just manually check every item. There should be less than 10 such items at any time, so it's not a huge amount of extra work. I agree with this policy in place of my original policy. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stable/2.14 and fixed_2_x_y
On 4/17/11 5:27 AM, Graham Percival gra...@percival-music.ca wrote: On Sun, Apr 17, 2011 at 05:15:00AM -0600, Carl Sorensen wrote: But it would be nice if the Bug Squad could verify any issues that are fixed pre 2.13.61 so that the list of issues to verify is the backport candidates. Given the existing difficulties with the bug squad, there's no way that I can support asking them to play with git master. I think you misunderstood my comment. There are currently 9 issues that are listed as Fixed, of which only 2 by my count are awaiting a new release. If that list could be cleared, it would be helpful. As I said, I'm looking to have things verified if they are marked fixed_2_13_60 or earlier. But I recognize that we have limited resources, so if this can't happen, it's not the end of the world. This is just a request. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [tablatures] snippet Slides in tablature, NR 2.4.1
On 4/17/11 2:03 PM, Federico Bruni fedel...@gmail.com wrote: However my question was about the whiteout property of TabNoteHead. IIRC, last year when I made a TabNoteHead transparent I could see a small white area in place of TabNoteHead, because the whiteout property of TabNoteHead was set to true by default (my blind guess). So I had to add \once \override TabNoteHead #'whiteout = ##f to my snippet. Now this happens no more, the override is no more needed. I guess that's because now the whiteout property is handled differently? I'm pretty sure that is true. The TabNoteHead used to be a composite of multiple stencils that then had whiteout added. Now the TabNoteHead is a single stencil, and if the head is transparent, no whiteout is drawn. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Compressabilty
On 4/22/11 1:32 PM, Olivier Chamley olivier.cham...@free.fr wrote:
Hi everybody...
I have some difficulties to understand the minimum-distance setting, I just
hopped that somebody could explain it to me.
According to current documentation, minimum-distance is the smallest allowable
vertical distance, and basic-distance the default one. So with the following
code, I would expect the staffs to compress down to being stuck together until
they don't fit in one page, where they would go back to basic-distance spacing
on two pages.
\include italiano.ly
\paper { system-system-spacing = #'((basic-distance . 12) (minimum-
distance . 0) (padding . 0) (stretchability . 1e7))
ragged-right = ##t }
\score { \new Staff { \unfoldRepeats { \repeat volta 15 \relative do'' { do4
re mi fa \break } } } }
This is not the case ! With the above example, I get two pages. Setting
minimum-distance to 10 does not change anything. And having both basic-
distance and minimum-distance to 0, I can have 20 staffs in page...
Yes, because basic-distance is the distance it tries to have. The layout
will always try to be close to basic-distance; in trying to make things fit
better in can get as close as minimum-distance. But fitting at
minimum-distance is considered fitting much worse than at basic-distance.
Spacing will not generally go to minimum-distance, and certainly not to
minimum-distance on all staves.
HTH,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows glissandi between chords (issue4442082)
On 4/26/11 5:55 AM, m...@apollinemike.com m...@apollinemike.com wrote: On Apr 26, 2011, at 7:30 AM, carl.d.soren...@gmail.com wrote: File scm/define-grob-properties.scm (right): http://codereview.appspot.com/4442082/diff/3001/scm/define-grob-properties.sc m#newcode412 scm/define-grob-properties.scm:412: (glissando-index ,integer? The index of a glissando in its note It seems to me like this should be an internal grob property, rather than a user grob property, and that it need not be part of an interface. I can't imagine how it ought to be tweaked by the user. Even if a property is moved to an internal property in define-grob-properties.scm, doesn't it still need to be declared in an interface so that internals.texi may be written? As far as I can see, most of the internal properties don't have interfaces. And they don't show up in internals.texi. I think I'm OK with this as a policy -- internal properties aren't to be changed by the user. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows glissandi between chords (issue4442082)
On 4/26/11 11:00 AM, m...@apollinemike.com m...@apollinemike.com wrote: On Apr 26, 2011, at 7:55 AM, m...@apollinemike.com wrote: On Apr 26, 2011, at 7:30 AM, carl.d.soren...@gmail.com wrote: The old behavior can be achieved via: \set glissandoMap = #'((0 . 0)) What would be the appropriate .ly file in ly/ to put this in? Alternatively, we could write a convert-ly rule that changes all \glissando to \set glissandoMap = #'((0 . 0)) \glissando \unset glissandoMap. I think that the majority of users who write glissandi between chords will want full-chord glissandi. So, it seems that #'() should be the default value for glissandoMap (as it is in the proposed patch). If all notes should be part of the glissando, then I think we should *not* write a convert-ly rule. Rather, we should make sure that the new setting is noted in changes, and we should make sure the new behavior is documented. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows glissandi between chords (issue4442082)
On 4/28/11 6:35 AM, Carl Sorensen c_soren...@byu.edu wrote: On 4/27/11 5:00 PM, mts...@gmail.com mts...@gmail.com wrote: On 2011/04/26 17:11:02, c_sorensen_byu.edu wrote: On 4/26/11 11:00 AM, m...@apollinemike.com mailto:m...@apollinemike.com wrote: On Apr 26, 2011, at 7:55 AM, mailto:m...@apollinemike.com wrote: On Apr 26, 2011, at 7:30 AM, mailto:carl.d.soren...@gmail.com wrote: The old behavior can be achieved via: \set glissandoMap = #'((0 . 0)) What would be the appropriate .ly file in ly/ to put this in? Alternatively, we could write a convert-ly rule that changes all \glissando to \set glissandoMap = #'((0 . 0)) \glissando \unset glissandoMap. I think that the majority of users who write glissandi between chords will want full-chord glissandi. So, it seems that #'() should be the default value for glissandoMap (as it is in the proposed patch). If all notes should be part of the glissando, then I think we should *not* write a convert-ly rule. Rather, we should make sure that the new setting is noted in changes, and we should make sure the new behavior is documented. Thanks, Carl Hey Carl et al, Before I push this patch, are there any further questions/concerns regarding it? Specifically: (a) Are people all right with glissando'ed chords being default behavior (given how ties work in lilypond, this seems to make sense)? I'm fine with it, but I'm not a good reference -- my experience with music is too limited. (b) With respect to my previous question about internal-properties, is it ok to have glissando-index in define-grob-properties.scm and to put it in the glissando-interface? If not, where should I put it? Personally, I think it should be in define-grob-properties.scm as an internal property, and not in an interface. There are lots of examples of properties like that, as far as I can see. For example, least-squares-dy, maybe-loose, positioning-done, important-column-ranks, pure-Y-extent. In my mind, we don't have interfaces to things that the user couldn't set properly, and glissando-index is one of those. We can read without an interface, we just can't set without an interface. But I could easily be wrong on this. In fact, I was wrong on this. Please ignore all my comments on the interface. Mike's approach is correct. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES: 48-hour notice for rest collisions and faulty warnings in articulate
On 4/28/11 5:52 AM, Graham Percival gra...@percival-music.ca wrote: Sat, 13:00. Allows glissandi between chords http://codereview.appspot.com/4442083/ Please include http://codereview.appspot.com/066/ at the same time as this patch. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: branching
On 4/29/11 9:55 AM, Joseph Wakeling joseph.wakel...@webdrake.net wrote: On 04/15/2011 07:05 PM, Carl Sorensen wrote: Just to be sure I understand correctly, the only things I will cherry-pick into stable/2.14 will be bugfixes for critical bugs. Just as a remark, I wonder if you may find it easier to adopt an alternative workflow: -- bugfix gets applied first in 2.14 branch -- bugfix gets merged into master dev branch since that probably reduces the amount of cherry-picking that's needed -- I expect that probably almost every patch applied to 2.14 is also applicable to dev, but not vice versa. This might work, but fails to meet the major criterion of the proposed branching scheme. The proposal is to make 2.14 stable. Actually, I think your final comment is backwards. Every patch is applicable to dev, but only some are applicable to 2.14. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Backporting / stable
So it appears that the biggest source of Critical bugs, and the thing that is holding up release of 2.14, is the beam-collision-engraver. Should we try to remove the beam-collision-engraver from 2.14.0? Or should we wait for it to settle itself out and make it part of 2.14.0? I can see arguments for both. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Backporting / stable
On 4/30/11 8:07 AM, Phil Holmes m...@philholmes.net wrote: - Original Message - From: Carl Sorensen c_soren...@byu.edu To: Lily devel lilypond-devel@gnu.org Sent: Saturday, April 30, 2011 1:59 PM Subject: Backporting / stable So it appears that the biggest source of Critical bugs, and the thing that is holding up release of 2.14, is the beam-collision-engraver. Should we try to remove the beam-collision-engraver from 2.14.0? Or should we wait for it to settle itself out and make it part of 2.14.0? I can see arguments for both. Thanks, Carl My own view is that getting the beam collisions improved is now a major feature of 2.14 and if it can be fixed in weeks rather than months it would be better to wait. I guess the counter-argument is that gives you lots of extra work :-( I actually think it would be more work to remove the beam-collision-engraver than to keep it in. But at this point I expect it to be months before we are sure we're clear of Critical bugs in beam-collision engraver. Beaming affects literally every piece of music. And there are so many beam cases that it seems to me to be unlikely that we'll be able to wring this all out in a time frame of say 6 weeks. I expect it to be more like 4-6 months. We have had beam-collision-engraver in git since Feb. 9. We still have Critical issues related to it. Please don't consider this a complaint about the beam-collision-engraver. I think it's a *great* feature, and I'm glad Mike has jumped in to tackle it. It's just *extremely* hard to verify something that affect so much music in so many different ways. We have what we think are good regtests, and then we find something new that we haven't covered. But I'm certainly willing to wait for a bit to see if we can get rid of all the critical bugs. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Backporting / stable
On 4/30/11 8:49 AM, Graham Percival gra...@percival-music.ca wrote: On Sat, Apr 30, 2011 at 08:37:01AM -0600, Carl Sorensen wrote: I actually think it would be more work to remove the beam-collision-engraver than to keep it in. But at this point I expect it to be months before we are sure we're clear of Critical bugs in beam-collision engraver. We don't need to be sure that we're clear. All we need... or at least, all I want before uploading the official 2.14.0... is for one week without *known* Critical bugs. Right, but we haven't had that happen with the beaming since beam-collision-engraver was added. Of course 2.14.0 will have unknown Critical bugs in it; there's just no realistic way to avoid that, so we're not even going to try (other than offering release candidates). Beaming affects literally every piece of music. And there are so many beam cases that it seems to me to be unlikely that we'll be able to wring this all out in a time frame of say 6 weeks. I expect it to be more like 4-6 months. We have had beam-collision-engraver in git since Feb. 9. We still have Critical issues related to it. Well, I'm on vacation for most of May, so we're looking at a June release at the earliest, in any case. So it seems that we've got some time to wait on this decision. I'll just pretend I never raised the issue, and when you get back from vacation if we're still adding Critical beaming bugs, we'll have the discussion again. (unless I set up ssh access from outside the university and leave my computer on, which I'm considering... but it would kind-of suck to spend my evenings in Paris and Amsterdam crouched over my laptop, using ssh over a hotel's dodgy wireless network) Don't even *think* about doing that! Enjoy your vacation! Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Backporting / stable
On 4/30/11 4:51 PM, m...@apollinemike.com m...@apollinemike.com wrote: On Apr 30, 2011, at 8:03 AM, Graham Percival wrote: On Sat, Apr 30, 2011 at 08:52:42AM -0600, Carl Sorensen wrote: On 4/30/11 8:49 AM, Graham Percival gra...@percival-music.ca wrote: We don't need to be sure that we're clear. All we need... or at least, all I want before uploading the official 2.14.0... is for one week without *known* Critical bugs. Right, but we haven't had that happen with the beaming since beam-collision-engraver was added. I'm pretty certain that we've had at least one 7-day period without new Critical bugs -- the only probablem was that such periods coincided with having old Critical bugs around. I'll admit that our record so far is still less than 48 hours of critical-bug-free-ness. But once we *do* have some bugs in the system, we can go for days and days without any new critical bugs being reported. If we'd been a bit faster in fixing some bugs, or a bit luckier and having a Critical bug report a few days later... or luckier in having critical bugs being reported earlier, and then getting fixed earlier... then I think we could have had 2.14 by now. Well, I'm on vacation for most of May, so we're looking at a June release at the earliest, in any case. So it seems that we've got some time to wait on this decision. I'll just pretend I never raised the issue, and when you get back from vacation if we're still adding Critical beaming bugs, we'll have the discussion again. I have no problem commenting out the Beam_collision_engraver and putting a use-at-your-own risk bit in the docs along with a list of known problems. In the devel version, the BCE could be a non-commented-out feature that people continue using/breaking so that we can perfect it over the next year or so. I agree that issues keep cropping up, and I think that we won't be able to anticipate all of them without broad, continued use in a variety of circumstances. I don't think we'd want to add that to the stable version. Use-at-your-own-risk should be part of the development version. But we've got some time now, so let's see what happens in the next six weeks. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Where to merge Translations now?
On 5/3/11 5:45 AM, Francisco Vila paconet@gmail.com wrote: 2011/5/3 Francisco Vila paconet@gmail.com: Hello, I have noticed that master is now 2.15; we on the lilypond/translation branch have unmerged work and more is to come. If master is now 2.15, what's the official mechanism planned for incorporate latest translations to the upcoming 2.12 stable? A possible solution is that I merge into master(2.15) as usual but I make a list of commits for Carl to cherry-pick them onto 2.14 . Sounds right? I would recommend that translators work from stable/2.14, rather than from master. I'm perfectly willing to have translation patches pushed to stable/2.14. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Another fix candidate for issue 1613. (issue4426072)
On 5/4/11 8:56 AM, m...@apollinemike.com m...@apollinemike.com wrote: On May 1, 2011, at 10:47 AM, mts...@gmail.com wrote: Ran the regtests - had to make one change, but they are now squeaky clean. Confirmations would be appreciated! Cheers, Mike http://codereview.appspot.com/4426072/ After chatting a bit w/ Han-Wen, I'm pushing this for now. In the future, he may implement a class to take care of this. For now, my solution works and does not break any regtests. I have some ideas for how to optimize one of the loops (at the expense of slightly more memory used), but I want to get this version up and running to see if it is as functional as I think it is. beam-collision-large-object.ly can be modified via the addition of an accidental to check for this behavior. Let me know if you want me to do this. Yes, please do. WE always want to keep regtests updated to check for fixed bugs. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Question about Custom Tablature in NR
On 5/5/11 10:46 AM, James Lowe james.l...@datacore.com wrote: Hello, I'm looking at tidying up some parts of this in the NR (not changing anything technically) and would like a clarification on something. We state: --snip-- The \makeStringTuning function is used to create a string tuning without setting the stringTunings property in the current context. The arguments to makeStringTuning are the symbol to be used for the new string tuning and a chord construct used to define the tuning. --snip-- Further up we say (I am paraphrasing) --snip-- \contextStringTuning takes two arguments: 1. The symbol in which the string tuning will be stored. 2. The chord construct that defines the pitches of each string in the tuning. This must be in absolute octave mode, The string with the highest number (generally the lowest string) must come first in the chord. --snip-- My question is does \makeStringTuning also require the pitches to be absolute mode as well? Yes. The chord constructs for defining the tunings are identical for \contextStringTuning and \makeStringTuning. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Better approach to fixing the TabVoice glissando problem. (issue4438092)
On 5/6/11 8:52 AM, m...@apollinemike.com m...@apollinemike.com wrote: On May 4, 2011, at 1:49 AM, Neil Puttock wrote: On 3 May 2011 23:44, m...@apollinemike.com m...@apollinemike.com wrote: Back to http://codereview.appspot.com/4438092/, it seems as if this doesn't screw up the harmonics problem. But they're already screwed (probably since the Tab_harmonic_engraver was removed and the harmonics moved to the TabNoteHead print function). Carl - I know you're slammed w/ a paper, but do you have time to apply my patch (as well as the failed commit that I pushed to master), look into the TabNoteHead print function, and see if there's a more elegant way to do what I'm doing w/o messing up the harmonics? I can put some time into it in a couple weeks, but I find that things go a lot quicker when the person who wrote a chunk of code sizes up the problem. Unfortunately, I don't. I hope to on Saturday. But it may be next week. It's on my list. I'll get to it as soon as I can. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix error messages in website build (issue4428077)
On 5/6/11 7:03 PM, percival.music...@gmail.com percival.music...@gmail.com wrote: woah, this is confusing. Could go back to the 2nd draft patch, yesterday's version? That is a very nice, self-contained patch. I'd like to have the official review period and get that pushed. I have no reason to believe that the other changes are bad; I just think that they're premature, and that we lose clarity by including them in this commit. You can^h^h^h^h^h^h^h^hOne can very easily get the previous draft, without losing the later work, in git. I'm not certain how to do it myself, though (I would begin by googling for tips), so I'm hesitant to offer to guide you through it. But it'll be a one- or two-line command, that a knowledgeable person can bash out in 30 seconds or so. You can use git stash (which I don't fully understand and have never used). But I'd recommend something like the following: git branch -f new-version git checkout new-version git checkout master git reset --hard sha1ID of the old version This will set your master back to the old version, and will create a new branch new-version that will be sitting there waiting for you to do further work on it. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Beam collisions on stable/2.14
All, I've backported all the beam collision stuff to stable/2.14. Graham, it seemed to me that VERSION was wrong for stable/2.14 -- it had stable 2.12.3 (correct) devel 2.13.60 (one too old) version 2.13.61 (also one too old) So I bumped version in stable/2.14. If it's wrong, go ahead and set it back for me. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Beam collisions on stable/2.14
On 5/7/11 2:09 PM, Graham Percival gra...@percival-music.ca wrote: On Sat, May 07, 2011 at 11:35:56AM -0600, Carl Sorensen wrote: stable 2.12.3 (correct) devel 2.13.60 (one too old) version 2.13.61 (also one too old) So I bumped version in stable/2.14. If it's wrong, go ahead and set it back for me. Hmm. We're going to end up with merge conflicts in VERSION, but oh well. It's not like whoever deals with that conflict will be puzzled about how to fix it. I'll be at university a bit past midnight your time, and I'll check the numbers in stable/2.14. I don't see your change to VERSION, so please check that you've pushed. If the numbers don't make sense, I'll change them, so no worries about that. I just cherry-picked your bump version patch and pushed it, so there should be no merge conflicts. I don't know how I lost that patch. I think I was working on a detached head for a while, and I may have built on the detached head. Yep -- just checking my reflog and I can see that. So now it's even better. I have your original commit in the stable branch. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Better approach to fixing the TabVoice glissando problem. (issue4438092)
On 5/6/11 8:52 AM, m...@apollinemike.com m...@apollinemike.com wrote: On May 4, 2011, at 1:49 AM, Neil Puttock wrote: On 3 May 2011 23:44, m...@apollinemike.com m...@apollinemike.com wrote: Back to http://codereview.appspot.com/4438092/, it seems as if this doesn't screw up the harmonics problem. But they're already screwed (probably since the Tab_harmonic_engraver was removed and the harmonics moved to the TabNoteHead print function). Carl - I know you're slammed w/ a paper, but do you have time to apply my patch (as well as the failed commit that I pushed to master), look into the TabNoteHead print function, and see if there's a more elegant way to do what I'm doing w/o messing up the harmonics? I can put some time into it in a couple weeks, but I find that things go a lot quicker when the person who wrote a chunk of code sizes up the problem. OK, I'm on this now. The problem is that the procedure called to determine frets and strings doesn't respect and maintain note ordering. And the ordering varies with whether or not strings are specified. I've modified the tablature-harmonics regtest to show the problem, and a fix will be coming soon. I think that will solve your problem. Once I have tab harmonics bulletproof, I'll check the glissando stuff out. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix determine-frets so that it preserves note order (issue4518045)
On 5/9/11 12:34 PM, n.putt...@gmail.com n.putt...@gmail.com wrote: Hi Carl, LGTM, apart from some indentation issues. One question for you though: do you think the refactoring is an improvement on the current code? You could for example achieve the same result with the following: (sort string-fret-fingering-tuples (lambda (a b) ( (car a) (car b) ;; end of determine-frets-and-strings There's no guarantee that the notes will be in decreasing string number order. That's the general case, but it's not required. In absolute mode I can write a C major chord as c' e' g' or g' e' c' and as far as I know, we have no requirement that we write chords with the lowest note first. Originally, (before the harmonic became part of the tab note head) we could be order-agnostic, because each head had its own information necessary to place the glyph. But now we aren't order agnostic because of glissandos on each note, and because the harmonic needs to be associated with the proper note. Additionally, there are instruments (at least one, the ukulele) where strings do not increase in pitch, so pitch order (as chords are generally entered in relative mode) doesn't necessarily match string order (which is what the sort call you proposed creates). For these reasons, I think something like what I've done is better than just the sort code you proposed. But I'm open to having the discussion. Thanks for the feedback! Carl Cheers, Neil http://codereview.appspot.com/4518045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Might understand this music stuff a bit better in the future
On 5/12/11 10:10 AM, Trevor Daniels t.dani...@treda.co.uk wrote: Colin Campbell wrote Thursday, May 12, 2011 2:19 PM On 11-05-12 05:08 AM, Phil Holmes wrote: I've just received an unconditional offer to study a part-time BA(Hons) in music from a local university. I'm well pleased :-) Up the geezers! Good for you, Phil. Make us old farts proud! I'll second that! Go for it Phil! Three here! Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Where to merge Translations now?
On 5/10/11 1:30 AM, Francisco Vila paconet@gmail.com wrote: Well. Here is my list. Carl, please, cherry-pick these commits from lilypond/translation to stable/2.14. I have cherry-picked the commits. I'm a bit concerned that Documentation/es/changes.tely may be wrong as a result of some merge conflicts I had. Can you please check that? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Where to merge Translations now?
On 5/12/11 12:28 PM, Francisco Vila paconet@gmail.com wrote: 2011/5/12 Carl Sorensen c_soren...@byu.edu: On 5/10/11 1:30 AM, Francisco Vila paconet@gmail.com wrote: Well. Here is my list. Carl, please, cherry-pick these commits from lilypond/translation to stable/2.14. I have cherry-picked the commits. I'm a bit concerned that Documentation/es/changes.tely may be wrong as a result of some merge conflicts I had. Can you please check that? It looks as if you applied two patches in reverse order. It is my fault, because I put the same info line on both of them (namely 'Doc-es: update CHANGES'). One is from 2011-04-19 and other from 2011-04-28. Now they are in the stable/2.14 branch but the 2011-04-28 is now older in history than 2011-04-19, which is latest in history. Aside of how could you manage to do this, the fact is that the resulting es/changes.itely file looks in perfect sync with English changes.itely file of the same stable/2.14 branch, so finally I think there is no problem at all. I managed to do it because I had merge problems with one commit, and I was applying things mostly blindly. Then when I got to the end, I looked at the English docs, and did what I thought was correct. Thanks for managing the translation commits for 2.14, and thanks for verifying that I got it right! Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Question about Music Classes in Internals and how to find \function properties
On 5/20/11 8:24 AM, James Lowe james.l...@datacore.com wrote: Hello, With regard to 'quotedCueEventTypes' and similar, I see in the NR that there is an example of explicitly stating which event types you want i.e: \set Score.quotedCueEventTypes = #'(note-event rest-event tie-event beam-event tuplet-span-event dynamic-event slur-event) If I look up Score in internals I see the translator property of quotedCueEventTypes is set to '(note-event rest-event tie-event beam-event tuplet-span-event). If I continue to look up ' quotedCueEventTypes' I only see that it is ' A list of symbols, representing the event types that should be duplicated for \cueDuring commands.' But then my trail finishes there. So my questions are 1. I know that I can use 'dynamic-event' for instance (because I have tried it) but there doesn't seem to be an easy way to know if an *-event will or will not work/be allowed in this property. Without trying it, I would assume any event that is in the Voice context will be usable here. 2. Where do I find out or where do I go to see where to find out a function like \cueDuring? Most likely ly/music-functions-init.ly. You can find it with git grep cueDuring HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Branches?
On 5/23/11 5:46 AM, David Kastrup d...@gnu.org wrote: What happens where? It appears like most work is done on release/unstable, partly on release/2.14, but almost nothing on master. What is the strategy here? When and how are changes expected to percolate to master? What is the difference between release/unstable and release/2.14 with regard to what changes will end up in master when? As far as I know, we have master as the current development snapshot. We have stable/2.14 as the 2.14 candidate; patches are cherry-picked from master to stable/2.14. I don't think anything is officially happening with release/unstable and release/2.14 Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Branches?
On 5/23/11 1:13 PM, Graham Percival gra...@percival-music.ca wrote: Carl Sorensen c_soren...@byu.edu writes: We have stable/2.14 as the 2.14 candidate; patches are cherry-picked from master to stable/2.14. Yes. Expect a release tomorrow. Please check with me before you make the release. I'm in the midst of some patch cherry-picking. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New alist to replace special characters. (issue4553056)
On 5/23/11 3:32 PM, bordage.bertr...@gmail.com bordage.bertr...@gmail.com wrote: http://codereview.appspot.com/4553056/diff/1/lily/text-interface.cc#newcode40 lily/text-interface.cc:40: int max_length = scm_to_int (ly_chain_assoc_get (ly_symbol2scm (replacement-string-max-length), It is needed line 50. This can be inferred from replacement-alist. But with this property we can disable every shorthand or just those longer than replacement-string-max-length. The ideas of disabling shorthands by the length of the replacement string seems very hackish to me. It seems unlikely to me that I would ever decide which replacement strings to disable by the length. To disable all replacement strings, we should have something like the following functionality #(define default-string-replacement-alist '(; This would be your list )) to enable replacements: \override TextScript #'replacement-alist = #'default-string-replacement-alist to disable replacements: \override TextScript #'replacement-alist = #'()_ @Carl : I agree for the .scm file. Why do you think it is going in the wrong direction ? Because we are making up our own syntax for characters that are already defined as UTF characters. We should avoid making up syntax if at all possible. For the ligatures, I'm supportive; we don't have a text processor that will automatically handle ligatures. For the special characters like trademark, and super2, we should just have them inserted into the file as UTF characters, IMO. I don't think we should be trying to (for example) handle TeX input in LilyPond strings. I see that as a maintenance pain in the neck. We're moving in the direction (if we're not there already) of correctly handling UTF text. Why not just let the person who wants to use UTF text do so? What is the advantage to typing \\aa instead of å? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stable/2.14 lacking predefined-mandolin-fretboards.ly
On 5/25/11 9:01 AM, James Lowe james.l...@datacore.com wrote: Carl et al )-Original Message- )From: lilypond-devel-bounces+james.lowe=datacore@gnu.org )[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On )Behalf Of Graham Percival )Sent: 25 May 2011 11:55 )To: Carl Sorensen )Cc: Lily devel )Subject: stable/2.14 lacking predefined-mandolin-fretboards.ly ) )Hi Carl, ) )Attempting make doc in stable/2.14 dies with this: )/main/src/lilypond/build/out/lybook-db/3c/lily-095253df.ly:1198:9: )error: cannot find file: `predefined-mandolin-fretboards.ly' ) )Could you cherry-pick whatever commit(s) dealt with this? ) [James' reply:] http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=5becf12f5ada6734 6f70ad8cfe68589466619305 Thanks for finding the commit for me, James. It saved me the effort. Pushed, along with some other patches I wanted to cherry-pick. Should be ready for a release now, I think. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stable/2.14 lacking predefined-mandolin-fretboards.ly
On 5/25/11 1:36 PM, Keith OHara k-ohara5...@oco.net wrote: Carl Sorensen c_sorensen at byu.edu writes: Pushed, along with some other patches I wanted to cherry-pick. Should be ready for a release now, I think. Not quite. The commit Fix determine-frets so that it preserves note order causes regression test tablature-negative-fret.ly to fails with an unbound variable: note OK, this is now fixed so it not only passes make check, but it also correctly ignores the note in tablature if the fret is negative and 'ignore is chosen for handle-negative-frets. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stable/2.14 fails on string for fret pitch
On 5/26/11 7:49 AM, Graham Percival gra...@percival-music.ca wrote: Build from scratch. make doc. ... warning: No string for pitch #Pitch c' (given frets (14 12 12 10)) ERROR: Wrong type (expecting pair): () error: Children (1) exited with errors. I've identified the problem, and completed a patch. I'm now in the midst of make doc to verify that there's nothing else causing problems. As soon as it's done, I'll push to git and let you know via email. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stable/2.14 fails on string for fret pitch
On 5/26/11 5:00 PM, Carl Sorensen c_soren...@byu.edu wrote: On 5/26/11 7:49 AM, Graham Percival gra...@percival-music.ca wrote: Build from scratch. make doc. ... warning: No string for pitch #Pitch c' (given frets (14 12 12 10)) ERROR: Wrong type (expecting pair): () error: Children (1) exited with errors. I've identified the problem, and completed a patch. I'm now in the midst of make doc to verify that there's nothing else causing problems. As soon as it's done, I'll push to git and let you know via email. Looks like everything succeeded. It's pushed to both stable/2.14 and master. Thanks, Carl Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Vacation
Hello, all. I will be on vacation from Monday May 30 through Saturday June 6. I expect to have no email during this time (I'll be camping on the beach of Lake Powell). Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Vacation
On 5/27/11 6:29 AM, Graham Percival gra...@percival-music.ca wrote: On Thu, May 26, 2011 at 10:11:39PM -0600, Carl Sorensen wrote: I will be on vacation from Monday May 30 through Saturday June 6. I expect to have no email during this time (I'll be camping on the beach of Lake Powell). http://www.google.com/search?hl=en=lake%20powell=1=isch http://www.google.com/search?hl=enq=lake%20powellum=1tbm=isch Wow! That place looks fantastic! Have a great trip. It really is fantqstic. It's wonderful to play on the water all day, then spend the night sitting on the beach watching the sun set. (I really didn't expect to get vacation envy less than a week after I got back, but... I love nature. Sorry Parisians: I had a great time meeting you, but your city sucks big time.) I enjoyed my two visits to Paris, but I enjoyed the French countryside even more. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc
On 5/27/11 11:40 AM, Graham Percival gra...@percival-music.ca wrote: On Fri, May 27, 2011 at 06:25:20PM +0100, Phil Holmes wrote: Is the aim with make docs to try to make it silent, unless there are errors, like we have done with make website? I think this is true only if we set a silent flag. When make errors show up, lots of times I have to look back quite a way to understand the source of the error. If it were silent, there would certainly be less to look back through, but I think there would also be much less information to help track down the problem. Yes. Ideally we should have no texinfo errors, no .ly errors, etc etc. I totally agree. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git merge mess to sort out
On 5/27/11 6:16 AM, Graham Percival gra...@percival-music.ca wrote: Hi guys, I'd like to be able to do git checkout master git merge stable/2.14 as implied by step 1 of post release on: http://lilypond.org/doc/v2.13/Documentation/contributor/minor-release-checklis t This step is useful to get the news announcement of the release; I don't expect to see anything else in these merges. Unfortunately, at the moment this produces a bunch of merge conflicts. Probably nothing serious, but it's an annoyance. Since it's been so long since the last release, I just went ahead and re-created the news announcements (which of course creates another merge conflict). The merge conflicts exist probably mostly because we have snippets listed at both 2.13.6x and 2.15.0. I guess once a snippet is backported to 2.13.6x, it should have the 2.13.6x in both stable/2.14 and master. I haven't done that, so I guess it's my mess to clean up. Does anybody feel like playing with git? I suppose this could be a useful exercise in git frustration if anybody wants to learn how to deal with conflicts. Or a git expert could probably spend 5 minutes to clear it all up. I'll take it on. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git merge mess to sort out
On 5/27/11 7:53 PM, Carl Sorensen c_soren...@byu.edu wrote: On 5/27/11 6:16 AM, Graham Percival gra...@percival-music.ca wrote: Unfortunately, at the moment this produces a bunch of merge conflicts. Probably nothing serious, but it's an annoyance. Since it's been so long since the last release, I just went ahead and re-created the news announcements (which of course creates another merge conflict). I'll take it on. Merge is completed. We have a bunch of duplicate commits, but everything is merged. I'll try to avoid that in the future. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc
On 5/28/11 4:03 AM, Phil Holmes m...@philholmes.net wrote: - Original Message - From: Carl Sorensen c_soren...@byu.edu To: Graham Percival gra...@percival-music.ca; Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org Sent: Saturday, May 28, 2011 2:35 AM Subject: Re: make doc On 5/27/11 11:40 AM, Graham Percival gra...@percival-music.ca wrote: On Fri, May 27, 2011 at 06:25:20PM +0100, Phil Holmes wrote: Is the aim with make docs to try to make it silent, unless there are errors, like we have done with make website? I think this is true only if we set a silent flag. When make errors show up, lots of times I have to look back quite a way to understand the source of the error. If it were silent, there would certainly be less to look back through, but I think there would also be much less information to help track down the problem. The current (new) situation with make website is that it echoes make commands if run with a straight make website - it also displays a few progress notifications - Processing web site: [fr] for example. If it's run silent - make -s website it just shows those progress messages and currently 4 errors about missing links. Try it - you might be surprised... That's the aim to replicate with docs. Also to understand and maybe streamline it? Sounds good^H^H^H^H^H great to me! Understanding, streamlining, and fixing dependencies would be wonderful (not all of the dependencies are currently in the doc make file properly, so we sometimes need to touch other files to trigger a rebuild. Thanks for taking this on! Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc
On 5/28/11 8:24 AM, Phil Holmes m...@philholmes.net wrote: - Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org Sent: Friday, May 27, 2011 6:40 PM Subject: Re: make doc On Fri, May 27, 2011 at 06:25:20PM +0100, Phil Holmes wrote: Is the aim with make docs to try to make it silent, unless there are errors, like we have done with make website? Yes. Ideally we should have no texinfo errors, no .ly errors, etc etc. I realise that to make this happen there will have to be lots of work to understand it better, ETA: 150 hours for the English docs alone. Another 50-100 hours for the translations. Is it worth raising a tracking issue report? I wouldn't bother adding an issue to the tracker, but there's certainly no harm in doing so. Cheers, - Graham OK - one of the first things I see is that lilypond is always invoked with the --verbose flag - so each time we call lilypond (and it's quite a bit - over 180 as an estimate from grep) we get 100s of lines of lilypond debug output - this probably adds 20-30,000 lines to the output. My suggestion for task 1 is to get rid of the --verbose flag. Any idea why it's there? So we can see which scm files are loaded, etc. It's very helpful in debugging problems. Certainly lose it with the -s flag. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc
On 5/28/11 9:05 AM, Graham Percival gra...@percival-music.ca wrote: On Sat, May 28, 2011 at 03:47:11PM +0100, Phil Holmes wrote: - Original Message - From: Carl Sorensen c_soren...@byu.edu To: Phil Holmes m...@philholmes.net; Graham Percival gra...@percival-music.ca OK - one of the first things I see is that lilypond is always invoked with the --verbose flag - so each time we call lilypond (and it's quite a bit - over 180 as an estimate from grep) we get 100s of lines of lilypond debug output - this probably adds 20-30,000 lines to the output. My suggestion for task 1 is to get rid of the --verbose flag. Any idea why it's there? So we can see which scm files are loaded, etc. It's very helpful in debugging problems. Certainly lose it with the -s flag. I disagree; those logs can be useful. We just don't need to see them on the console. I agree with your position. I had forgotten about the individual log files. Why not redirect the compile-output from each .ly to the appropriate .log file? I mean, we *already* have a .log for each .ly file... what's in the .log file at the moment? Why not put the --verbose output in there? etc. GUB does a really nice job of managing ouput information -- it (generally) doesn't overwhelm you with spam on the console, but whenever you want to see what the detailed output was at some step, it's either in the log/ dir (for general GUB stuff) or the relevant target/architecture/log/ dir. I'd like to see a similar thing here. Don't remove output; just save it to files. Even better. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Windows SP1 bug and ghostscript-9.0
On 5/29/11 3:48 PM, Graham Percival gra...@percival-music.ca wrote: On Sun, May 29, 2011 at 08:09:53PM +0200, Jan Nieuwenhuizen wrote: In trying to nail down the notorious #1562, I started a ghostscript-9.0 branch in GUB, which uses ghostscript 9.02, freetype-2.4.4 and includes a small ghostscript installer fixlet. It would be nice if you could find a time to include these into the release branch or master. Sorry, but I don't think that would be a good idea. We've just reached 0 Critical bugs again, so I'll be making a new Release Candidate (Carl: I can handle the backporting, probably, enjoy your vacation). This is not the right time to switch a bunch of build requirements. Remember that 2.14.0 is drastically late and the delay has caused huge problems. I think the best thing is to get 2.14.0 out now, include a warning that it doesn't work on windows 7 SP1 but that we're testing a fix and hope to have a new version out soon. Then we switch to ghostscript-9.0 in 2.15.0 and start testing. Actually, the last patch than Jan posted should make LilyPond work on windows 7 sp1, IIUC. So as long as we backport that patch, we're good with windows. Thanks, Carl P.S. I'm glad this whole gs9 thing came up. I was having weird bugs doing make doc on my (OSX) system, and chord names had the wrong font. As a result of all the discussion about gs9, I reset my gs to 8.73, and everything went away. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Windows SP1 bug and ghostscript-9.0
On 5/30/11 3:46 AM, Jan Nieuwenhuizen jann...@gnu.org wrote: Actually, the last patch than Jan posted should make LilyPond work on windows 7 sp1, IIUC. So as long as we backport that patch, we're good with windows. Indeed! Ghostscript 9.0 is not required, neither is freetype 2.4.4 -- but I had to check and now they're available [for testing anyway]. The patch is now backported. P.S. I'm glad this whole gs9 thing came up. I was having weird bugs doing make doc on my (OSX) system, and chord names had the wrong font. As a result of all the discussion about gs9, I reset my gs to 8.73, and everything went away. Hmm, and you were at gs9? Yes, via Macports. I can set it back to 9 at any time for testing. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES: 48-hour notice for event listener docs, ignoring note-heads, and spacing with empty contexts
On 6/6/11 12:16 PM, Graham Percival gra...@percival-music.ca wrote: Wed, 20:00. Doc: writing music events to a .notes file http://codereview.appspot.com/4438054/ Allows LilyPond to ignore certain note-heads in a stem http://codereview.appspot.com/4547058/ I thought this patch was withdrawn. See http://thread.gmane.org/gmane.comp.gnu.lilypond.devel/36499 Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parameters in metafont files
On 6/1/11 9:39 AM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: Please help! I'm not ignoring you, but I have no idea on this! I'm sorry, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc
On 5/30/11 12:56 PM, Phil Holmes m...@philholmes.net wrote: - Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: Carl Sorensen c_soren...@byu.edu; lilypond-devel@gnu.org Sent: Saturday, May 28, 2011 6:22 PM Subject: Re: make doc On Sat, May 28, 2011 at 05:48:39PM +0100, Phil Holmes wrote: So the command line would need to be something like lilypond filename.ly filename.log? Something like that, probably. Dunno. What happens when you try that command on the command-line? Remember the first rule of build systems: a build system just sets up the environment and then runs command-line commands. (no wait, that's the second rule. The first rule is that all build systems suck; most of them suck exponentially.) Will have to look at how that could be done, since the times lily is called that I've so far found are initiated by lilypond-book. Well, figure out how to do it with lilypond by itself, then figure out how to do it with lilypond-book, then figure out how to do it inside the build system. Cheers, - Graham OK - so I now know how to redirect the output from lilypond-book.py when it's making, for example, collated-files.tely - I can redirect it to collated-files.log. FWIW simply doing the redirect on /input/regression/out-www/collated-files.tely creates a logfile of 30 Meg and 68,000-odd lines! I think this is a good first step. For those who are interested in the build system, I attach my notes to date of how make doc works - slightly stream-of-consciousness, I'm afraid. Phil, I'd like to see this dumped in the CG, even in its current stream-of-consciousness form. I'll put it in if you'd like. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parameters in metafont files
On 6/1/11 9:39 AM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: Hi again :) Congrats on 0 criticals! I have a question about parameters in metafont files: i want to create something similar to mf/out/feta20.otf-table, but i don't understand how it's done (i tried to find bbox and attachment in mf files or scripts/build/gen-emmentaler-scripts.py, but there are no results). I also tried adding autometric_parameter (someBogusName, someValue); inside mf code, but there were no results. Here is roughly what i want to achieve: add a magical command to feta-flags.mf fet_beginchar (8th Flag (up), u3); [...] % flags.u3 definition magical_command (arbitraryRealValueChosenByMe); fet_endchar; fet_beginchar (16th Flag (up), u4); [...] % flags.u4 definition magical_command (anotherArbitraryRealValueChosenByMe); fet_endchar; [...] and have it output a flags.otf-table file looking like this (flags . (u . ((3 . (arbitraryRealValueChosenByMe)) (4 . (anotherArbitraryRealValueChosenByMe)) [...] )) . (d . [...] ))) Please help! After looking more at this, it appears that the .otf-table files are created by parsing the log files created during font creation. See scripts/build/mf-to-table.py So this means that your magic command would need to emit a keyword and a real value to the log file, and mf-to-table.py would need to be modified to read the keyword and the value and put it in the table file. HTH, Carl Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: On creating a new all-encompassing drum mode (with example)
On 6/8/11 6:36 AM, Mike J. Bell cki...@gmail.com wrote:
(reposted from lilypond-user at the suggestion of one of the readers, and
includes my script)
I'm interested in making a custom drum mode that more accurately reflects the
rules in Weinberg's Guide To Standardized Drumset Notation. Some of the
pieces seem to be straightforward, others not so much. I made an example file
that was as close as I could get it, but there are a number of problems with
my approach. In particular, one notehead uses custom postscript; two others
use standard lilypond noteheads that aren't quite right; and there are other
expressive marks or articulations that aren't 100%. So not only am I not
getting exactly the output I want, it's also moderately difficult to enter the
notes themselves in some cases.
Has anyone already looked into updating lilypond's drum features to be
compliant with GSDN? If not, is there anyone out there that's put extensive
time/effort into customizing their drum modes that would be willing to share
their work so I might see best (or better!) practices on how to approach this?
As far as I know, there is no developer who has a primary interest in
developing drum features. This means the field is wide open -- you could be
that person!
Specific notes on some of the major problems with my approach:
1) I'd like the halfopen articulation to be a 0 with line straight up-and-down
through it instead of slanted...my guess is this mark is embedded in the font
and hard to change
It is embedded in the font, but not terribly hard to change. What we would
probably want to do is to add a new articulation with the line straight
up-and-down, unless we can get agreement that the angled line is wrong. In
your opinion, is the angled line wrong, or just a different variant? Can
you cite any references that indicate the line should be vertical? Are
there any references that indicate the line should be at an angle? We want
to make sure that LilyPond does the right thing.
2) The staccatissimo articulation appears directly over the choked cymbal
note, instead of slightly behind (to the right) of it
You can set the X-offset property of the Script grob (using either \tweak or
\once \override) to adjust the horizontal position of the articulation.
3) The rimshot slash is rendered with custom postscript per notehead
This seems to me to be a reasonable approach, but it would be better to use
a path instead of postscript. Using a path will give both postscript and
SVG output correctly. But since it's a simple line, the draw-line function
is probably even easier. See Notation Reference, A.9.3 (both of these
functions are new in 2.14 compared to 2.12)
4) There is no circled default notehead, so I used xcircle instead
You may be able to redefine the notehead print funtion to use the
circle-stencil function (see scm/stencil.scm).
5) The triangle notehead isn't the proper orientation for percussion (wide
isosceles with base parallel to staff lines)
Try the do notehead, or the doThin notehead.
6) The acciaccatura I use for flams doesn't put the slur line in the direction
I wish (it's over instead of under)
You may be able to define your own \flam command using
define-grace-function. You can see how it's done for acciaccatura in
ly/grace-init.ly and ly/music-functions-init.ly.
7) The grace I used for ruffs and drags doesn't put the slur line in the
direction I wish (but I think I can override this)
See my answer to 6.
These are mostly appearance-related. Functional- or use-related issues are
that I'd really like to be able to make new note names that are like macros so
I don't need to be so specific at invocation. I kind of want something like
(pardon the pseudocode):
(define bell cymr-)
(define choke cymc-|)
(define rimshot sn^\markup { \postscript #gsave 0.25 setlinewidth -0.2 -1.3
rmoveto 1.7 -1.7 rlineto stroke grestore })
(define ghost \parenthesize sn )
(define flam \acciaccatura { sn8 } sn)
(define drag \grace { sn16[\( sn] } sn4\))
Except of course that each of those would need to put the note value in the
correct place and be a valid expression, etc.
You may be able to achieve this by some modification of the shape note code.
Barring that, you should be able to do it as a series of music functions.
ghost =
#(define-music-function (parser location note)
(ly:music?)
#{ \parenthesize $note #})
Your music would then read
\ghost sn4 \ghost sn2
and so forth.
See Notation Reference 5.6 for more on music functions.
Thanks for your contributions! I'm excited to see more of this.
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: On creating a new all-encompassing drum mode (with example)
On 6/8/11 8:20 AM, Carl Sorensen c_soren...@byu.edu wrote: On 6/8/11 6:36 AM, Mike J. Bell cki...@gmail.com wrote: 1) I'd like the halfopen articulation to be a 0 with line straight up-and-down through it instead of slanted...my guess is this mark is embedded in the font and hard to change It is embedded in the font, but not terribly hard to change. What we would probably want to do is to add a new articulation with the line straight up-and-down, unless we can get agreement that the angled line is wrong. In your opinion, is the angled line wrong, or just a different variant? Can you cite any references that indicate the line should be vertical? Are there any references that indicate the line should be at an angle? We want to make sure that LilyPond does the right thing. I've since done a bit of research on the current half-open symbol. It's used with the angled slash for horn. So we'll need to add another glyph for drums -- maybe we'll call it drumhalfopen. I will do this if I can get my metafont/mf2pt1/fontforge to work properly. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parameters in metafont files
On 6/9/11 9:02 AM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: Hi, i wanted to reply yesterday, but my dad broke our internet connection :) Unfortunately, I don't have anybody else to blame when my internet connection is broken. After looking more at this, it appears that the .otf-table files are created by parsing the log files created during font creation. See scripts/build/mf-to-table.py So this means that your magic command would need to emit a keyword and a real value to the log file, and mf-to-table.py would need to be modified to read the keyword and the value and put it in the table file. Carl, you are great! After struggling with this shortened-flags issue for 5 months, i wouldn't have enough motivation to continue my work without your help! Right now I'm reading all the stuff that i did to remind myself where i am. As for now it looks that you are pointing me in the right direction! Glad to be of help! I really do like your work, and I want to see it implemented in LilyPond. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parameters in metafont files
On 6/9/11 3:18 PM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: 2011/6/8-9 Carl Sorensen c_soren...@byu.edu: After looking more at this, it appears that the .otf-table files are created by parsing the log files created during font creation. See scripts/build/mf-to-table.py So this means that your magic command would need to emit a keyword and a real value to the log file, and mf-to-table.py would need to be modified to read the keyword and the value and put it in the table file. Yes, and i'll also have to add a function to mf/feta-autometric.mf, similar to set_char_box. I'm finding the actual place in which the value is being output to logfile. But there's another question: currently all glyphs in feta-noteheadsFONTSIZE.log have the same amount of characteristics. Adding another values only to the flags, if at all possible, would perhaps make reading the logfiles more diffucult. Perhaps it would be good to move flags into a separate font file? (i.e. separate feta-noteheads into actual feta-noteheads and feta-flags) That sounds to me like a reasonable approach. Rather than messing with feta-autometric, you can define your own feta-flag-autometric. There is another rationale for doing this: i'm pretty sure that there's a limit of 256 glyphs per font. Until now there were only a handful of flags, but we're going to have many dozens of them; it's quite possible that either now or in the future we will reach the 256 glyph limit. I think that's reasonable. feta-noteheads was already separated because of hitting the 256 glyph limit when we added shape noteheads in multiple styles. What do you think? I remember that i tried doing this separation, but something didn't work. I hope i have that draft somewhere though. I think that what causes problems is you lose the definition of black-notehead-width (which comes from feta-noteheads). On 6/9/11 9:02 AM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: Carl, you are great! After struggling with this shortened-flags issue for 5 months, i wouldn't have enough motivation to continue my work without your help! Right now I'm reading all the stuff that i did to remind myself where i am. As for now it looks that you are pointing me in the right direction! Glad to be of help! I really do like your work, and I want to see it implemented in LilyPond. I'm so happy to hear this! Sometimes i have the impression that noone really cares. And wait till i start another project! It's gonna be about ties ;) Maybe i'll finish it before Lily 3.0... Great! Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parameters in metafont files
On 6/10/11 5:43 AM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: 2011/6/10 Carl Sorensen c_soren...@byu.edu: On 6/9/11 3:18 PM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: I remember that i tried doing this separation, but something didn't work. I hope i have that draft somewhere though. I think that what causes problems is you lose the definition of black-notehead-width (which comes from feta-noteheads). Yes. I discovered that my previous try is available as Rietveld issue: http://codereview.appspot.com/4273119/ Unfortunately i still don't know how to extract the information about black_notehead_width. It should be made some kind of a global variable, but the main problem is that its value is not specified explicitely, but it's a result of a drawing operation. I've looked at this some more. In feta-noteheads.mf, line 39, we do save black_notehead_width which establishes black_notehead_width as a local variable to the group. It may be as simple as eliminating the save statement for black_notehead_width. Alternatively, it may involve expanding the group, instead. But I haven't worked that out yet. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parameters in metafont files
On 6/10/11 2:53 PM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: Carl, 2011/6/10 Carl Sorensen c_soren...@byu.edu: It may be as simple as eliminating the save statement for black_notehead_width. it works! You are a GENIOUS!! I'm sure that genius is too strong a word to apply to me, but thanks for the kind words. Even a blind squirrel finds a nut every once in a while. I'm glad it worked for you! I've looked at your Rietveld patch, but I won't be able to actually test it until sometime later, but it may be a few days. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Duplication in NR 1.6.3 - snippets no longer needed?
On 6/10/11 12:05 AM, Keith OHara k-ohara5...@oco.net wrote: James Lowe James.Lowe at datacore.com writes: I think we have some duplication in this section but would like a second opinion I agree. The two snippets do not need to be quoted in the documentation because you cover all the concepts earlier. I concur. The Selected Snippets have no reason for being; the same concepts are taught in the main text, and there is no reason the snippets need to be selected snippets (i.e. they don't use \override or \set (except for the instrument name). Please eliminate the selected snippets. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: very miniscule nitpick
On 6/11/11 1:56 AM, Mark Polesky markpole...@yahoo.com wrote:
Carl, I have a tiny tiny tiny nitpick:
In your latest commit (0475fb3) I think you should wrap
--enable-double in an @option block:
@option{--enable-double}
Without it, the two hyphens become an en-dash, and command-line
options should be appropriately formatted anyway (i.e. in a
monospace font).
Thanks, Mark. You are absolutely correct. In the future, when something
like this happens (as I am sure it will), please feel free to fix it. Or,
if you want to have me fix it, go ahead and post to -devel so others can
learn from my mistakes
Fix pushed.
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.15.1 with new fontforge
On 6/11/11 9:34 AM, Graham Percival gra...@percival-music.ca wrote: 2.15.1 has fontforge 20110222. I'll upload 2.14.1 with the same fontforge unless anybody screams in the next 24 hours. AFAICS, there's no problem with 20110222. I don't think you need to worry about waiting. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.15.1 with new fontforge
On 6/11/11 9:42 AM, Graham Percival gra...@percival-music.ca wrote: On Sat, Jun 11, 2011 at 09:39:07AM -0600, Carl Sorensen wrote: On 6/11/11 9:34 AM, Graham Percival gra...@percival-music.ca wrote: 2.15.1 has fontforge 20110222. I'll upload 2.14.1 with the same fontforge unless anybody screams in the next 24 hours. AFAICS, there's no problem with 20110222. I don't think you need to worry about waiting. Are you saying this because you're a nice and optimistic guy, or are you saying it because you've tested it in linux-x86, linux-64, darwin-x86, and mingw ? :) I'm saying this because Werner has been using 20110222 for a long time, and 20110222 has been out four 4 months on all those platforms. I don't think we're going to get any more information in 24 hours than we currently have. But I'm fine to have you be cautious. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: ugly boxes
On 6/12/11 6:07 AM, Phil Holmes m...@philholmes.net wrote: I'm continuing to look at the build system, and studying the output of make doc see lots of the following: Overfull \hbox (plus some other stuff) Looking on the web for what this means, I found http://docs.freebsd.org/info/texinfo/texinfo.info.Overfull_hboxes.html which says: TeX is sometimes unable to typeset a line without extending it into the right margin unless told otherwise, TeX will print a large, ugly, black rectangle beside the line that contains the overfull hbox. There are quite a few of these in, say, the 2.14 NR - see the PDF page 33 and 37 for example. I don't think these should be there (although I had previously assumed they were change bars). It would seem there are 2 options: either fix the text/diagram sizes, or compile as suggested in the page above: To prevent such a monstrosity from marring your final printout, write the following in the beginning of the Texinfo file on a line of its own, before the `@titlepage' command: @finalout Could someone from the documentation team confirm that the bars are unintended and have a think about what should be done? I'm not part of the doc team, but I'm sure the bars are unintended, and that we should use @finalout. IWBN if we could eliminate the overfull hboxes, but that doesn't seem to me to be likely in the short run. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES: 48-hour countdown for longas, separating font, and compressing vertical
On 6/14/11 6:06 AM, Graham Percival gra...@percival-music.ca wrote: separating flags from noteheads in font http://codereview.appspot.com/4273119/ This one is currently broken, so should not be pushed. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.14.1 released; attention span over
On 6/14/11 1:07 PM, Francisco Vila paconet@gmail.com wrote: 2011/6/12 Francisco Vila paconet@gmail.com: 2011/6/12 Graham Percival gra...@percival-music.ca: I'll still make 2.14 releases -- just tell me to build a release, and I'll do that based on the current stable/2.14 branch in git. At the moment, Carl is the person to backport stuff, but the amount of energy he puts into that is entirely up to him. Or he could ask somebody else to do stuff. Up to him. I'd like to recall Carl that a translation by Federico was pending, see http://lilypond-translations.3384276.n2.nabble.com/Doc-it-patch-Usage-complet ed-tt6439450.html#a6448641 He specifically wanted to see this in 2.14 and I promised him to, but I can not promise anything not in my hand. The commit is in savannah http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=98b690b03df23d45 ae827340c00700be8814c156 I beg your pardon if I am a pain in your neck, but please backport-cherrypick-whatever this commit onto stable/2.14 so that it goes to the next 2.14-2 stable release. Thank you! This has now been pushed. I'm sorry that I didn't get it done earlier. I had a merge conflict and didn't have the time to resolve it. Now the conflict is gone. Graham; it would be _very_ appreciated if you'd announce a new stable 2.14-x release some days in advance. Thank you very much How many days in advance would like notification of a new 2.14.x release? As far as I can see, the feature set in 2.14.x should be fixed; later 2.14 revisions should be about fixing bugs. So it seems that translation can happen any time. I guess if we have documentation bugs it would be nice to have them fixed before release. Would a 1-week notification serve? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bugfix for issue 1630 (issue4490045)
On 6/14/11 4:19 PM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: 2011/6/14 percival.music...@gmail.com and Janek: you are probably quite confused (and maybe disheartened) by this indentation problem, because the current indentation policy used in lilypond is completely braindead and ridiculous for any editor other than GNU/emacs. I'm disheartened by the idea of reverting tab-space conversion, because CG 10.3.2 says All indentation should be done with spaces. Strictly speaking, CG 10.3.2 applies to changes in .scm and .ly files (see section 10.3). The .ly file proposal is fully supported, AFAIK. The .scm proposal is moderately supported. But the current policy is do what's in the current file. I hope we can get to don't use tabs, but we haven't got there fully. I have just postponed the lessons from 2.14 GOP policy question for another week so that we can start dealing with C++ indentation on Wed 22 June. Unfortunately the discussion would not be over until 06 July, but that's the best I can do (unless I postpone the mentors discussion, but I think that one's even more pressing than indentation). No, don't postpone mentors! If you want the patch pushed sooner, then unfortunately you need to use the exact (braindead) indentation we currently have for C++ code. Alternately, wait until we have a sensible policy I think we are inconsistent: sometimes we stick to the rules very strictly, and sometimes not at all. I think that the C++ rules are quite strictly enforced, although I won't promise that all existing files follow them. C++ standards are in CG 10.5; indentation standards are 10.5.3. Previous discussions on tabs v. spaces include the following: http://thread.gmane.org/gmane.comp.gnu.lilypond.devel/22691 http://lists.gnu.org/archive/html/lilypond-devel/2009-04/msg00076.html It's part of GLISS, I think. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.14.1 released; attention span over
On 6/14/11 5:06 PM, Francisco Vila paconet@gmail.com wrote: 2011/6/14 Carl Sorensen c_soren...@byu.edu: I guess if we have documentation bugs it would be nice to have them fixed before release. Would a 1-week notification serve? Yes. If 2.14-x releases are to be frequent and/or numerous, this is not so important. If we are going to live with a maximum of 2.14-3 for 2.5 years, this is very important. IMHO we have wasted one already. I think that we should make sure we get good translations for 2.14.x. I'm willing to do new releases even if the only change is the state of the documentation. So please keep me up to date on it. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.14.1 released; attention span over
On 6/15/11 6:21 AM, James Lowe james.l...@datacore.com wrote: \ Does that also mean that you need me to do something (apart from hurry up and get the patches for the doc bugs done!)? When you push a patch for a doc bug that applies to 2.14, please make sure there's a google code issue with a backport tag. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.14.1 released; attention span over
On 6/15/11 7:14 AM, James Lowe james.l...@datacore.com wrote: Carl, )-Original Message- )From: Carl Sorensen [mailto:c_soren...@byu.edu] )Sent: 15 June 2011 14:04 )To: James Lowe; Francisco Vila )Cc: LilyPond-Devel list )Subject: Re: 2.14.1 released; attention span over )Importance: Low ) ) ) ) )On 6/15/11 6:21 AM, James Lowe james.l...@datacore.com wrote: ) )\ ) ) Does that also mean that you need me to do something (apart from )hurry ) up and get the patches for the doc bugs done!)? ) )When you push a patch for a doc bug that applies to 2.14, please make )sure there's a google code issue with a backport tag. ) [James' reply:] I cannot see an option to add a 'backport' tag - for example I can see how to add the 'Type-Defect' and 'Priority-medium' etc. But nothing with 'Backport' in the string. So is there a specific way to do this? Go down to the tags field (collection of empty boxes) and type backport in one of them. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 2: mentors and Frogs
On 6/15/11 5:44 AM, Graham Percival gra...@percival-music.ca wrote: Perfect example: two weeks ago, issue 1630 chord autosplit was almost finished (it only needed a few minor code formatting). But then it stalled until I suggested to Janek that he should get in touch with Karin 2 days ago. Then suddenly stuff started happening. I think the story of this patch http://code.google.com/p/lilypond/issues/detail?id=1630 http://codereview.appspot.com/4490045/ is a horrible black eye for us. Initial patch sent on 2011-04-29. Janek said (in private email) that he could mentor her on 2011-04-29, but the patch only went on rietveld on 2011-05-07 because he was on vacation. A few comments, then nothing happened for two weeks. Then a few more revisions happened, followed by another two-week gap. This whole patch could have been done in 5 DAYS if we'd had our cards in order. - new contributor comes. - welcome, here's the guidelines, ask on frogs or xyz for personal help - revision 1, comments for 24 hours, revision 2, comment for 24 hours, revision 3, patch review countdown 48 hours. Instead, this has dragged out for almost 7 WEEKS. Given this experience, I fully expect Karin to abandon any attempt at future bugfixing in lilypond. Seven weeks for a 68-line patch?! This is especially tragic because the initial quality of the patch was very high. Karin is clearly a gifted programmer who figured out how to solve this problem on her own. Losing her potential contributions to LilyPond is a real problem. I hope we can change our ways and continue to get her involved. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: separating flags from noteheads in font (issue4273119)
On 6/13/11 1:17 PM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: Bad news: it doesn't work (the flags are squashed) - i have no idea why... Maybe i forgot to make clean when i tested it before, but i'm almost sure i didn't. Still, this looks like the only possible explanation. Mike tested it too and he got flags as squashed as attached; the only person who reports to have everything ok is Colin - that's weird... Seems we are back to the same question: how to pass black_notehead_width to feta-flags from feta-noteheads. Have you tried eliminating the numeric black_notehead_width; line from feta-noteheads.mf and adding it to feta-generic.mf? I haven't tried this, but this is the direction I would go. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: clashing note columns in example
On 6/15/11 7:35 AM, Phil Holmes m...@philholmes.net wrote:
Minor nit-pick? The doc build generates the following:
tab-example.ly:42:26: warning: ignoring too many clashing note columns
gis\4 d'\3 fis\2 2
Thanks, Phil. This is more than a minor nit pick. This is a bug.
The \voiceOne and \voiceTwo commands are ignored in this file. If you
compare to an earlier version, you'll see that a bunch of the stems that
used to be up are now down.
Here's a patch that solves the problem for the particular file, but it does
a workaround rather than fix the bug.
diff --git a/Documentation/web/ly-examples/tab-example.ly
b/Documentation/web/ly
index 3f9a8d3..672b7c8 100644
--- a/Documentation/web/ly-examples/tab-example.ly
+++ b/Documentation/web/ly-examples/tab-example.ly
@@ -35,7 +35,7 @@ upper= \relative c' {
\set Staff.midiInstrument = #acoustic guitar (steel)
\set fingeringOrientations = #'(left)
- \partial 4. \acciaccatura c16 \glissando cis8 e4
+ \partial 4. \acciaccatura c16 \glissando \voiceOne cis8 e4
cis-1 g'-3 2 s8 \grace a16 ( \glissando b-2 8\3 ) d-1 ( b )
e-3 \2 ( d-1 b ) \grace ais-2 16 ( \glissando a8 g ) s4.
s4. d'\3 g\2 8 gis,\4 d'\3 fis\2 2\arpeggio ~
@@ -45,7 +45,7 @@ upper= \relative c' {
lower= \relative c {
\set fingeringOrientations = #'(left)
- \partial 4. s4.
+ \partial 4. s4. \voiceTwo
s4 e,4 s2
s2 s8 e'-3 4. ~
e4 \hideFretNumber \grace { b8 \glissando s4 } e-2 4\5 e,2 ~
I'll see if I can get the bug down to a tiny example.
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
