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 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: 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
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: 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: 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: Issue 37 - new work
On Thu, Jan 27, 2011 at 12:47 AM, Mike Solomon mike...@ufl.edu wrote:
Hey all,
I have a new Issue 37 fix.
The attached patch set implements a 2-pass approach through the quanting that
is potentially a huge time drain in scores with lots of collisions, but
likely not a time drain for most scores. The problem is that the quanting
algorithm, by fixing a region size, sometimes places all possible solutions
in a range in which a collision will happen. The algorithm will also
sometimes create collisions where
The knee code has a similar problem. See Beam::shift_to_valid on how
it was handled there.
I'm not a fan of the 2 pass approach. With the 2-pass approach, you'd
always forego any beams with more extreme slopes; also, this patch
looks hackish,
+ Direction dir = to_dir (me-get_property (collision-dir));
+
+ if (dir)
+ {
+Real max_demerit = 0.0;
+for (vsize i = qscores.size (); i--;)
+ max_demerit = max (max_demerit, qscores[i].demerits);
+
+for (vsize i = qscores.size (); i--;)
+ {
+Real d = (yl * dir qscores[i].yl * dir) || (yr * dir
qscores[i].yr * dir) ? max_demerit : 0.0;
+qscores[i].demerits += d;
+ }
+ }
Why not increase the region-size for beams that we know are
problematic, similar to what we do for knees? In a typical score most
beams will not have collisions, so performance would largely be
unaffected.
Have you tried rebasing your work on the proof-of-concept code that I sent?
there were none before, making it impossible to check for them beforehand.
I dont understand what you mean here.
Thus, we need to let that collision happen, then move the beam such that it
is around the point of the collision, and then rerun the quanting algorithm.
If you only apply the first patch, you'll still get something that works, but
w/ no good quanting.
I'd like to hear your opinions - do you see anyway to trim down the
computations?
I've been using the attached .ly file to monitor the results. The only odd
thing is the small beam for the C that is being squashed by the G, but I
can't figure out a better solution with proper quants. The alternative here
would be just turning off the collision avoiding, but I haven't figured out
how to do that in that particular scenario. Otherwise, all of Han-Wen's
concerns are addressed. And, as before, the truly heinous collisions are
unavoidable because there is no way to anticipate desired output.
I still need to do a make check.
--
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
inline: hanwen6.png
I cooked up this musical example that shows both responses to upward and
downward pressure to give you an idea of where I'm coming from.
Is there a way to get this type of collision avoidance w/o a 2nd quanting pass?
Cheers,
~Mike
On Jan 28, 2011, at 7:45 AM, Han-Wen Nienhuys wrote:
On Thu, Jan 27, 2011 at 12:47 AM, Mike Solomon mike...@ufl.edu wrote:
Hey all,
I have a new Issue 37 fix.
The attached patch set implements a 2-pass approach through the quanting
that is potentially a huge time drain in scores with lots of collisions, but
likely not a time drain for most scores. The problem is that the quanting
algorithm, by fixing a region size, sometimes places all possible solutions
in a range in which a collision will happen. The algorithm will also
sometimes create collisions where
The knee code has a similar problem. See Beam::shift_to_valid on how
it was handled there.
I'm not a fan of the 2 pass approach. With the 2-pass approach, you'd
always forego any beams with more extreme slopes; also, this patch
looks hackish,
+ Direction dir = to_dir (me-get_property (collision-dir));
+
+ if (dir)
+ {
+Real max_demerit = 0.0;
+for (vsize i = qscores.size (); i--;)
+ max_demerit = max (max_demerit, qscores[i].demerits);
+
+for (vsize i = qscores.size (); i--;)
+ {
+Real d = (yl * dir qscores[i].yl * dir) || (yr * dir
qscores[i].yr * dir) ? max_demerit : 0.0;
+qscores[i].demerits += d;
+ }
+ }
Why not increase the region-size for beams that we know are
problematic, similar to what we do for knees? In a typical score most
beams will not have collisions, so performance would largely be
unaffected.
Have you tried rebasing your work on the proof-of-concept code that I sent?
there were none before, making it impossible to check for them beforehand.
I dont understand what you mean here.
Thus, we need to let that collision happen, then move the beam such that it
is around the point of the collision, and then rerun the quanting
algorithm. If you only apply the first patch, you'll still get something
that works, but w/ no good quanting.
I'd like to hear your opinions - do you see anyway to trim down the
computations?
I've been using the attached .ly file to monitor the results. The only odd
thing is the small beam for the C that is being squashed by the G, but I
can't figure out a better solution with proper quants. The alternative here
would be just turning off the collision avoiding, but I haven't figured out
how to do that in that particular scenario. Otherwise, all of Han-Wen's
concerns are addressed. And, as before, the truly heinous collisions are
unavoidable because there is no way to anticipate desired output.
I still need to do a make check.
--
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
Mike Solomon mike...@ufl.edu writes: I cooked up this musical example that shows both responses to upward and downward pressure to give you an idea of where I'm coming from. Is there a way to get this type of collision avoidance w/o a 2nd quanting pass? Actually, it would appear a third pass would be nice in order to put sympathetic pressure on the lowest beam, decreasing the discrepancy of its stems with the adjacent (highly compressed) stem set. -- David Kastrup ___ 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 02:38:56PM +0100, David Kastrup wrote: Mike Solomon mike...@ufl.edu writes: I cooked up this musical example that shows both responses to upward and downward pressure to give you an idea of where I'm coming from. Is there a way to get this type of collision avoidance w/o a 2nd quanting pass? Actually, it would appear a third pass would be nice in order to put sympathetic pressure on the lowest beam, decreasing the discrepancy of its stems with the adjacent (highly compressed) stem set. Hmm... 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 ;) 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. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 37 - new work
Graham Percival gra...@percival-music.ca writes: On Fri, Jan 28, 2011 at 02:38:56PM +0100, David Kastrup wrote: Mike Solomon mike...@ufl.edu writes: I cooked up this musical example that shows both responses to upward and downward pressure to give you an idea of where I'm coming from. Is there a way to get this type of collision avoidance w/o a 2nd quanting pass? Actually, it would appear a third pass would be nice in order to put sympathetic pressure on the lowest beam, decreasing the discrepancy of its stems with the adjacent (highly compressed) stem set. Hmm... 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 ;) 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 think it makes more sense to focus on optimal typesetting via the usual efficient shortest graph traversal algorithm. If that's not feasible due to code complexity, it should be made so by proper refactoring and providing a suitable framework making it possible to express the relevant parameters and decisions locally and separately even though their influence is global. The alternative, doing multiple passes consisting of only locally optimal behavior, sounds good as a practical approach not touching working areas. However, going there leads to uncontrollably exploding execution times with diminuishing returns. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 37 - new work
On Jan 28, 2011, at 8:43 AM, Graham Percival wrote: On Fri, Jan 28, 2011 at 02:38:56PM +0100, David Kastrup wrote: Mike Solomon mike...@ufl.edu writes: I cooked up this musical example that shows both responses to upward and downward pressure to give you an idea of where I'm coming from. Is there a way to get this type of collision avoidance w/o a 2nd quanting pass? Actually, it would appear a third pass would be nice in order to put sympathetic pressure on the lowest beam, decreasing the discrepancy of its stems with the adjacent (highly compressed) stem set. Hmm... 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 ;) 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. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 37 - new work
pressed send too soon. On Fri, Jan 28, 2011 at 4:14 PM, Han-Wen Nienhuys hanw...@gmail.com wrote: On Fri, Jan 28, 2011 at 11:22 AM, Mike Solomon mike...@ufl.edu wrote: I cooked up this musical example that shows both responses to upward and downward pressure to give you an idea of where I'm coming from. Is there a way to get this type of collision avoidance w/o a 2nd quanting pass? You are now dramatically extending the problem scope: you are looking for a configuration that optimizes configurations of all beams at the same time. For example, it is conceivable that individually, the beam for A below staff would be better served when the beam goes up the line of D''. However, that would leave no room for the A' beam, since it would be on top of the A'' beam. A solution that would work for this should optimize all of the beams at the same time. It might be feasible to code, but probably only if you restrict all the beams to be horizontal. The tie formatting is similar: it also tries to find a configuration where *all* ties between a chord are more or less OK. -- 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 Fri, Jan 28, 2011 at 11:22 AM, Mike Solomon mike...@ufl.edu wrote:
I cooked up this musical example that shows both responses to upward and
downward pressure to give you an idea of where I'm coming from.
Is there a way to get this type of collision avoidance w/o a 2nd quanting
pass?
You are now dramatically extending the problem scope: you are looking
for a configuration that optimizes configurations of all beams at the
same time. For example, it is conceivable that individually, the beam
for A below staff would be better served when the beam goes up the
line of D''. However, that would leave no room for the A' beam, since
it would be on top of the A'' beam.
A solution that would work for this should optimize all of the beams
at the same time. It might be feasible to code, but probably only if
you restrict all the beams to be
You could try thinking of a A completely different option would be to
restrict these beams to be
Cheers,
~Mike
On Jan 28, 2011, at 7:45 AM, Han-Wen Nienhuys wrote:
On Thu, Jan 27, 2011 at 12:47 AM, Mike Solomon mike...@ufl.edu wrote:
Hey all,
I have a new Issue 37 fix.
The attached patch set implements a 2-pass approach through the quanting
that is potentially a huge time drain in scores with lots of collisions,
but likely not a time drain for most scores. The problem is that the
quanting algorithm, by fixing a region size, sometimes places all possible
solutions in a range in which a collision will happen. The algorithm will
also sometimes create collisions where
The knee code has a similar problem. See Beam::shift_to_valid on how
it was handled there.
I'm not a fan of the 2 pass approach. With the 2-pass approach, you'd
always forego any beams with more extreme slopes; also, this patch
looks hackish,
+ Direction dir = to_dir (me-get_property (collision-dir));
+
+ if (dir)
+ {
+ Real max_demerit = 0.0;
+ for (vsize i = qscores.size (); i--;)
+ max_demerit = max (max_demerit, qscores[i].demerits);
+
+ for (vsize i = qscores.size (); i--;)
+ {
+ Real d = (yl * dir qscores[i].yl * dir) || (yr * dir
qscores[i].yr * dir) ? max_demerit : 0.0;
+ qscores[i].demerits += d;
+ }
+ }
Why not increase the region-size for beams that we know are
problematic, similar to what we do for knees? In a typical score most
beams will not have collisions, so performance would largely be
unaffected.
Have you tried rebasing your work on the proof-of-concept code that I sent?
there were none before, making it impossible to check for them beforehand.
I dont understand what you mean here.
Thus, we need to let that collision happen, then move the beam such that
it is around the point of the collision, and then rerun the quanting
algorithm. If you only apply the first patch, you'll still get something
that works, but w/ no good quanting.
I'd like to hear your opinions - do you see anyway to trim down the
computations?
I've been using the attached .ly file to monitor the results. The only odd
thing is the small beam for the C that is being squashed by the G, but I
can't figure out a better solution with proper quants. The alternative
here would be just turning off the collision avoiding, but I haven't
figured out how to do that in that particular scenario. Otherwise, all of
Han-Wen's concerns are addressed. And, as before, the truly heinous
collisions are unavoidable because there is no way to anticipate desired
output.
I still need to do a make check.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
--
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 Fri, Jan 28, 2011 at 11:43 AM, Graham Percival gra...@percival-music.ca wrote: I cooked up this musical example that shows both responses to upward and downward pressure to give you an idea of where I'm coming from. Is there a way to get this type of collision avoidance w/o a 2nd quanting pass? Actually, it would appear a third pass would be nice in order to put sympathetic pressure on the lowest beam, decreasing the discrepancy of its stems with the adjacent (highly compressed) stem set. Hmm... 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 ;) 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 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. -- 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 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 of the page breaking / beam calculation / text column collision handling code. So let's just give them a bad quality / good quality command! (admittedly, in the above example I implicitly divided the quality into 9 levels, not 1) SPEED Composer (or typesetter) working by himself, just entering pitches and rhythms: use 0 quality. Who cares what it looks like, as long as he can see that the notes are in the right octave, it fits into bars, etc. Let slurs go through noteheads, draw accidentals on every note, use a monospace/courier f instead of a dynamic font... ok, maybe that's an exaggeration, but the point remains: at some point in people's work on a composition, they would *gladly* accept absolute crap typography in exchange for dividing the processing time by 2. I honestly think that if somebody seriously looked into this, we could divide the processing time (for crap output) by 10 for most scores. QUALITY Composer producing final (or near-final) version: use highest quality. Resolve beam collisions, try to have page turns at rests, keep text, etc etc. These two usage cases are very different; there is just no way to do the right thing. Cheers, - Graham ___ 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 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. -- 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 Fri, Jan 28, 2011 at 6:01 PM, Graham Percival gra...@percival-music.ca wrote: On Fri, Jan 28, 2011 at 05:42:56PM -0200, Han-Wen Nienhuys wrote: On Fri, Jan 28, 2011 at 4:43 PM, Graham Percival gra...@percival-music.ca wrote: 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. gperciva@futoi:~$ gunzip --help Usage: gzip [OPTION]... [FILE]... Compress or uncompress FILEs (by default, compress FILES in-place). [...] -V, --version display version number -1, --fast compress faster -9, --best compress better oh dear. I hope that nobody uses these terrible command-line switches to gzip! At least bzip2 doesn't make this same mistake... oops, no wait, it also has -1 .. -9 options! This is terribly disheartening. I'd better go off and download some pirated tv shows... oh no! Most popular video encoding software has a quality setting, too! ok, I guess I'll go drown myself in C programming. Surely gcc wouldn't be stupid enough to provide multiple optimization levels... oh noes! -O -O0 -O1 -O2 -O3 -Os ! I see nothing wrong with providing easy-to-use optimization levels, as long as it's possible to dig down and find out what they all do. I've happily used -O2 for years without once looking at it. A few months ago, I tried doing some heavy optimizations, so I went and looked at the difference between -O2 and -O3 and what --funsafe-math-optimizations did (I was especially curious because the latter produced incorrect answers for my program!). But I don't see anything dangerous about having -Ox switches in general. Quick: in what case should you use gcc option -ftree-vrp ? The -O2 option to GCC demonstrates what I mean. Nobody knows what the levels do, so people settle on either -O2 which is the maximum that is not a tradeoff, or no optimization at all. In the case of lilypond, how would someone know which level to choose, if it werent either maximum or minimum level? -- 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 Fri, Jan 28, 2011 at 07:26:14PM -0200, Han-Wen Nienhuys wrote: On Fri, Jan 28, 2011 at 6:01 PM, Graham Percival gra...@percival-music.ca wrote: I see nothing wrong with providing easy-to-use optimization levels, as long as it's possible to dig down and find out what they all do. I've happily used -O2 for years without once looking Quick: in what case should you use gcc option -ftree-vrp ? I cannot imagine any case, other than some madman bursting into my bedroom and threatening me with a chainsaw, in which I would need to answer this question quickly. If I had reason to suspect that -ftree-vrp might be useful, I'd stick it into google and see what I find. The -O2 option to GCC demonstrates what I mean. Nobody knows what the levels do, so people settle on either -O2 which is the maximum that is not a tradeoff, or no optimization at all. *shrug* I have no objection to an all or none approach to this optimization, if an investigation of the options suggests that there's no useful level between all and none. In the case of lilypond, how would someone know which level to choose, if it werent either maximum or minimum level? By reading the documentation. Trust me, I know how to work on this part. :) One cannot learn how to use lilypond without reading the docs, so demanding that people RTFM for nonstandard usage isn't a terrible burden. Off the top of my head, I can imagine at least 3 useful levels of optimization. The default output is the highest quality, of course. 1. absolute crap output. All \override and \set and \tweaks are ignored, all beams are horizontal, strict grid-like notehead spacing, fixed distance between staves, allow collisions between noteheads, allow slurs to go through noteheads, etc etc. Whatever _can_ be turned off, _is_ turned off. To make it absolutely clear that this is totally disgusting output, we automatically make the background color of the PDF or PNG light pink, or dull brown, or puke yellow/green. 2. decent quality. Something like the 2.12.3 output, or current output with #(minimal-breaking) or whatever the lowest-processing version of vertical spacing is. 3. highest quality. Use O(n^2) operations for beam collisions, or multiple passes, or whatever. * not that we deliberately use silly alogrithms; if we can get good beam collision avoidance without multiple passes, then of course we'd hold out for such a patch. Cheer, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 37 - new work
On Jan 28, 2011, at 6:12 PM, Mike Solomon wrote: On Jan 28, 2011, at 1:15 PM, Han-Wen Nienhuys wrote: pressed send too soon. On Fri, Jan 28, 2011 at 4:14 PM, Han-Wen Nienhuys hanw...@gmail.com wrote: On Fri, Jan 28, 2011 at 11:22 AM, Mike Solomon mike...@ufl.edu wrote: I cooked up this musical example that shows both responses to upward and downward pressure to give you an idea of where I'm coming from. Is there a way to get this type of collision avoidance w/o a 2nd quanting pass? You are now dramatically extending the problem scope: you are looking for a configuration that optimizes configurations of all beams at the same time. For example, it is conceivable that individually, the beam for A below staff would be better served when the beam goes up the line of D''. However, that would leave no room for the A' beam, since it would be on top of the A'' beam. A solution that would work for this should optimize all of the beams at the same time. It might be feasible to code, but probably only if you restrict all the beams to be horizontal. The tie formatting is similar: it also tries to find a configuration where *all* ties between a chord are more or less OK. I've made an updated version where the collision penalty controls the extent to which the beam approaches the original quants. In the png below, the penalty is set normal first, then insanely high. Normal builds the regtest to look as pretty as possible but fails in tight situations like the first example in the png. If you set it too high, it leads to the non-conventional quanting in the second example. That said, I think that most users would opt for ugly quanting over smooshed beams and thus go w/ the second example. Interestingly, if you comment out the slope damping function, it leads to even better results for the inner two beams, leading me to believe that there should be a switch that allows one to bypass this function. Perhaps that should be a separate patch, though. Thoughts? http://codereview.appspot.com/4022045 Clean make check. http://codereview.appspot.com/4022045 Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 37 - new work
Hey all, I have a new Issue 37 fix. The attached patch set implements a 2-pass approach through the quanting that is potentially a huge time drain in scores with lots of collisions, but likely not a time drain for most scores. The problem is that the quanting algorithm, by fixing a region size, sometimes places all possible solutions in a range in which a collision will happen. The algorithm will also sometimes create collisions where there were none before, making it impossible to check for them beforehand. Thus, we need to let that collision happen, then move the beam such that it is around the point of the collision, and then rerun the quanting algorithm. If you only apply the first patch, you'll still get something that works, but w/ no good quanting. I'd like to hear your opinions - do you see anyway to trim down the computations? I've been using the attached .ly file to monitor the results. The only odd thing is the small beam for the C that is being squashed by the G, but I can't figure out a better solution with proper quants. The alternative here would be just turning off the collision avoiding, but I haven't figured out how to do that in that particular scenario. Otherwise, all of Han-Wen's concerns are addressed. And, as before, the truly heinous collisions are unavoidable because there is no way to anticipate desired output. I still need to do a make check. Cheers, Mike 0002-Triggers-second-quant-pass-for-collisions.patch Description: Binary data 0001-Implements-a-more-robust-solution-to-issue-37.patch Description: Binary data full-beam-collision.ly Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
