Re: GOP-PROP 5: build system output (probable 2?)
Graham Percival writes: You mean, like 23cdda9506931d5b9a1e75ee8be8b74f9084a7c0 ? Yes (I would have called the option --log). I'd call it 20% rather than 90%, but yes, Phil's work on lilypond-book will certainly be valuable! Assuming that --redirect-lilypond-output is used during build now, you mention 500,000 and 370,000 lines of output for make doc. Am I assuming correctly that currently make doc prints 130,000 lines? Which programs are responsible for that? I can imagine also adding stepmake rules to handle V=0 for c/c++ compilation. Possibly not logging that would be OK, because a new compile with V=1 would almost instantly show the problem? I don't agree. Log files are cheap; I think we should always write the logfiles I don't get this. Any sort of complexity added is expensive. It must be written, it must be documented, it must be remembered, it must be maintained. One of the biggest responsibilities as a maintainer is to deny most if not all `nice to have' features in favour of simplicity and more important things. Moreover, I figure that c/c++ compilation amounts to only a maximum of about 0% to the sea of output burden. What are you trying to fix? Also, you are [should be] probably running c/c++ compilation in -j4 mode; how are you going to find/determine which compile failed and what log file it is? Then, you have to open the log file and tell your editor to go to the right location. It's just much smarter to hit compile [bound to make V=[ [-j1]] in your editor and have it jump to the error location. Jan -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: review process not working
I agree with Graham that it's a matter of bad luck (i.e. stuff happens). If i understand Graham correctly, the idea of countdown is not to add some beaurocratic order, but to force us to speak now, or forever be silent (tongue-in-cheek, of course). In other words, a patch without reviews is not put on countdown because it certainly must be good, but precisely to *get* some reviews. 2011/7/26 Graham Percival gra...@percival-music.ca: On Tue, Jul 26, 2011 at 07:36:43PM +0200, David Kastrup wrote: So it needs to tell its story in comments. It doesn't. There is a lot of code in Lilypond that nonchalantly expects people to get along without commenting what it does. This is often a nuisance, but if the code is written by a master, the pain of figuring out what it does is usually tolerable. Very true; I think that almost all developers (if not all!) would like to see better comments in the code! I'd like to see them for certain. Could you get into the habit of pointing out questionable / unclear parts of code in future patches, so that the author will explain them in comments? I'll try. This will probably be easy; as i won't understant anything i'll ask for comments everywhere :) cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output (probable 2?)
Graham Percival writes: You mean, like 23cdda9506931d5b9a1e75ee8be8b74f9084a7c0 ? Yes (I would have called the option --log). I'd call it 20% rather than 90%, but yes, Phil's work on lilypond-book will certainly be valuable! Assuming that --redirect-lilypond-output is used during build now, you mention 500,000 and 370,000 lines of output for make doc. Am I assuming correctly that currently make doc prints 130,000 lines? Which programs are responsible for that? I can imagine also adding stepmake rules to handle V=0 for c/c++ compilation. Possibly not logging that would be OK, because a new compile with V=1 would almost instantly show the problem? I don't agree. Log files are cheap; I think we should always write the logfiles I don't get this. Any sort of complexity added is expensive. It must be written, it must be documented, it must be remembered, it must be maintained. One of the biggest responsibilities as a maintainer is to deny most if not all `nice to have' features in favour of simplicity and more important things. Moreover, I figure that c/c++ compilation amounts to only a maximum of about 0% to the sea of output burden. What are you trying to fix? Also, you are [should be] probably running c/c++ compilation in -j4 mode; how are you going to find/determine which compile failed and what log file it is? Then, you have to open the log file and tell your editor to go to the right location. Isn't it smarter to hit compile [bound to make V=[ [-j1]] in your editor and have it jump to the error location? Jan -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output (probable 2?)
On Thu, Jul 28, 2011 at 08:25:25AM +0200, Jan Nieuwenhuizen wrote: Graham Percival writes: You mean, like 23cdda9506931d5b9a1e75ee8be8b74f9084a7c0 ? Yes (I would have called the option --log). IMO a long descriptive name is better than a short name that's open to interpretation. Note that --redirect-lilypond-output does *not* save any output from lilypond-book (the python script) to a file. I'd expect a --log to do that. We may well look at adding --log in the future, or else do that redirection in the build system. I'd call it 20% rather than 90%, but yes, Phil's work on lilypond-book will certainly be valuable! Assuming that --redirect-lilypond-output is used during build now, It is not. We are moving very slowly and cautiously to avoid creating more problems. --redirect-lilypond-output needs a lot more testing, particularly stuff like .tely files including .itely files including .ly files. The build system has not been touched, in large part because we have not yet decided on what the overall policy should be. I don't agree. Log files are cheap; I think we should always write the logfiles I don't get this. Any sort of complexity added is expensive. It must be written, it must be documented, it must be remembered, it must be maintained. One of the biggest responsibilities as a maintainer is to deny most if not all `nice to have' features in favour of simplicity and more important things. I submit to you that since we have 1 thread about broken builds every 2 months, the current build system needs to change. I think this extra complexity is worth it. BTW, do you consider the logging system in GUB to be unnecessary added complexity? I find it incredibly useful. Moreover, I figure that c/c++ compilation amounts to only a maximum of about 0% to the sea of output burden. What are you trying to fix? We're mostly trying to fix the doc output. In case there is ambiguity here, build system output refers to make doc in addition to plain old make We are trying to figure out general policies for the build system. Also, you are [should be] probably running c/c++ compilation in -j4 mode; how are you going to find/determine which compile failed and what log file it is? Then, you have to open the log file and tell your editor to go to the right location. If we cannot clearly distinguish which log file (from -j4) contains the error, then obviously we would simply redirect all threads to the same log file. I consider this a relatively minor implementation detail; the relevant policy point is: Ideally, a failing build should provide hints about the reason why it failed, or at least hints about which log file(s) to examine. If a certain arrangement of log files (be that merging files, splitting files, whatever) does a better job of bringing the error to the user's attention, then we should use that arrangement. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29
On Do., 28. Jul. 2011 04:04:21 CEST, Colin Campbell c...@shaw.ca wrote: Countdown done, but still open/not marked fixed: From Wednesday July 27 Issue 732: Alignment problems when vertically stacking horizontally centered stencils. Issue : Allow manual directions on dynamics to break alignment spanner automatically Issue 1433: \breakDynamicSpan breaks with \break (bounds of spanner are invalid) Issue 1259: DynamicTextSpanner #'style = #'none doesn't work over \break The list of patches still not dealt with is rather alarming: is it because devels are on holiday, Those four patches quoted above are mine, and I'm currently at vacation at home with my parents, so I simply don't find enough time to deal with them right now. I'll fix and close them in the next few days. Cheers, Reinhold ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes error for tuplet bracket direction calculation when tuplets contain rests. (issue4668045)
Pushed as eed6f105c0b478572ec2b8fa93e1f96c0c5869ba. Cheers, MS http://codereview.appspot.com/4668045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29
Hello, )-Original Message- )From: lilypond-devel-bounces+james.lowe=datacore@gnu.org )[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On )Behalf Of Reinhold Kainhofer )Sent: 28 July 2011 08:16 )To: Colin Campbell; Devel )Subject: Re: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29 ) )On Do., 28. Jul. 2011 04:04:21 CEST, Colin Campbell c...@shaw.ca )wrote: ) Countdown done, but still open/not marked fixed: ) From Wednesday July 27 ) Issue 732: Alignment problems when vertically stacking horizontally )centered stencils. ) Issue : Allow manual directions on dynamics to break alignment )spanner automatically ) Issue 1433: \breakDynamicSpan breaks with \break (bounds of spanner )are invalid) ) Issue 1259: DynamicTextSpanner #'style = #'none doesn't work over )\break ) ) The list of patches still not dealt with is rather alarming: is it ) because devels are on holiday, ) )Those four patches quoted above are mine, and I'm currently at vacation )at home with my parents, so I simply don't find enough time to deal with )them right now. I'll fix and close them in the next few days. )Cheers, )Reinhold ) --- I also keep half an eye on Rietveld issues being updated in the emails and Trackers not - as the patches are on Rietveld it is more than likely a dev will do one but forget the other. So I often step in and cut/paste the relevant comment on the Rietveld and update the Tracker. Until we get a single place to put issues and Patches I can't see this really changing and as has been said before, it is more important to keep the Devs slaving^H^H^H^H^H^H^H working away fixing and improving LP than worrying *too* much about the admin. James PA to Mike Solomon ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
little scheme problem (convert ly - xml)
Hi,
As you know , I have started coding the ly- xml in scheme,
but as i want to make the code easier to read, I started to create a list
of callback to retrieve information for example
so I wrote this (for example):
;; once you retrived the good object you just have to extract its value
;; functions to retrieve the value of duration/step/octave
(define function-value-list
(('duration . ((lambda(x) (ly:duration-log x
('step . ((lambda(x) (ly:pitch-notename x
('test . ((lambda(x) (begin (display salut :)
(display x) (display .\n)
('octave . ((lambda(x) (ly:pitch-octave x))
;; return false if value is not found
(define (get_value music name )
(if (assq name function-value-list)
(let (fun (car(assq name function-value-list)))
(fun music))
(#f)))
however , it does not seem to work , because is always says Wrong type
to apply: duration
even though I never called the function yet... if i am executing it
inside a lilypond file
i get this Unbound variable: function-value-list
so I begin to think it is impossible to create a list containing, is it ?
if so, i will have to create each function one by one, so it would be
longer and more difficult to edit ...
Thanks very much
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29
On Jul 28, 2011, at 10:07 AM, James Lowe wrote: PA to Mike Solomon :) Even with my new virtual box, I am sometimes forgetting to take certain steps to get a clean baseline (i.e. forgetting to commit changes before deleting a branch, which leaves a set of files in my new branch, which then gets compiled with a patch, etc.). That has gotten better in the past few days, but I still make mistakes (like the slur stuff). Your regtest and admin help is very appreciated! Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Moves tuplet numbers outside staff with their brackets. (issue4639075)
Pushed as 72210831b0366cb7c1f7009ba99a56538d68a7e5. Cheers, MS http://codereview.appspot.com/4639075/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: little scheme problem (convert ly - xml)
bigcab writes:
(define function-value-list
(('duration . ((lambda(x) (ly:duration-log x
What are you trying to achieve by doing (lambda (x) (foo x))?
('step . ((lambda(x) (ly:pitch-notename x
('test . ((lambda(x) (begin (display salut :)
(display x) (display .\n)
('octave . ((lambda(x) (ly:pitch-octave x))
You probably want something like
(define function-value-list
`((duration . (,ly:duration-log))
(step . (,ly:pitch-notename))
(test . (,lambda (x) (begin (display salut: ) ...)))
...))
Jan.
--
Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: little scheme problem (convert ly - xml)
Jan Nieuwenhuizen jann...@gnu.org writes:
bigcab writes:
(define function-value-list
(('duration . ((lambda(x) (ly:duration-log x
What are you trying to achieve by doing (lambda (x) (foo x))?
('step . ((lambda(x) (ly:pitch-notename x
('test . ((lambda(x) (begin (display salut :)
(display x) (display .\n)
('octave . ((lambda(x) (ly:pitch-octave x))
You probably want something like
(define function-value-list
`((duration . (,ly:duration-log))
(step . (,ly:pitch-notename))
(test . (,lambda (x) (begin (display salut: ) ...)))
...))
The begin form seems sort of pointless as a top level part in lambda.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: review process not working
Am Dienstag, 26. Juli 2011, 19:43:26 schrieb David Kastrup: Reinhold Kainhofer reinh...@kainhofer.com writes: So, it seems the only one who is aware of those rounding problems is David. The question then is, why didn't David do a review of the patch and now complains that the process is not working? Come on. Yes, I didn't intend it to sound like an ad-hominem attack. Sorry for that. One important thing with code reviews is that either one perfect reviewer (which doesn't exist, of course) looks at it, or many different eyes look at a patch and might observe problems. Most developers - me included - simply do not do enough code reviews. The reason is mostly that we all think that we don't know enough about the code or the area that the patch is about. Rather, we should still try to look at and understand those patches, because we might also spot some logic errors or style errors, even if we don t know anything about that area. Anyway, code review is no guarantee for perfect and fault-less patches. Rather, it minimizes the chance of bad code going into lilypond, and it increases the chance that problems are found. But 100% can never be achieved. And with the patch reviews and the patch countdown, at least we get some feedback now. A while ago it used to be luck if you posted a patch to the devel list and got one response eventually. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: review process not working
Reinhold Kainhofer reinh...@kainhofer.com writes: And with the patch reviews and the patch countdown, at least we get some feedback now. A while ago it used to be luck if you posted a patch to the devel list and got one response eventually. Well, that's what I experience with my syntax extensions. I'm currently down to eliminating some reduce/reduce conflicts because I am not happy with the semantics of the last patch version (which received no feedback like its predecessors), and then am likely to document and commit it. What worked before will continue to work except for some hypothetical borderline cases (not to be found in regtests) which you need to rewrite into something quite more convenient. The main benefit for the average Lilyponder will likely be that there will actually be documentation. The previous semantics were awkward and undocumented. So in my case, the review process tends to do nothing. Could be worse, but likely nobody except myself would know the difference. In the case I brought up here, the review process did a lot, but too superficially. Of those cases, the second one is much more likely to get an ISO certification for proper process. I don't feel good about either. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29
Hello, )-Original Message- )From: m...@apollinemike.com [mailto:m...@apollinemike.com] )Sent: 28 July 2011 09:16 )To: James Lowe )Cc: Reinhold Kainhofer; Colin Campbell; Devel )Subject: Re: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29 )Importance: Low ) )On Jul 28, 2011, at 10:07 AM, James Lowe wrote: ) ) PA to Mike Solomon ) ):) )Even with my new virtual box, I am sometimes forgetting to take certain )steps to get a clean baseline (i.e. forgetting to commit changes before )deleting a branch, which leaves a set of files in my new branch, which )then gets compiled with a patch, etc.). That has gotten better in the past )few days, but I still make mistakes (like the slur stuff). Your regtest and )admin help is very appreciated! ) )Cheers, )MS Mike, depending on your Host machine you can use snapshot of VBOX quite effectively, to snapshot a point where you KNOW you have a clean build and even create snaps of different stages of your dev. I use it a lot because I get confused with git stashing and popping, but also to save me having to keep making a clean make test-baseline (only because it is much more sure to go back to a snap than run the 'clean' make commands). James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re : little scheme problem (ly- xml )
Le 28/07/2011 13:36, lilypond-devel-requ...@gnu.org a écrit : Send lilypond-devel mailing list submissions to lilypond-devel@gnu.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.gnu.org/mailman/listinfo/lilypond-devel or, via email, send a message with subject or body 'help' to lilypond-devel-requ...@gnu.org You can reach the person managing the list at lilypond-devel-ow...@gnu.org When replying, please edit your Subject line so it is more specific than Re: Contents of lilypond-devel digest... Today's Topics: 1. Re: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29 (Reinhold Kainhofer) 2. Re: Fixes error for tuplet bracket direction calculation when tuplets contain rests. (issue4668045) (mts...@gmail.com) 3. RE: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29 (James Lowe) 4. little scheme problem (convert ly - xml) (bigcab) 5. Re: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29 (m...@apollinemike.com) 6. Re: Moves tuplet numbers outside staff with their brackets. (issue4639075) (mts...@gmail.com) 7. Re: little scheme problem (convert ly - xml) (Jan Nieuwenhuizen) 8. Re: little scheme problem (convert ly - xml) (David Kastrup) 9. Re: review process not working (Reinhold Kainhofer) 10. Re: review process not working (David Kastrup) -- Message: 1 Date: Thu, 28 Jul 2011 09:16:28 +0200 From: Reinhold Kainhoferreinh...@kainhofer.com To: Colin Campbellc...@shaw.ca, Devellilypond-devel@gnu.org Subject: Re: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29 Message-ID:1311837388.7156.2.camel@Nokia-N900 Content-Type: text/plain; charset=utf-8 On Do., 28. Jul. 2011 04:04:21 CEST, Colin Campbellc...@shaw.ca wrote: Countdown done, but still open/not marked fixed: ? From Wednesday July 27 Issue 732: Alignment problems when vertically stacking horizontally centered stencils. Issue : Allow manual directions on dynamics to break alignment spanner automatically ?Issue 1433: \breakDynamicSpan breaks with \break (bounds of spanner are invalid) ?Issue 1259: DynamicTextSpanner #'style = #'none doesn't work over \break The list of patches still not dealt with is rather alarming: is it because devels are on holiday, Those four patches quoted above are mine, and I'm currently at vacation at home with my parents, so I simply don't find enough time to deal with them right now. I'll fix and close them in the next few days. Cheers, Reinhold -- Message: 2 Date: Thu, 28 Jul 2011 07:59:06 + From: mts...@gmail.com To: james.l...@datacore.com, hanw...@gmail.com, pkx1...@gmail.com, m...@apollinemike.com, k-ohara5...@oco.net, n.putt...@gmail.com Cc: re...@codereview.appspotmail.com, lilypond-devel@gnu.org Subject: Re: Fixes error for tuplet bracket direction calculation when tuplets contain rests. (issue4668045) Message-ID:20cf3011dfc30721b004a91c8...@google.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Pushed as eed6f105c0b478572ec2b8fa93e1f96c0c5869ba. Cheers, MS http://codereview.appspot.com/4668045/ -- Message: 3 Date: Thu, 28 Jul 2011 08:07:08 + From: James Lowejames.l...@datacore.com To: Reinhold Kainhoferreinh...@kainhofer.com, Colin Campbell c...@shaw.ca, Devellilypond-devel@gnu.org Subject: RE: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29 Message-ID: ddfaf00dc0c80042bab7bba1b3838af914eff...@mail-ftl1.datacoresoftware.com Content-Type: text/plain; charset=utf-8 Hello, )-Original Message- )From: lilypond-devel-bounces+james.lowe=datacore@gnu.org )[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On )Behalf Of Reinhold Kainhofer )Sent: 28 July 2011 08:16 )To: Colin Campbell; Devel )Subject: Re: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29 ) )On Do., 28. Jul. 2011 04:04:21 CEST, Colin Campbellc...@shaw.ca )wrote: ) Countdown done, but still open/not marked fixed: )? From Wednesday July 27 ) Issue 732: Alignment problems when vertically stacking horizontally )centered stencils. ) Issue : Allow manual directions on dynamics to break alignment )spanner automatically )?Issue 1433: \breakDynamicSpan breaks with \break (bounds of spanner )are invalid) )?Issue 1259: DynamicTextSpanner #'style = #'none doesn't work over )\break ) ) The list of patches still not dealt with is rather alarming: is it ) because devels are on holiday, ) )Those four patches quoted above are mine, and I'm currently at vacation )at home with my parents, so I simply don't find enough time to deal with )them right now. I'll fix and close them in the next few days. )Cheers, )Reinhold ) --- I also keep half an eye on Rietveld issues being updated in the emails and Trackers not - as the patches are on Rietveld it is more than likely
New engraver for braces (issue4807053)
Reviewers: , Message: Hi! This patchs allows to add braces the same way as arpeggios. Very useful for complex organ music. Check this out, there is several examples: http://imslp.org/wiki/12_Pi%C3%A8ces_pour_Orgue_(Gigout,_Eug%C3%A8ne) For the moment, the new engraver is a clone of Arpeggio_engraver. But I would like to add a command to attach text directly to braces (see IMSLP's score). Since there's many cases for the text attachment points, I think a new engraver is required. Done with Mike's help. The regression test is temporary. Regards, Bertrand PS: Li Jie Wong requested this last year : http://lists.gnu.org/archive/html/lilypond-user/2010-11/msg00361.html Please review this at http://codereview.appspot.com/4807053/ Affected files: A input/regression/braces.ly M lily/arpeggio.cc A lily/brace-engraver.cc M lily/include/arpeggio.hh M lily/span-arpeggio-engraver.cc A lily/span-brace-engraver.cc M ly/engraver-init.ly M ly/property-init.ly M scm/define-context-properties.scm M scm/define-event-classes.scm M scm/define-grob-interfaces.scm M scm/define-grob-properties.scm M scm/define-grobs.scm M scm/define-music-display-methods.scm M scm/define-music-types.scm M scm/safe-lily.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds longas, maximas and non-standard tweaks to MultiMeasureRest (issue4536068)
http://codereview.appspot.com/4536068/diff/37002/lily/multi-measure-rest.cc#newcode241 lily/multi-measure-rest.cc:241: length = (2 -i) / 2; The division by 2 changes the result. Not that I understand too well what it is supposed to be doing. To be honest, I never understood well how this bitset operator works. What I see is that 2 -i gives the same result than 2^(-i+1). I should have write 2 (-i + 1) instead of /2... Besides this, I would like to remove these ugly ifs I added yesterday, but I don't see a better human-readable solution. Bertrand http://codereview.appspot.com/4536068/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds longas, maximas and non-standard tweaks to MultiMeasureRest (issue4536068)
To be honest, I never understood well how this bitset operator works. adds trailing zeros in binary. What I see is that 2 -i gives the same result than 2^(-i+1). I should have write 2 (-i + 1) instead of /2... the +1 multiplies by 2, not divides. perhaps the best would be 1 -i. now I'll really take a look at the actual patch... p ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds longas, maximas and non-standard tweaks to MultiMeasureRest (issue4536068)
I should have write 2 (-i + 1) instead of /2... the +1 multiplies by 2, not divides. Whoops, I meant -(i + 1)... perhaps the best would be 1 -i. Thanks. When I told you I never understood , I wasn't kidding! An update will follow this comment. Bertrand http://codereview.appspot.com/4536068/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 1214: cueDuring and quoteDuring should also quote voices that create subvoices (issue4816044)
Reviewers: J_lowe, Keith,
Message:
On 2011/07/26 02:17:28, Keith wrote:
I like it, although I can still get the error if I put a new voice in
the quoted
expression like this:
quoteMe = \relative c' \new Voice {
Yeah, but then we have a general problem: Which voice do we want to
quote?
http://codereview.appspot.com/4816044/diff/3001/input/regression/quote-during-subvoice.ly#newcode12
input/regression/quote-during-subvoice.ly:12: \new Voice {
You might keep the main voice going in parallel
{ c4 c }
\new Voice { g4 g }
to ensure that the patch continues to work (as it does now) to quote
an
instrument that is itself quoting third. (I've actually wanted to to
this, for
taking cues, in a couple situations.)
Yes, good idea, too.
It is interesting, in a good way, how it works with
{c4 c} \\ {g g}
divisi parts if both parts have the same rhythm,
but I would not encourage that we try to guarantee nor advertise that.
The \\ construct uses two new voices, so none of the notes will be
quoted.
Cheers,
Reinhold
Description:
Fix 1214: cueDuring and quoteDuring should also quote voices that create
subvoices
If a voice was quoted that created a subvoice, add-quotable wrongly
selected
only that subvoice for quoting rather than the original voice.
The proper fix is to correctly use the assoc list returned by
recording-group-emulate. We need to hand it a proper unique voice name
and can then extract the events for just this voice, no matter which
other
voices are created.
Please review this at http://codereview.appspot.com/4816044/
Affected files:
A input/regression/quote-during-subvoice.ly
M scm/part-combiner.scm
Index: input/regression/quote-during-subvoice.ly
diff --git a/input/regression/quote-during-subvoice.ly
b/input/regression/quote-during-subvoice.ly
new file mode 100644
index
..f8d61e34923683a2b0fffeaf654cf917360e7ce3
--- /dev/null
+++ b/input/regression/quote-during-subvoice.ly
@@ -0,0 +1,21 @@
+\version 2.15.6
+
+\header {
+ texidoc = @code{\\quoteDuring} and @code{\\cueDuring} shall properly
quote
+voices that create a sub-voice. The sub-voice will not be quoted, though.
+
+}
+
+
+quoteMe = \relative c' {
+ c4 c
+ \new Voice {
+c4 c
+ }
+}
+\addQuote quoteMe \quoteMe
+
+\relative c'' {
+ c4 \cueDuring #quoteMe #DOWN { r4 } % - show a cue note from quoteMe
+ c4 \cueDuring #quoteMe #DOWN { r4 } % - no cue note due to sub-voice
+}
Index: scm/part-combiner.scm
diff --git a/scm/part-combiner.scm b/scm/part-combiner.scm
index
0e72ebe2a057eef1f4284e9c4d69fa3c4e20ee94..54f9ea4a57aeefe4a3389c6a779e85cc06d78c1d
100644
--- a/scm/part-combiner.scm
+++ b/scm/part-combiner.scm
@@ -571,10 +571,18 @@ the mark when there are no spanners active.
(define-public (add-quotable parser name mus)
(let* ((tab (eval 'musicQuotes (current-module)))
-(context-list (recording-group-emulate (context-spec-music mus 'Voice)
- (ly:parser-lookup parser
'partCombineListener
-(if (pair? context-list)
- (hash-set! tab name
- ;; cdr : skip name string
- (list-vector (reverse! (cdar context-list)
- '()))
+ ;; If a Voice is passed, use its contents:
+ (contents (if (equal? (ly:music-property
mus 'name) 'ContextSpeccedMusic)
+ (ly:music-property mus 'element)
+ mus))
+ (voicename (get-next-unique-voice-name))
+ ;; recording-group-emulate returns an assoc list, so hand it a
+ ;; proper unique context name and extract that key:
+ (context-list (recording-group-emulate (context-spec-music
contents 'Voice voicename)
+(ly:parser-lookup
parser 'partCombineListener)))
+ (quote-contents (if (assoc voicename context-list)
+ (assoc-get voicename context-list)
+ '(
+
+(if quote-contents
+(hash-set! tab name (list-vector (reverse!
quote-contents '()))
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds longas, maximas and non-standard tweaks to MultiMeasureRest (issue4536068)
hi Bertrand, I started at the patch but it's quite difficult for now, I hope I'll have enough time in the evening. till then could you tell me whether usable-duration-logs is ordered? is it a range or can it have holes? thanks, p ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29
On 11-07-28 01:16 AM, Reinhold Kainhofer wrote: On Do., 28. Jul. 2011 04:04:21 CEST, Colin Campbellc...@shaw.ca wrote: Countdown done, but still open/not marked fixed: From Wednesday July 27 Issue 732: Alignment problems when vertically stacking horizontally centered stencils. Issue : Allow manual directions on dynamics to break alignment spanner automatically Issue 1433: \breakDynamicSpan breaks with \break (bounds of spanner are invalid) Issue 1259: DynamicTextSpanner #'style = #'none doesn't work over \break The list of patches still not dealt with is rather alarming: is it because devels are on holiday, Those four patches quoted above are mine, and I'm currently at vacation at home with my parents, so I simply don't find enough time to deal with them right now. I'll fix and close them in the next few days. Cheers, Reinhold No worries, Reinhold. Thanks for your hard work, and I see you've already pushed them. Great to get that group around the dynamic spanner off this list! Enjoy the rest of the vacation, and sorry for the nagging. Colin -- The human race has one really effective weapon, and that is laughter. -- Mark Twain ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29
On 11-07-28 12:48 AM, m...@apollinemike.com wrote: On Jul 28, 2011, at 4:04 AM, Colin Campbell wrote: New today, for Friday: Issue 621 http://code.google.com/p/lilypond/issues/detail?id=621: Dynamics should avoid cross-staff BarLines (e.g. GrandStaff, PianoStaff etc) - Rietveld Countdown done, but still open/not marked fixed: From Wednesday July 27 Issue 732 http://code.google.com/p/lilypond/issues/detail?id=732: Alignment problems when vertically stacking horizontally centered stencils. - Rietveld Issue 4798050 http://codereview.appspot.com/4798050/: Fix 732: center-column ignored left half of stencil extent - collision with previous stencil Issue http://code.google.com/p/lilypond/issues/detail?id=: Allow manual directions on dynamics to break alignment spanner automatically - Rietveld Issue 4810048 http://codereview.appspot.com/4810048/: Fix : Break dynamic line spanner if different direction is explicitly given Issue 1730 http://code.google.com/p/lilypond/issues/detail?id=1730: Documentation for lilypond-windows.exe and -dgui option - Rietveld Issue 4806050 http://codereview.appspot.com/4806050/: Doc: Usage - new option for lilypond-book And a couple of Rietveld-only patches: Issue 4668045 http://codereview.appspot.com/4668045/: Fixes error for tuplet bracket direction calculation when tuplets contain rests. Issue 4639075 http://codereview.appspot.com/4639075/: Moves tuplet numbers outside staff with their brackets. Issue 4580041 http://codereview.appspot.com/4580041/: Current state of automatic footnotes. Issue 1433 http://code.google.com/p/lilypond/issues/detail?id=1433: \breakDynamicSpan breaks with \break (bounds of spanner are invalid) - Rietveld Issue 4630070 http://codereview.appspot.com/4630070/: Fix issues 1259 and 1433 (\breakDynamicSpan and a spanner's style=#'none over a line break) Issue 1259 http://code.google.com/p/lilypond/issues/detail?id=1259: DynamicTextSpanner #'style = #'none doesn't work over \break The list of patches still not dealt with is rather alarming: is it because devels are on holiday, am I missing the closed or fixed tags in Rietveld and Google Code? How can I help you folk keep this moving? Hey Colin, Sorry for the delay! I'll take care of a large portion of my backlog today (I run an extra regtest before pushing, which slows me down a bit). Cheers, MS No problem, Mike: extra testing is always in order. Many's the time I wished I'd checked the order first: ready, fire, aim or . . . Thanks for the effort! Colin -- The human race has one really effective weapon, and that is laughter. -- Mark Twain ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29
On 11-07-27 10:59 PM, Graham Percival wrote: On Wed, Jul 27, 2011 at 08:04:21PM -0600, Colin Campbell wrote: The list of patches still not dealt with is rather alarming: is it because devels are on holiday, am I missing the closed or fixed tags in Rietveld and Google Code? How can I help you folk keep this moving? You could check the git changelog (either in gitk, or on the web) to make sure that nobody pushed something without marking it fixed. Then send private emails to people reminding them to push, or to send final patches to me if they don't have push ability. Private emails always get more attention. Yes, it adds another 30 minutes to your job, but with the looming Aug 1 deadline before existing C++ patches get awkward, I think it's worth the effort. Cheers, - Graham Good points, Graham, and I'll try to do that. Colin -- The human race has one really effective weapon, and that is laughter. -- Mark Twain ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds longas, maximas and non-standard tweaks to MultiMeasureRest (issue4536068)
It doesn't need to be ordered. It can have holes, but there's a small issue with this for now: Church rests are only looking for maximum and minimum values. You can therefore find longas in a church rest if you set usable-duration-logs to '(0 -1 -3). I don't know whether it's better to keep this system or to stick to usable-duration-logs. This would be logical to stick to the list, but church rests are something special that doesn't behave the same way than uncompressed multi-measure rests. Maybe a separated list for church rests would be the best solution... Thanks, Bertrand http://codereview.appspot.com/4536068/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Current state of automatic footnotes. (issue4580041)
Many thanks to everyone for their help on this. Pushed as 233aad0ba9781e43424c4e77a859e42b660210e6. Cheers, MS http://codereview.appspot.com/4580041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GOP-PROP 7: Developers as resources
http://lilypond.org/~graham/gop/gop_7.html Recent discussions have prompted me to clarify this. ** Proposal summary How should treat+view developers? I see three main contenders: 1. Independent volunteers: each person does whatever they want, whenever they want. We have busy careers and lives; we make no expectations of action from anybody (with the exception of 6 people in “Meister” positions). 2. Human resources: developers are members of a team; we can build better software with more coordination. Developers will be assigned bugs to fix, features to implement, and patches to review. 3. Mixed: we form 1 or 2 teams of developers, plus indepedents. Developers are still free to do whatever they want whenever they want as independents, but they can also sign up for a team for X hours a week. For those X hours, they will be assigned bugs to fix, features to implement, and patches to review. ** Rationale I have historically been very vocal about treating developers at “independent volunteers”, but some recent discussions are making me wonder if that’s the best way to go. Our policy on this topic will influence many upcoming discussions. ** Amateur orchestra I deliberately chose the loaded term “human resources” to get our immediate distaste out of the way. Here’s the positive spin on that idea: I shall describe the workings of the (Vancouver) “West Coast Symphony Orchestra” (at least when I was playing with them, back in 2002-2006). This orchestras is the best amateur orchestra in Vancouver; it is better than most university student orchetras. Most of its members are doctors, engineers, or lawyers, and the average age is between like 40-50. As you would expect, they have busy careers, growing families, but still love to play music. There are 5-6 weekly rehearsals for each concert. The list of performers for a particular concert is relatively fluid; there’s up to 30% fluctuation in the list of performers. A week or two before each set of rehearsals start, a list is passed around where people sign up for the concert or not. There is no discouragement from missing a concert – members know that they all have busy lives, and if there is a big deadline at work or a family vacation during a rehearsal period, they simply do not sign up for that concert. However, if you do sign up for a concert, then you are normally only allowed to miss one rehearsal. Orchestras are particularly interesting because they involve a voluntary surrender of freedom. When the conductor indicates a tempo, you don’t start playing your part however you want; you follow his tempo. If the conductor tells your section to play quieter so that the soloist can be heard, you don’t start arguing. You follow his directions, even if you think he’s wrong – not because you’re getting paid to do so, but because you trust that in the long run, having a single authority controlling 80 musicians allows them to produce better music than 80 musicians all exercising their independent judgement. ** Problems with independent judgement The orchestra idea (or choir, or dance troup, or any volunteer activity which involves following somebody else’s orders) could be benefitial in lilypond. We’ve seen a certain amount of friction lately with reviews. Not enough reviews; reviews are too superficial; feeling uncertain about reviewing code that’s not your speciality. To take one specific case by the bull’s horns: David has identified a few problems in an old commit. We’ve noted a few problems, such as non-experts reviewing the patch (which is still fantastically better than nobody reviewing the patch!). But David is also interested in the parser – which is an area of lilypond that has even fewer experts, and even less interest, than the old patch that introduced a few problems. If we had a central authority leading a team (or teams) of developers – or at least, leading developers for X hours a week – then we could “enforce” reviews. Maybe July-August would be directed towards the graphical display of rhythms. That team would dissect any patch for beaming, drawing longas, etc; any patch to the parser would be ignored (at least, ignored during the X hours of team work). But perhaps the team leader would decide to look at parser stuff in November. That’s not ideal for David, since he’s interested in working on that stuff now... but perhaps he’d be willing to wait until Nov (or Oct), so that at least when it happens, there will be a serious discussion about those problems and serious review of those patches. ** Bottom line We’re not going to pick option 2 “treat developers like human resources”. I’m mainly wondering if there’s enough interest in option 3 “mixed” to make it worth doing. Note that you don’t need to spend all your lilypond time on the team-based approach of the “mixed” option. You could sign up for 5 hours of “team work” each week, but still spend another 5 hours on your own lilypond work, submitting patches and
Re: Doc: NR Added new Node for Footnotes (issue4751045)
note from Mike --snip-- I just pushed a patch for automatic footnotes. Everything you need to know about them exists in the two new regtests (233aad0ba9781e43424c4e77a859e42b660210e6). The most important thing to note is that, if people want to use non-automatic footnotes, they must now add footnote-auto-numbering=##f in the paper block. Otherwise, Lily will attempt to do auto numbering and erase whatever numbering scheme the person is manually using. --snip-- http://codereview.appspot.com/4751045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re : little scheme problem (ly- xml )
(define function-value-list '((duration . ( ,ly:duration-log )) (step . (,ly:pitch-notename )) (octave . (,ly:pitch-octave )) (test . (,display At the beginning of line 2, replace the apostrophe ' by ` (a semiquote in scheme) http://www.gnu.org/software/guile/manual/guile.html#Expression-Syntax (define function-value-list `((duration . ( ,ly:duration-log )) etc ... Gilles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: font: change breve vertical lines (issue4748044)
A pdf proof file is attached to tracker issue http://code.google.com/p/lilypond/issues/detail?id=1767 The gap in smallest font sizes was reduced according to Bertrand's suggestion, and the line height was increased just a bit according to my friend's suggestion. I don't feel strong about these changes; for me both this version and previous version is good enough (and definately better than current Lily). http://codereview.appspot.com/4748044/diff/1/mf/feta-noteheads.mf File mf/feta-noteheads.mf (right): http://codereview.appspot.com/4748044/diff/1/mf/feta-noteheads.mf#newcode181 mf/feta-noteheads.mf:181: % when there is an interval of fourth. On 2011/07/27 05:03:15, lemzwerg wrote: Wouldn't it be simpler to explicitly specify the line length instead of using such a complicated algorithm? I mean a global variable to be added to the various feta-noteheadsXX.mf files. I know that none of the existing size driver files contain such a variable except the standard assignment of `design_size', but this shouldn't stop you to add something since it would be the logical place to add. Cf. similar control files in other MF fonts like TeX's Computer Modern, which are full of such meta-variables. Aww, i was so proud of this code... Frankly, i don't think we will gain anything from defining a global value. The algorithm i wrote is a bit complicated, but i thinks is easier to understand than what you suggest (if i understood your suggestion correctly). It keeps things in one place instead of values flying all around (at least that's how i see it). http://codereview.appspot.com/4748044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New engraver for braces (issue4807053)
I updated the patch to work on the latest git HEAD. After doing a clean regtest comparison (git clean -fxd, config, make, make test-baseline, make check), I don't see anything. The logs' names show this is due to Mike's last commits. Regards, Bertrand http://codereview.appspot.com/4807053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
auto numbering footnote checkin doesn't play with \null and \musicglyph
Mike,
I *think* your recent checkin did something to your original \footnote[Grob]
code because taking a snippet from my example in my in-progress doc patch
\version 2.15.6
#(set-default-paper-size a6)
\book {
\relative c' {
c1
\breathe
\footnoteGrob #'BreathingSign #'(1 . 1)
\markup { \musicglyph #rests.4 }
\markup { \null }
}
}
Worked fine.
Now it prints the numeral '1' all over the place actually. If you change \null
to , then it goes away but I get a number with no footnote. It also seems to
ignore the glyph used in a markup.
My original intention in my doc patch was to show how to have a 'footnoteGrob
markup without a footnote (and also show how you can add space between the
copyright and the last footnote), Neil suggested I use \null instead of
which did the same thing, until now.
regards
James
weird.pdf
Description: weird.pdf
before.pdf
Description: before.pdf
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove special case in staff-spacing (issue4188051)
Keith, I am so sorry - you've sent me this patch ages ago and i forgot about it! :( I've checked regtests to see how it works and it's great!! However, i cannot write any meaningful review, because i don't understand what's going on here at all :( Could you add some comments for rookies like me (the more, the better)? Thanks!! Janek http://codereview.appspot.com/4188051/diff/17001/scm/define-grobs.scm File scm/define-grobs.scm (left): http://codereview.appspot.com/4188051/diff/17001/scm/define-grobs.scm#oldcode2237 scm/define-grobs.scm:2237: (extra-spacing-height . (-1.0 . 1.0)) Why this disappeared? http://codereview.appspot.com/4188051/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 1214: cueDuring and quoteDuring should also quote voices that create subvoices (issue4816044)
On Thu, 28 Jul 2011 05:46:29 -0700, reinhold.kainho...@gmail.com wrote:
Message:
On 2011/07/26 02:17:28, Keith wrote:
I like it, although I can still get the error if I put a new voice in
the quoted
expression like this:
quoteMe = \relative c' \new Voice {
Yeah, but then we have a general problem: Which voice do we want to
quote?
I would not expect LilyPond to divine the answer to that question,
but it would be nice to avoid exiting the program with
ERROR: Value out of range: 0
It is interesting, in a good way, how it works with
{c4 c} \\ {g g}
divisi parts if both parts have the same rhythm,
but I would not encourage that we try to guarantee nor advertise that.
The \\ construct uses two new voices, so none of the notes will be
quoted.
But somehow your patch quotes them both, showing as a c g in the cue
voice.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: some comments do not appear in the tracker page
James, 2011/7/27 James Lowe james.l...@datacore.com: Janek )On Behalf Of Janek Warchol: )there is a problem with comments in the tracker. At least 2 comments )didn't make it to the changing G clef issue page: )- Trevor's comment from July 26th, containing sentence The G clef font )was changed 18 months or so ago by Carl without all this fuss )- Carls comment, perhaps from July 25th, containing sentence This )proposal was based on Graham's assertion that 2.16 is 10 days away from )release Are these messages you are missing on the tracker itself (as opposed to someone just replying to the email that the tracker generates)? Umm, i don't understand what you mean... When you go to http://code.google.com/p/lilypond/issues/detail?id=1752 , do you see any message sent by Trevor? For example I agree. LilyPond has many glyphs. If we start using overrides to select glyphs with minor differences where might it end? ? I don't see it there and it didn't appear in my e-mail account. The only place where i can see it is bug- archives: http://lists.gnu.org/archive/html/bug-lilypond/2011-07/msg00375.html ... oh well, i found it. I've disabled receiving e-mails from bug-lilypond, silly me. I remember now that i did this a long time ago as they seemed irrelevant to me, and i never noticed the difference... Ugh bangs his head with a club. Still, i think that it'd be better if every message related to a tracker issue appeared as a comment in the tracker. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Postscript printer errors with rounded barlines?
2011/7/27 Han-Wen Nienhuys hanw...@gmail.com: On Wed, Jul 27, 2011 at 3:23 PM, Jan Warchoł lemniskata.bernoulli...@gmail.com wrote: I think this is an other issue. Due to rounding, PDF viewers can err the placement of the barline by a pixel. This is insolvable, as there is no way to hint that the barline should coincide with the staffline, yet we need to go the end of the barline to get the correct effect in the corners in staves. I'd accept this if it were not for the fact that Finale seems to handle this perfectly. I've never experienced any sticking out barlines in Finale pdfs, neither on screen nor in print (i can send you some if you want). Also, the thickness of the stems and barlines is consistent in Finale pdfs (i.e. it looks like second image from here http://lists.gnu.org/archive/html/lilypond-devel/2007-07/msg00076.html while Lily output looks like first one). I'd say that the fact that Finale does something this basic better than LilyPond is a serious insult to us, given how much Finale sucks in these matters (for example in flag attachment, see attached). You can make the problem disappear by - hard coding the output to a certain resolution Umm, i don't understand what you mean... - making the bar go to the middle of the staffline, rather than the outside. I have a patch doing this: http://codereview.appspot.com/4809057 both have disadvantages. (what does finale's barline at the end of a staff look like?) Sharp and pointy, example attached. cheers, Janek Canticorum.pdf Description: Adobe PDF document ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Ends of barlines are hidden in staff lines. (issue4809057)
Reviewers: hanwenn,
Message:
http://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg01051.html
2011/7/27 Han-Wen Nienhuys hanw...@gmail.com:
Due to rounding, PDF viewers can err
the placement of the barline by a pixel.
[so that it looks like sticking out of staff]
You can make the problem disappear by
- hard coding the output to a certain resolution
- making the bar go to the middle of the staffline,
rather than the outside.
both have disadvantages.
This patch does the second thing. What disadvantages do you see besides
what happens when barline and staff have different colors?
cheers,
Janek
Description:
Ends of barlines are hidden in staff lines.
Barlines are made a little shorter, so that the end of the barline
doesn't touch
the outer edge of staff line - it ends in the middle of staff line now.
This prevets artifacts in pdf viewing and printing.
Please review this at http://codereview.appspot.com/4809057/
Affected files:
M lily/bar-line.cc
M lily/include/staff-symbol-referencer.hh
M lily/staff-symbol-referencer.cc
Index: lily/bar-line.cc
diff --git a/lily/bar-line.cc b/lily/bar-line.cc
index
a2d6588726bb823c03075ca65dc35b663ecffaa3..64ca4d0dbd7bbb80f8c8aa87e4ec8966e2d7e58d
100644
--- a/lily/bar-line.cc
+++ b/lily/bar-line.cc
@@ -34,8 +34,22 @@ Bar_line::calc_bar_extent (SCM smob)
Interval result;
Grob *me = unsmob_grob (smob);
if (Grob *staff = Staff_symbol_referencer::get_staff_symbol (me))
-result = staff-extent (staff, Y_AXIS);
-
+{
+ result = staff-extent (staff, Y_AXIS);
+
+ /* Due to rounding problems, barlines extending to the outermost
edges
+ of the staff lines appear wrongly in on-screen display
+ (and, to a lesser extent, in print) - they stick out a pixel.
+ The solution is to extend barlines only to the middle
+ of the staff line - unless they have different colors,
+ when it would be undesirable.
+ */
+ SCM bar_line_color = me-get_property (color);
+ SCM staff_color = Staff_symbol_referencer::color (me);
+ if (bar_line_color == staff_color)
+ result *= (1 - 0.5 * (Staff_symbol_referencer::line_thickness (me) /
+ Staff_symbol_referencer::staff_radius (me)));
+}
return ly_interval2scm (result);
}
Index: lily/include/staff-symbol-referencer.hh
diff --git a/lily/include/staff-symbol-referencer.hh
b/lily/include/staff-symbol-referencer.hh
index
ed6156c62c78b1a1acae8423c1906d6e10cf8226..39889f2388f7a0111bad4c8d41207a5c26444641
100644
--- a/lily/include/staff-symbol-referencer.hh
+++ b/lily/include/staff-symbol-referencer.hh
@@ -40,6 +40,7 @@ public:
typeface. ie. leading is vertical space.
*/
static Real line_thickness (Grob *);
+ static SCM color (Grob *);
static Real staff_space (Grob *);
static Grob *get_staff_symbol (Grob *);
static bool on_line (Grob *, int);
Index: lily/staff-symbol-referencer.cc
diff --git a/lily/staff-symbol-referencer.cc
b/lily/staff-symbol-referencer.cc
index
2939e0c0614fdb035fe5a62409c4708f7bbf03ee..fcf7c3b76a900ce0bbd33fd4e08da8f3c1fcca6c
100644
--- a/lily/staff-symbol-referencer.cc
+++ b/lily/staff-symbol-referencer.cc
@@ -63,6 +63,15 @@ Staff_symbol_referencer::staff_space (Grob *me)
return 1.0;
}
+SCM
+Staff_symbol_referencer::color (Grob *me)
+{
+ Grob *st = get_staff_symbol (me);
+ if (st)
+return st-get_property (color);
+ return ly_symbol2scm (black);
+}
+
Real
Staff_symbol_referencer::line_thickness (Grob *me)
{
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove special case in staff-spacing (issue4188051)
On 2011/07/29 04:31:00, Janek Warchol wrote: Could you add some comments for rookies like me (the more, the better)? Some explanatory comments. (English takes a lot more space than C.) http://codereview.appspot.com/4188051/diff/17001/lily/spacing-spanner.cc File lily/spacing-spanner.cc (right): http://codereview.appspot.com/4188051/diff/17001/lily/spacing-spanner.cc#newcode526 lily/spacing-spanner.cc:526: Real full_measure_extra_space = robust_scm2double (l-get_property (full-measure-extra-space), 1.0); I moved the addition of this space (before a single note-column when it is alone in a measure) earlier because ... http://codereview.appspot.com/4188051/diff/17001/lily/spacing-spanner.cc#newcode539 lily/spacing-spanner.cc:539: spring = merge_springs (springs); ..when merge_springs() [in spring.cc] combines the desired spacing from all voices/staves in the system, it lengthens the relaxed-spring distance of the combined spring enough to give 0.3 space clearance. The old code first ensured that accidentals were at least 0.3-space away from the barline, and then added the full-measure-extra-space on top of that. http://codereview.appspot.com/4188051/diff/17001/lily/staff-spacing.cc File lily/staff-spacing.cc (right): http://codereview.appspot.com/4188051/diff/17001/lily/staff-spacing.cc#newcode208 lily/staff-spacing.cc:208: ideal = max (ideal, fixed); At an earlier step, while looking up the space to leave after a bar-line or clef or similar, the old code made sure that 'fixed' spacing was enough to leave a bit of clearance. The 'fixed' distance was intended to be what gets left if the line is moderately tight, so 'tight' distance might be a better name. The problem was that any adjustment to 'fixed' also applied to 'ideal'. If an accidental would not fit in the tight-spacing gap between a notehead and barline (they never do) then the 'ideal' distance to the nothead was increased to the right by nearly the full width of the accidental. There is no reason to lengthen a spring when the line has plenty of room, merely because the space would have been tight if the line were compressed. Better to make the spring stiffer, and change the 'ideal' distance as little as possible. http://codereview.appspot.com/4188051/diff/17001/lily/staff-spacing.cc#newcode212 lily/staff-spacing.cc:212: ret.set_inverse_compress_strength (max (0.0, ideal - fixed)); This addition is for issue 1785. Before 2007 there was only one kind of strength so one line was enough. http://codereview.appspot.com/4188051/diff/17001/scm/define-grobs.scm File scm/define-grobs.scm (left): http://codereview.appspot.com/4188051/diff/17001/scm/define-grobs.scm#oldcode2237 scm/define-grobs.scm:2237: (extra-spacing-height . (-1.0 . 1.0)) On 2011/07/29 04:31:00, Janek Warchol wrote: Why this disappeared? I'm glad you asked. I /thought/ that I had added this as a hack to solve issue 1229, which hack would not be necessary if space-alist works correctly, but I don't see it in my patch. Next time I have linux up I'll use git-blame to learn why this was added, and put it back if the reason still holds. http://codereview.appspot.com/4188051/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: modifying default behaviour of tremolo slashes (issue4636081)
New patch set uploaded. Minor style change: slash shape that was named default (which was confusing) is now named parallelogram (because that's how it looks like). If you don't like parallelograms ;) we can name it beam-like or sth. http://codereview.appspot.com/4636081/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
parser.yy: rearrange to allow more lenient use of music arguments for music functions. (issue4815052)
Reviewers: ,
Message:
I should point out that I consider this a merge candidate. AFAICT, it
passes the regtests.
Description:
parser.yy: rearrange to allow more lenient use of music arguments for
music functions.
This change may be somewhat contentious: it removes a lot of
opportunities for syntax errors by allowing a lot of music functions
to work that did not do so previously.
For one thing, you can use a ly:music? style signature as often as you
want to in all music functions. There are some cases where it will
only be accepted in closed form, namely as a music identifier or a
music expression enclosed in { ... } or ... . Those cases are
before a post-event not belonging to the music argument, or a duration
argument.
Music functions can be used in a number of places with different
semantics, not necessarily the cleanest thing. When they are used as
post-events and have a music argument last, they will actually try
getting a post-event as that music argument. What is new (and
probably less than fabulous) that they will instead accept a closed
form music expression.
However, when such a function is used as a primary music event, its
last argument will be a regular music expression anyway. So it is not
like this argument dichotomy was really all that novel.
In a similar vein, as a chord constituent, a music function will
accept a chord constituent in the place of a prospective last music
argument.
It does not seem overly satisfactory that only the last such component
will be syntactically warped according to the surrounding. Perhaps
one should use different signatures in the first place.
Suggestions welcome.
Please review this at http://codereview.appspot.com/4815052/
Affected files:
M Documentation/extending/programming-interface.itely
M lily/parser.yy
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
