Re: Issue 37 - new work
Am 28.01.2011 20:42, schrieb Han-Wen Nienhuys: On Fri, Jan 28, 2011 at 4:43 PM, Graham Percival gra...@percival-music.ca wrote: On Fri, Jan 28, 2011 at 04:18:16PM -0200, Han-Wen Nienhuys wrote: On Fri, Jan 28, 2011 at 11:43 AM, Graham Percival gra...@percival-music.ca wrote: lilypond -p 0 my_file.ly% for quick work lilypond -p 2 my_file.ly% for a draft to print out lilypond -p 9 my_file.ly% for the final score I think most of these will go unused, as very few people will know how and when to tune them. Having configurable settings is neat, but it's far more important to do the right thing by default in 95% of the cases. That's actually precisely why I'm suggesting a -p X option. People (generally) aren't going to look into the depths that's even worse, because people that will want to use this option won't even understand what it does. It's the same time of idiocy of Windows' and IE settings: do you want low, medium or high for hardware acceleration, internet privacy. If this is done similar to LaTeX packages where you can enable the option draft to speed up compiling, and if everything looks ok, you remove the draft and that's it, then this would be not too confusing for users. What about something like \draftModeOn / \draftModeOff ? Just my 2ct Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 37 - new work
Marc Hohl m...@hohlart.de writes: If this is done similar to LaTeX packages where you can enable the option draft to speed up compiling, and if everything looks ok, you remove the draft and that's it, then this would be not too confusing for users. draft Mode in LaTeX omits details but does not change the layout or pagebreaking. -- David Kastrup ___ 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)
Right, I will have a look at that. Thanks! Felipe On 28 January 2011 12:17, percival.music...@gmail.com wrote: Hi Felipe, I'm very sorry about the delay, but at least I'm looking at it now, and I'll take care of badgering people to review it once it's ready. Unfortunately due to the delay, we have a few extra regtests, which fail when this patch is applied. One is tablature-string-tunings.ly -- I think that the old (ly:make-pitch ...) just needs to be updated to use the NATURAL thing that you've used elsewhere. Could you try rebasing this patch from current git master, check for anything that's changed from 4 weeks ago, and then upload a new draft? I promise that we won't ignore the next draft. I'm very sorry about this problem. - Graham http://codereview.appspot.com/3789044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: harmonics and slides (issue3590041)
Hi Graham, I haven't forgotten this patch but unfortunately I don't seem to find time to fix it at the moment. It seems as if two patches got mixed up at least. So I'm probably not responsible for the good stuff! ;-( I can't promise but I'll try to take care of it next weekend. Thanks, patrick Am 22.01.2011 um 21:08 schrieb percival.music...@gmail.com: It looks like there's lots of good work in this patch, but the latest version seems to have some mixed patches. Could you try updating your git tree, then try uploading a new patch? If you need help with git (or with lily-git.tcl), then please don't hesitate to ask. http://codereview.appspot.com/3590041/diff/11001/Documentation/ notation/rhythms.itely File Documentation/notation/rhythms.itely (right): http://codereview.appspot.com/3590041/diff/11001/Documentation/ notation/rhythms.itely#newcode1178 Documentation/notation/rhythms.itely:1178: Metronome marks may also be printed as a range of two numbers: It looks like this patchset contains multiple patches -- I don't see what metronome marks have to do with harmonics. http://codereview.appspot.com/3590041/diff/11001/lily/optimal-page- breaking.cc File lily/optimal-page-breaking.cc (left): http://codereview.appspot.com/3590041/diff/11001/lily/optimal-page- breaking.cc#oldcode62 lily/optimal-page-breaking.cc:62: if (systems_per_page () 0) Is this another accidental change? I'm not certain that this should be part of the harmonic+slides patch. http://codereview.appspot.com/3590041/diff/11001/lily/page-breaking.cc File lily/page-breaking.cc (right): http://codereview.appspot.com/3590041/diff/11001/lily/page- breaking.cc#newcode1141 lily/page-breaking.cc:1141: return space_systems_with_fixed_number_per_page (configuration, first_page_num); Ditto. http://codereview.appspot.com/3590041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 37 - new work
On Sat, Jan 29, 2011 at 09:46:23AM +0100, Marc Hohl wrote: What about something like \draftModeOn / \draftModeOff ? How about four named modes: Screen mode - Fastest but good enough for checking on screen. Useful if lily is being used as a composition tool. Draft mode - Not that beautiful but good enough to perform from. Normal mode (the default) - Allows tweaks etc. Adequate for most uses e.g. music homework. Professional mode - Slowest but adds all know adjustments. For times when presentation is important. It would probably be the case that only for music above a certain complexity would there be a difference between Normal and Professional. I would anticipate that most people would just stick to the default and if that gives them the same result, or better, than the lilypond they know and love that would be OK. /Bernard ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme extension for playback experiments
Hi On Fri, Jan 28, 2011 at 11:14:56PM -0800, Dennis Raddle wrote: I am completely new to LilyPond, but it seems like a good way to get beautiful notation, and, I hope, experiment with playback algorithms that add human touch. What I wonder is whether the Scheme extension language would let me easily examine the notes, dynamics, hairpins, articulations, and ornaments in the file and write that into some custom file format that can be processed by some of my Python scripts that experiment with human touch playback. This link might be of interest to you: http://www.nicta.com.au/people/chubbp/articulate I am a professional programmer with some prior Lisp experience. This would let me use LilyPond's convenient text input to enter the notes, let me see them in beautiful format, and let me export them to my Python scripts. How feasible is this idea? The idea is quite feasible. The easiest way to do this would be to use the concept of a music stream as outlined in Erik Sandberg's master's thesis: http://lilypond.org/web/images/thesis-erik-sandberg.pdf I believe this has all been implemented internally but the current lily does not have a facility for importing/exporting music streams. This is something I am interested in, for other reasons. But once that is done they should be quit easy to work on in Python. /Bernard ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GUB] Github tracker issue
On Fri, Jan 28, 2011 at 11:19:10PM -0800, Patrick McCarty wrote: I meant to post this to -devel a while ago, but I opened a Github tracker issue for GUB. https://github.com/janneke/gub/issues#issue/2 Interesting. How do I get a proper git format-patch version of this? The raw link gives me a plain diff. The download gives me a tarball, which contains a plain diff. Why does it seem like every code review tool out there strips out the commit message and author from git patches? :(I can vaguely excuse codereview, since it was intended for svn... but github?! Please tell me that my old eyes completely missed some get patch button somewhere. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 37 - new work
Bernard Hurley bern...@marcade.biz writes: On Sat, Jan 29, 2011 at 09:46:23AM +0100, Marc Hohl wrote: What about something like \draftModeOn / \draftModeOff ? How about four named modes: Screen mode - Fastest but good enough for checking on screen. Useful if lily is being used as a composition tool. Draft mode - Not that beautiful but good enough to perform from. Normal mode (the default) - Allows tweaks etc. Adequate for most uses e.g. music homework. Professional mode - Slowest but adds all know adjustments. For times when presentation is important. It would probably be the case that only for music above a certain complexity would there be a difference between Normal and Professional. I would anticipate that most people would just stick to the default and if that gives them the same result, or better, than the lilypond they know and love that would be OK. While it is a rather established technique in user interface design to assign blame to the user by giving him the choice between several half-baked solutions, I prefer Lilypond to do good typesetting at a speed commensurate to the problem space (typically linear programming, so quite tractable). Once we get to the frame of mind where exponential complexity seems ok as long as one labels it professional, Lilypond will not be usable for professional work any more. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Tweaks regtest and adds avoid-collisions property (issue4022045)
LGTM. http://codereview.appspot.com/4022045/diff/12001/input/regression/beam-collision.ly File input/regression/beam-collision.ly (right): http://codereview.appspot.com/4022045/diff/12001/input/regression/beam-collision.ly#newcode15 input/regression/beam-collision.ly:15: \clef bass g,,,8[ \clef treble d''8] Could the notes go on their own line? If there's no other problems with this draft, then don't bother -- there's no point being really fussy with .ly syntax in the regtests -- but I expect there's still a few more drafts to come, and it would be easier to read if notes were a little bit more separate from clefs, overrides, and the like. http://codereview.appspot.com/4022045/diff/12001/input/regression/beam-collision.ly#newcode26 input/regression/beam-collision.ly:26: \once \override Voice . Beam #'avoid-collisions = ##f c8[ c c c] } Could the notes go on the next line, leaving the override by itself on the line? Also, could I get a ^turn off collision avoidance so that it's obvious in the image that these collisions are ok? :) http://codereview.appspot.com/4022045/diff/12001/input/regression/beam-collision.ly#newcode54 input/regression/beam-collision.ly:54: s8 f s g s a s b s c s d s e } I see a stem collision for the d and e. I'm not complaining about this, but consider adding a ^no solution possible; stem collides with notehead if this is intentional/acceptable. Basically, imagine that you're a poor bug squad member doing our infrequent full regtest check. You know nothing about programming, and you have 900+ regtests to review, so you're trying to go through each regtest in 30 seconds or so. Anything you can do to make the .png more clear is a good thing. :) http://codereview.appspot.com/4022045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
regression tests for white mensural ligature enhancements (issue3989049)
Reviewers: , Message: and a try at Changes. Description: enhance ligature test with new features Please review this at http://codereview.appspot.com/3989049/ Affected files: M Documentation/changes.tely M input/regression/mensural-ligatures.ly ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: regression tests for white mensural ligature enhancements (issue3989049)
On 2011/01/29 14:07:20, benko.pal wrote: and a try at Changes. LGTM; please send me a git-format originpatch and I'll push it. http://codereview.appspot.com/3989049/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tweaks regtest and adds avoid-collisions property (issue4022045)
Reviewers: Graham Percival, Message: All fixed. New patchset uploaded. http://codereview.appspot.com/4022045/diff/12001/input/regression/beam-collision.ly File input/regression/beam-collision.ly (right): http://codereview.appspot.com/4022045/diff/12001/input/regression/beam-collision.ly#newcode15 input/regression/beam-collision.ly:15: \clef bass g,,,8[ \clef treble d''8] On 2011/01/29 14:00:09, Graham Percival wrote: Could the notes go on their own line? If there's no other problems with this draft, then don't bother -- there's no point being really fussy with .ly syntax in the regtests -- but I expect there's still a few more drafts to come, and it would be easier to read if notes were a little bit more separate from clefs, overrides, and the like. Done. http://codereview.appspot.com/4022045/diff/12001/input/regression/beam-collision.ly#newcode26 input/regression/beam-collision.ly:26: \once \override Voice . Beam #'avoid-collisions = ##f c8[ c c c] } On 2011/01/29 14:00:09, Graham Percival wrote: Could the notes go on the next line, leaving the override by itself on the line? Also, could I get a ^turn off collision avoidance so that it's obvious in the image that these collisions are ok? :) Done. http://codereview.appspot.com/4022045/diff/12001/input/regression/beam-collision.ly#newcode54 input/regression/beam-collision.ly:54: s8 f s g s a s b s c s d s e } On 2011/01/29 14:00:09, Graham Percival wrote: I see a stem collision for the d and e. I'm not complaining about this, but consider adding a ^no solution possible; stem collides with notehead if this is intentional/acceptable. Basically, imagine that you're a poor bug squad member doing our infrequent full regtest check. You know nothing about programming, and you have 900+ regtests to review, so you're trying to go through each regtest in 30 seconds or so. Anything you can do to make the .png more clear is a good thing. :) Done. Description: Tweaks regtest and adds avoid-collisions property Merge branch 'master' of git://git.sv.gnu.org/lilypond into 37final Triggers second quant pass for collisions Bad Revert Bad This reverts commit fac518ab6e4ea9fd591c849afb56e247d53c9bf3. Implements a more robust solution to issue 37 Intermediary Intermediary Intermediary Intermediary Intermediary Finally Whitespace fixes Please review this at http://codereview.appspot.com/4022045/ Affected files: A input/regression/beam-collision.ly A lily/beam-collision-engraver.cc M lily/beam-quanting.cc M lily/beam.cc M lily/include/beam.hh M ly/engraver-init.ly M scm/define-grob-properties.scm M scm/define-grobs.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: regression tests for white mensural ligature enhancements (issue3989049)
LGTM; please send me a git-format origin patch and I'll push it. thanks! p 0001-regtest-and-changes-for-mensural-ligature-improvemen.patch Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tweaks regtest and adds avoid-collisions property (issue4022045)
http://codereview.appspot.com/4022045/diff/14001/input/regression/beam-collision.ly File input/regression/beam-collision.ly (right): http://codereview.appspot.com/4022045/diff/14001/input/regression/beam-collision.ly#newcode17 input/regression/beam-collision.ly:17: g,,,8[ \clef treble d''8] newline before \clef, newline before d'' I'm not saying to do this right now -- wait until somebody points out some code problems/improvements, then do this at the same time. :) http://codereview.appspot.com/4022045/diff/14001/input/regression/beam-collision.ly#newcode22 input/regression/beam-collision.ly:22: \key bes \major ees ] | newline before ees and could we get a 8 as well? I've lost track of the durations by this point. http://codereview.appspot.com/4022045/diff/14001/input/regression/beam-collision.ly#newcode24 input/regression/beam-collision.ly:24: \break indent two spaces. http://codereview.appspot.com/4022045/diff/14001/input/regression/beam-collision.ly#newcode40 input/regression/beam-collision.ly:40: \stemUp e'8[ e e e] newline before e'8 http://codereview.appspot.com/4022045/diff/14001/input/regression/beam-collision.ly#newcode41 input/regression/beam-collision.ly:41: \set fontSize = #-4 c8[ c c c] newline before c8[ http://codereview.appspot.com/4022045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 37 - new work
On Fri, Jan 28, 2011 at 11:55 AM, m...@apollinemike.com
m...@apollinemike.com wrote:
Despite the joke, this is a semi-serious suggestion that I've been
hoping that somebody might be interested in for years. There's a
bunch of options that we can enable or disable to change the
amount of processing power; it would be really nice if one (or
more) people seriously looked into this, and provided an easy way
to change between the optimization levels.
I completely agree. I think that the beam collision engraver (if it makes
it into lilypond) is the prime example of
something that could be included or left out with
optimization flags. There can even be multiple collision
engravers that perform the same task but provide different
levels of optimization.
In the case of the beam scoring specifically, I disagree: there are
many ways to search more cleverly in the problem space.
For beams specifically, how about this one:
choose large region size
calculate cheapest of the scoring functions for all configurations
put configurations in a min-heap
while (true) {
take minimum score configuration from heap
if conf has passed all scoring functions
break // found optimum
add another scoring function to configuration // *
insert result in heap
}
for the common cases, this will skip computations for many of the more
extreme cases. At //* , there is still some option of further
optimization by doing an intelligent choice between what to run next.
The same approach should work well for slurs as well.
If I find time one of these days (may be next week), I'll try to implement this.
--
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
Re: Issue 37 - new work
On Jan 29, 2011, at 10:10 AM, Han-Wen Nienhuys wrote:
On Fri, Jan 28, 2011 at 11:55 AM, m...@apollinemike.com
m...@apollinemike.com wrote:
Despite the joke, this is a semi-serious suggestion that I've been
hoping that somebody might be interested in for years. There's a
bunch of options that we can enable or disable to change the
amount of processing power; it would be really nice if one (or
more) people seriously looked into this, and provided an easy way
to change between the optimization levels.
I completely agree. I think that the beam collision engraver (if it makes
it into lilypond) is the prime example of
something that could be included or left out with
optimization flags. There can even be multiple collision
engravers that perform the same task but provide different
levels of optimization.
In the case of the beam scoring specifically, I disagree: there are
many ways to search more cleverly in the problem space.
For beams specifically, how about this one:
choose large region size
calculate cheapest of the scoring functions for all configurations
put configurations in a min-heap
while (true) {
take minimum score configuration from heap
if conf has passed all scoring functions
break // found optimum
add another scoring function to configuration // *
insert result in heap
}
for the common cases, this will skip computations for many of the more
extreme cases. At //* , there is still some option of further
optimization by doing an intelligent choice between what to run next.
The same approach should work well for slurs as well.
If I find time one of these days (may be next week), I'll try to implement
this.
Hey Hanwen,
What you describe above is close-ish to what I wound up putting in my newest
patch, which only has one pass thru the quanting function. It does all the
quant scoring, then does one last pass to check for collisions. This is done
through allowing negative pressure, or an amount of leeway that a beam has to
move in a direction before it will collide with something.
http://codereview.appspot.com/4022045/
Cheers,
MS___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 37 - new work
Am 29.01.2011 09:50, schrieb David Kastrup: Marc Hohlm...@hohlart.de writes: If this is done similar to LaTeX packages where you can enable the option draft to speed up compiling, and if everything looks ok, you remove the draft and that's it, then this would be not too confusing for users. draft Mode in LaTeX omits details but does not change the layout or pagebreaking. The comparison between LaTeX and LilyPond was not meant to be 1:1, of course. The point here was that IMHO most LaTeX users understand what draft means, so it would not be too confusing to add certain levels of processing stages. On the other hand, I agree with you that LilyPond should simply do the best job without the need to fuzz around with optimization stages and whatnot. Human engravers didn't have a draft mode either ;-) Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 37 - new work
On Jan 29, 2011, at 10:50 AM, Marc Hohl wrote: Am 29.01.2011 09:50, schrieb David Kastrup: Marc Hohlm...@hohlart.de writes: If this is done similar to LaTeX packages where you can enable the option draft to speed up compiling, and if everything looks ok, you remove the draft and that's it, then this would be not too confusing for users. draft Mode in LaTeX omits details but does not change the layout or pagebreaking. The comparison between LaTeX and LilyPond was not meant to be 1:1, of course. The point here was that IMHO most LaTeX users understand what draft means, so it would not be too confusing to add certain levels of processing stages. On the other hand, I agree with you that LilyPond should simply do the best job without the need to fuzz around with optimization stages and whatnot. Human engravers didn't have a draft mode either ;-) True, but human engravers did not have the benefit of sending composers drafts every time a measure was updated. I think that for programs like SCORE, the logic of best job makes perfect sense because it is best used for typesetting finished works. But, given that many people make drafts in Lilypond, I think that a draft mode would save a lot of time in the early stages of creating a work. However, I think that lilypond's default quality should be the highest possible, with people opting out of this quality for faster calculated and thus iffy-er looking scores. On this note, I think that PaperColumn #'keep-inside-line = ##t and NonMusicalPaperColumn #'keep-inside-line = ##t should be the default options in Lilypond, as I cannot imagine anyone wanting markups to spill outside of the line width. In a way, setting these as ##f in scm/define-grobs.scm is a form of normal optimization that leads to sub-par results. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GUB] Github tracker issue
On 1/29/11 6:20 AM, Graham Percival gra...@percival-music.ca wrote: On Fri, Jan 28, 2011 at 11:19:10PM -0800, Patrick McCarty wrote: I meant to post this to -devel a while ago, but I opened a Github tracker issue for GUB. https://github.com/janneke/gub/issues#issue/2 Interesting. How do I get a proper git format-patch version of this? The raw link gives me a plain diff. The download gives me a tarball, which contains a plain diff. Why does it seem like every code review tool out there strips out the commit message and author from git patches? :(I can vaguely excuse codereview, since it was intended for svn... but github?! Please tell me that my old eyes completely missed some get patch button somewhere. It appears to me that the desired work flow for this is for the submitter (Patrick in this case) to make a pull request, at which time the applier can do the pull and the patch will have the original author stuff. Here's an email thread that addresses this issue: http://support.github.com/discussions/pull-requests/91-pull-requests-dont-k eep-commit-history Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 37 - new work
On Sat, Jan 29, 2011 at 1:37 PM, m...@apollinemike.com m...@apollinemike.com wrote: Hey Hanwen, What you describe above is close-ish to what I wound up putting in my newest I don't think so, since the main scoring loops still loop through all combinations in no particular order. I looked closer at your example; the proof-of-concept code I showed you does not consider stems as collision objects, and hence configs where beams overlay stems of other voices are not considered problems. Let me try to refine my patch to include stems as well. patch, which only has one pass thru the quanting function. It does all the quant scoring, then does one last pass to check for collisions. This is done through allowing negative pressure, or an amount of leeway that a beam has to move in a direction before it will collide with something. http://codereview.appspot.com/4022045/ Cheers, MS -- 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
Re: [GUB] Github tracker issue
On Sat, Jan 29, 2011 at 8:45 AM, Carl Sorensen c_soren...@byu.edu wrote: On 1/29/11 6:20 AM, Graham Percival gra...@percival-music.ca wrote: On Fri, Jan 28, 2011 at 11:19:10PM -0800, Patrick McCarty wrote: I meant to post this to -devel a while ago, but I opened a Github tracker issue for GUB. https://github.com/janneke/gub/issues#issue/2 Interesting. How do I get a proper git format-patch version of this? The raw link gives me a plain diff. The download gives me a tarball, which contains a plain diff. Why does it seem like every code review tool out there strips out the commit message and author from git patches? :( I can vaguely excuse codereview, since it was intended for svn... but github?! Please tell me that my old eyes completely missed some get patch button somewhere. It appears to me that the desired work flow for this is for the submitter (Patrick in this case) to make a pull request, at which time the applier can do the pull and the patch will have the original author stuff. Yes, this is the typical work flow for Github. Once we figure out a proper patch to merge, we have the option of submitting a pull request. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 37 - new work
On Jan 29, 2011, at 1:21 PM, Han-Wen Nienhuys wrote: On Sat, Jan 29, 2011 at 1:37 PM, m...@apollinemike.com m...@apollinemike.com wrote: Hey Hanwen, What you describe above is close-ish to what I wound up putting in my newest I don't think so, since the main scoring loops still loop through all combinations in no particular order. Ah, OK, now I see what you mean. Yes, you're absolutely right - if it is possible to slim down the candidates, then the loop speeds up. In other places in the code, there is a comparison via reasonable_score, but I wasn't sure if acting only on reasonable scores would make them so unreasonable that what was once unreasonable now becomes reasonable and is erroneously chosen. I'll check that out later today. I looked closer at your example; the proof-of-concept code I showed you does not consider stems as collision objects, and hence configs where beams overlay stems of other voices are not considered problems. Let me try to refine my patch to include stems as well. OK! In doing so, make sure to address stem direction: a big headache I went through in my initial draft was figuring out how stem direction influenced the calculation. In my current code, NoteHeads (and accidentals) that belong to a beam push the beam in the direction of said NoteHeads' stem, whereas NoteHeads that are not part of the beam push the beam in the opposite direction of said NoteHeads' stem. Cheers, MS patch, which only has one pass thru the quanting function. It does all the quant scoring, then does one last pass to check for collisions. This is done through allowing negative pressure, or an amount of leeway that a beam has to move in a direction before it will collide with something. http://codereview.appspot.com/4022045/ Cheers, MS -- 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: Multimeasure rest print function
Mike Solomon MikeSol at ufl.edu writes: It seems that the variable `measures' is unused in this function - can this be deleted? Who are you asking? git blame (git credit would have been a nicer name) shows these lines have not been touched in several years, so it is not likely to be in anyone's memory. It really does look like a left-over piece of code, since the complete version appears in symbol_stencil(). The names of functions called imply they have no side-effects, but I'd still do regression test. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 1120 in a way to avoid issues 1472, 1474 (issue4095041)
On 2011/01/26 18:18:21, Graham Percival wrote: Neil has identified a potential downside to this patch. That was a restoration of 2.12.3 behavior, which I had mentioned in the original email thread but didn't explicitly handle until now. Status of this patch is 1)revert ee0488, which was a global change in effective extra-spacing-height, /except/ keep from ee0488 the addition of beat-slash on the print-callbacks list 2)reviewed the entire list of Layout Objects to specify extra-spacing-height to restore any possible positive effect of ee0488 3)regression test and see only expected changes http://codereview.appspot.com/4095041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 1120 in a way to avoid issues 1472, 1474 (issue4095041)
This patch solves Neil's problem with clef spacing. LGTM. Carl http://codereview.appspot.com/4095041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
fine-tuning new flags - feedback needed
Hi, After some discussion in flags, beams and stem length in forced directions - output improvement thread, i've created new flags for shorter-stemmed notes and new rules for shortening stems. Please look at pdfs linked below and tell me what you think. Changes: - stem length transition between regular stems and shortened stems is now smooth (it's especially visible with unflagged notes), - the difference in length between regular stems and shortened stems depends on the duration of notes (that's because notes with different amount of flags need different treatment), - regular stems of 32nd and 128th notes are shorter. I felt they were too long, especially compared to the beamed notes - for example the stem of the unbeamed e 32nd reaches higher than the beamed f's following it, - 64th and 128th basic flag shape now matches stem length better (i think). I hope that .zip archives are appropriate here... Each archive is about 400 KB. output from 2.13.45: http://www.sendspace.com/file/6cwf2q proposed new output: http://www.sendspace.com/file/52bbz6 If you don't like the last two changes (shorter regular stems and modified basic flags), try this: http://www.sendspace.com/file/gglzoh (shortened stems of 8th and 16th notes are also a little bit longer here than in previous one) I attach .ly files used for testing. You may send me more files if you want to see how they would look like. I will send a patch with the code changes when i resolve some problems i've encountered; as for now i'd like to know your opinions about the output itself. I see that there is a problem with dots and single flags... I'd gladly help with solving this one, i have some idea what the solution may look like. cheers, Janek PS you may forward this to -user if you find this appropriate. 01-HomeSweetHome.ly Description: Binary data 02-BlueBells.ly Description: Binary data 03-TheLastRoseOfSummer.ly Description: Binary data Abschied.ly Description: Binary data flag testing.ly Description: Binary data Lyngham.ly Description: Binary data Uxbridge.ly Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fine-tuning new flags - feedback needed
On 1/29/11 4:14 PM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: Hi, After some discussion in flags, beams and stem length in forced directions - output improvement thread, i've created new flags for shorter-stemmed notes and new rules for shortening stems. Please look at pdfs linked below and tell me what you think. Very interesting work, indeed. Thanks! Changes: - stem length transition between regular stems and shortened stems is now smooth (it's especially visible with unflagged notes), - the difference in length between regular stems and shortened stems depends on the duration of notes (that's because notes with different amount of flags need different treatment), - regular stems of 32nd and 128th notes are shorter. I felt they were too long, especially compared to the beamed notes - for example the stem of the unbeamed e 32nd reaches higher than the beamed f's following it, - 64th and 128th basic flag shape now matches stem length better (i think). I hope that .zip archives are appropriate here... Each archive is about 400 KB. output from 2.13.45: http://www.sendspace.com/file/6cwf2q proposed new output: http://www.sendspace.com/file/52bbz6 If you don't like the last two changes (shorter regular stems and modified basic flags), try this: http://www.sendspace.com/file/gglzoh (shortened stems of 8th and 16th notes are also a little bit longer here than in previous one) I attach .ly files used for testing. You may send me more files if you want to see how they would look like. I will send a patch with the code changes when i resolve some problems i've encountered; as for now i'd like to know your opinions about the output itself. I see that there is a problem with dots and single flags... I'd gladly help with solving this one, i have some idea what the solution may look like. I prefer the compromise flags to the new flags. I think that the new flags are a little bit too short. I prefer the old stem-down single flags to the new. The shorter flags seem to me to be too squat and blocky. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fine-tuning new flags - feedback needed
Nice job! And I have to second Carl's comment: The `compromise' stuff is the best one $(Q#|(B and perhaps you can make a compromise between the `orig' stuff and `compromise' w.r.t. the shape of the down-flags... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
