Re: [frogs] Re: tablature: ties and harmonics (issue1669041)
Carl Sorensen schrieb: [...] http://codereview.appspot.com/1669041/diff/26001/27004#newcode130 scm/define-grob-properties.scm:130: (bracket-width ,number? Width of the harmonic angle bracket.) Why do we need bracket-width? Why can't we just use the pre-existing width property? Hm, Neil proposed to use a more descriptive name for this property, IIUC. Done. Well, if we want to have this be part of the parenthesis-interface, then we may want to go ahead with bracket-width. Ok, done. [...] If instead of making the whiteout and the stencil different stencils, we combined them, then parenthesize-stencil would work great. But this might not be possible if we need to have the stencil and the whiteout on separate layers. As an alternative, parenthesize-stencil could be modified to take white-padding as an argument. There's nothing that says we can't modify scm/stencil.scm so that it works better for tablature. It's much better, IMO, to have one general-purpose piece of code than to have two separate special-purpose code chunks. So I tried to extend the parenthesize-stencil function in scm/stencil.scm. It compiles without error, but the regression file is cluttered up. I feel that this is not the right approach, either. I still don't understand why I have to shift the TabNoteHead #'layer at all. As far as I see it, HarmonicParenthesesItem #'stencils is a list of stencils, containing the left and the right angle bracket, which are placed either side of the TabNoteHead #'stencil. So the order in which the stancils are placed should not change anything at all, but if the TabNoteHead #'stencil is set *before* the HarmonicParenthesesItem #'stencils, it seems that some whitespace occurs between the angle brackets, overriding the already placed TabNoteHead. If on the other hand the whiteout would not appear, we could just use the parenthesize-tab-note-head function defined in scm/tablature.scm. This function could detect whether we have a harmonic and in this case would place the parentheses just further apart. Furthermore, I have a bad feeling to misuse your time reviewing my patch for error seeking issues, but I am stuck here. I like the general idea of not defining the same functionality over and over again, but on the other hand, the parenthesize-stencil function in scm/stencil.scm does not seem to be used anywhere else ... Thanks in advance, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Vertical spacing regression !?
On 06/30/2010 01:04 AM, David Kastrup wrote:
until after line-breaking. Also, the vertical collision avoidance means
that in { c1^long long markup c1^long long markup }, we cannot
calculate the height of the second bar without considering the first bar
too (and the answer will change if they are on different lines).
Maybe I am dull, but we need the line heights (or skyline) for a given
line breakpoint sequence, and a given line breakpoint sequence has a
given skyline for each line.
Correct. And there is O(2^N) breakpoint sequences for N possible
breakpoint places (roughly, for N bars); so we need O(2^N)
heights/skylines and page breakings. The dynamic programming algorithm
deals with this complexity, but even though there are less than O(2^N)
actual configurations to calculate a demerit score for, it is still
prohibitively expensive to perform a full layout every time we need a
demerit score.
Maybe the problem can be alleviated by not associating a fixed line
height/skyline with each bar, but something that is dependent on the
current breakpoint sequence being considered.
Not sure what you mean. We do not and can not have a fixed line height
/ skyline for each bar -- as Joe just explained. For example, consider
music in the G clef; if a particular bar comes after a line break, it
will have a clef, making the bar much taller. So I am not sure what you
have in mind here... something else that I do not see?
Originally, the skyline was approximated by its bounding rectangle. In
other words, there was only one measurement: the line height. About a
year ago, to address the problem with G clefs, Joe added the distinction
between begin- and rest-of-line, for inter-staff, intra-system
space. (So instead of one point we have two). This worked reasonably
well for music with many staves per system; but for music on one staff
(e.g. instrument parts, or monody) this does no good, because all the
space is inter-system. So about two months ago I introduced the
begin/rest distinction for inter-system space (i.e. for computing
pure-height of a whole system). This still left some unaddressed things
like 1062, which is what today's discussion is about.
Boris
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Vertical spacing regression !?
On Wed, 2010-06-30 at 07:04 +0200, David Kastrup wrote:
Joe Neeman joenee...@gmail.com writes:
On Tue, 2010-06-29 at 20:23 +0200, Arno Waschk wrote:
can't we have correct heights say for every bar (which must be computed
later anyway) with clever caching so we have them ready when the final
layout is made?
No. For example, we don't know if a bar will have its clef displayed
until after line-breaking. Also, the vertical collision avoidance means
that in { c1^long long markup c1^long long markup }, we cannot
calculate the height of the second bar without considering the first bar
too (and the answer will change if they are on different lines).
Maybe I am dull, but we need the line heights (or skyline) for a given
line breakpoint sequence, and a given line breakpoint sequence has a
given skyline for each line.
No, we don't compute the full skyline for a sequence of breakpoints,
because doing so would require performing the full horizontal layout
first. My point is that it isn't possible to get _completely_ accurate
height estimates unless we do the complete layout for every possible
line-breaking configuration.
Cheers,
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Vertical spacing regression !?
On Mon, 2010-06-28 at 06:34 -0400, Boris Shingarov wrote: On 06/27/2010 01:25 PM, Joe Neeman wrote: On Sun, 2010-06-27 at 06:56 -0400, Boris Shingarov wrote: This was discussed on this list only a few weeks ago. I think we are on our way to get rid of global page*line breaking. Although I am happy to have an option to do full line-breaking before page-breaking, I am very much against getting rid of the line and page-breaking interaction. For example, if we did that then we would have to scrap the new vertical layout since it relies on being able to stretch the systems after the pages are determined. And while I have a personal bias against scrapping the vertical layout (since I wrote it), I do think that it is a big improvement over the previous layout algorithm and I have heard comments to that effect on the lists too. Also, the page-turn-breaker can't function without some interaction between line- and page-breaking. I understand the bad effects of divorcing line- from page-breaking. Another one (of those which I personally care about) is that it will negate the window/orphan handling feature I added. At least to my users, this is important. And yes, I do agree that the new layout algorithm *is* a big improvement over the previous one. But what do we do about the height estimation problems? For one thing, we can add an option to do the full horizontal layout first. system-count used to have this effect, so it isn't even very hard (see issue 325). No matter how important the positive effects of line/page-breaking interaction are, a score with staves cut at the bottom, is unusable. Agreed. There used to be a feature that would detect an overfull page and try to lay it out again without any padding between staves, but it didn't make it into the new page layout algorithm. It could be reinstated. And a score with the opposite problem, is equally unusable. I don't entirely agree with this one. Unless you have ragged-bottom=##t, underfilling the page by a single system is hardly noticeable (whereas overfitting by a single system is, of course). Can we realistically hope to fix enough bugs so that real publications will look usable? I have seen real publications that use 2.12 (which also used height-estimation). There are workarounds (like the page-breaking-between-system-spacing variable) and there could be more workarounds (like an option for doing the horizontal layout first). And the complaints from the lists have died down a lot compared to when the page-breaking*line-breaking was first introduced (2.9, IIRC), so I think we are converging on something that works consistently. I don't know. I started working on the estimations because the user's book suffered the problem. I fixed five, and pulled your fixes for a few. And yet the book is still suffering the same problem. I know what causes it *now*, but I do not know if this is going to be the last one *for this book*, and I am now facing problems of customer value when talking about fixing height estimation bugs. So what are we going to do, keep fixing these bugs, under the theory that there is only finite number of them? One thing that makes me nervous is that a lot of the time the fixes involve increase of computational complexity. We are moving from simple height estimation to more and more complex height estimation; can it be that as we approach being more and more correct in our estimation, the complexity also approaches that of full layout? We are still very far from full layout. As long as we avoid horizontal spacing (and all the layout that it requires), I think we're ok. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: authors+contributors list
Any new / new-ish contributors, please check: http://lilypond.org/website/authors.html The basic breakdown is: - if you have git access, you're a developer - if you don't, you're a contributor - developers shouldn't appear in the contributor list - developers can pretty much pick their own title/description/email/web AFAIK, we haven't been keeping track of this for the past 4-5 months, so I expect to have a few gaps. I'm listed in both Current contributors (as Pál Benkő) and in Previous Contributors (as Pal Benko), someone please remove the latter one. p ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: authors+contributors list
On Wed, Jun 30, 2010 at 10:59:54AM +0200, Benkő Pál wrote: I'm listed in both Current contributors (as Pál Benkő) and in Previous Contributors (as Pal Benko), someone please remove the latter one. Actually, that's fine -- Previous contributors is for anybody who worked on stuff before 2.13, while Current is for anybody who did stuff for 2.13. I'll try to think of how to clarify this on the page. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Vertical spacing regression !?
Joe Neeman joenee...@gmail.com writes:
On Wed, 2010-06-30 at 07:04 +0200, David Kastrup wrote:
Joe Neeman joenee...@gmail.com writes:
On Tue, 2010-06-29 at 20:23 +0200, Arno Waschk wrote:
can't we have correct heights say for every bar (which must be computed
later anyway) with clever caching so we have them ready when the final
layout is made?
No. For example, we don't know if a bar will have its clef displayed
until after line-breaking. Also, the vertical collision avoidance means
that in { c1^long long markup c1^long long markup }, we cannot
calculate the height of the second bar without considering the first bar
too (and the answer will change if they are on different lines).
Maybe I am dull, but we need the line heights (or skyline) for a given
line breakpoint sequence, and a given line breakpoint sequence has a
given skyline for each line.
No, we don't compute the full skyline for a sequence of breakpoints,
because doing so would require performing the full horizontal layout
first. My point is that it isn't possible to get _completely_ accurate
height estimates unless we do the complete layout for every possible
line-breaking configuration.
But a lot of line-break configurations share lines. And even more
configurations share starting measures, so things that appear only at
the beginning of a line don't need recalculation for every
configuration.
I see an ugly factor (basically O(n l) where l is the maximum line
length in measures, and n the number of measures), but it appears to me
that _if_ one properly shares information (namely using a shortest path
traversal linear programming algorithm), it is, for a fixed value of l,
basically a constant after all.
And that means something that you can hope to wait for.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Vertical spacing regression !?
On Wed, 2010-06-30 at 13:41 +0200, David Kastrup wrote:
Joe Neeman joenee...@gmail.com writes:
On Wed, 2010-06-30 at 07:04 +0200, David Kastrup wrote:
Joe Neeman joenee...@gmail.com writes:
On Tue, 2010-06-29 at 20:23 +0200, Arno Waschk wrote:
can't we have correct heights say for every bar (which must be computed
later anyway) with clever caching so we have them ready when the final
layout is made?
No. For example, we don't know if a bar will have its clef displayed
until after line-breaking. Also, the vertical collision avoidance means
that in { c1^long long markup c1^long long markup }, we cannot
calculate the height of the second bar without considering the first bar
too (and the answer will change if they are on different lines).
Maybe I am dull, but we need the line heights (or skyline) for a given
line breakpoint sequence, and a given line breakpoint sequence has a
given skyline for each line.
No, we don't compute the full skyline for a sequence of breakpoints,
because doing so would require performing the full horizontal layout
first. My point is that it isn't possible to get _completely_ accurate
height estimates unless we do the complete layout for every possible
line-breaking configuration.
But a lot of line-break configurations share lines. And even more
configurations share starting measures, so things that appear only at
the beginning of a line don't need recalculation for every
configuration.
I see an ugly factor (basically O(n l) where l is the maximum line
length in measures, and n the number of measures),
Ok, but if l is 10 then that's still 10 times as much layout time as
before.
It isn't just a matter of running time, though. There are plenty of
side-effects in the layout step (for example, grobs which get
destroyed). If we really wanted to try multiple layouts, someone would
have to go through the whole backend code to remove these side-effects.
Cheers,
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: authors+contributors list
Graham Percival gra...@percival-music.ca writes: On Wed, Jun 30, 2010 at 10:59:54AM +0200, Benkő Pál wrote: I'm listed in both Current contributors (as Pál Benkő) and in Previous Contributors (as Pal Benko), someone please remove the latter one. Actually, that's fine -- Previous contributors is for anybody who worked on stuff before 2.13, while Current is for anybody who did stuff for 2.13. I'll try to think of how to clarify this on the page. Oops. I thought that the idea was not to duplicate listings. I already changed the entry, but if it is to be changed back, it seems like a good idea to correct the spelling. Incidentally, I have my doubts that Benkő will be rendered properly in the printed PDF manual, but it would appear that it looks fine in HTML and in info (inside of Emacs). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: authors+contributors list
Benkő Pál benko@gmail.com writes: Any new / new-ish contributors, please check: http://lilypond.org/website/authors.html The basic breakdown is: - if you have git access, you're a developer - if you don't, you're a contributor - developers shouldn't appear in the contributor list - developers can pretty much pick their own title/description/email/web AFAIK, we haven't been keeping track of this for the past 4-5 months, so I expect to have a few gaps. I'm listed in both Current contributors (as Pál Benkő) and in Previous Contributors (as Pal Benko), someone please remove the latter one. Done. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Vertical spacing regression !?
Joe Neeman joenee...@gmail.com writes: It isn't just a matter of running time, though. There are plenty of side-effects in the layout step (for example, grobs which get destroyed). If we really wanted to try multiple layouts, someone would have to go through the whole backend code to remove these side-effects. As I said: I was just putting out my spontaneous thoughts. If I was responsible manager, I'd declare make it so and rush out before anybody clubs me. Instead I am in the position of doomsayer. And if you say typesetting a complex score with 100 pages will take a week for the final, good pass, then the obvious reply is that letting it done manually will require two months. So an expensive good option is still worth a lot, as long as the expense is not ridiculous. As long as the expense remains close to linear to the size of the task, one can manage it by throwing heavier iron at it when time is important. What you label as these side-effects sounds like something that is going to come back and bite us, anyway. So much for my gut feelings. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: authors+contributors list
On Wed, Jun 30, 2010 at 02:01:06PM +0200, David Kastrup wrote: Oops. I thought that the idea was not to duplicate listings. I already changed the entry, but if it is to be changed back, it seems like a good idea to correct the spelling. Yes, please change it back, and fix the spelling. Sorry about the uncertainty here. Incidentally, I have my doubts that Benkő will be rendered properly in the printed PDF manual, but it would appear that it looks fine in HTML and in info (inside of Emacs). I remember being told that texinfo 4.12 supported unicode and that we should insert accented characters normally (without using tex-like \'a notation). I confess that I've never tried looking at the actual pdf output. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: authors+contributors list
Graham Percival gra...@percival-music.ca writes: On Wed, Jun 30, 2010 at 02:01:06PM +0200, David Kastrup wrote: Oops. I thought that the idea was not to duplicate listings. I already changed the entry, but if it is to be changed back, it seems like a good idea to correct the spelling. Yes, please change it back, and fix the spelling. Sorry about the uncertainty here. Done. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Vertical spacing regression !?
Hi David, Instead I am in the position of doomsayer. And if you say typesetting a complex score with 100 pages will take a week for the final, good pass, then the obvious reply is that letting it done manually will require two months. So an expensive good option is still worth a lot, as long as the expense is not ridiculous. I agree... but if we're trying to woo the masses, we're competing against FinSib, with their almost instantaneous spacing redraws. Of course, as long as it's a switch, which can be flipped on when one has the luxury of running the compilation overnight, it's no problem IMO. Cheers, Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Re: tablature: ties and harmonics (issue1669041)
On 6/30/10 1:48 AM, Marc Hohl m...@hohlart.de wrote: Carl Sorensen schrieb: [...] http://codereview.appspot.com/1669041/diff/26001/27004#newcode130 scm/define-grob-properties.scm:130: (bracket-width ,number? Width of the harmonic angle bracket.) Why do we need bracket-width? Why can't we just use the pre-existing width property? Hm, Neil proposed to use a more descriptive name for this property, IIUC. Done. Well, if we want to have this be part of the parenthesis-interface, then we may want to go ahead with bracket-width. Ok, done. [...] If instead of making the whiteout and the stencil different stencils, we combined them, then parenthesize-stencil would work great. But this might not be possible if we need to have the stencil and the whiteout on separate layers. As an alternative, parenthesize-stencil could be modified to take white-padding as an argument. There's nothing that says we can't modify scm/stencil.scm so that it works better for tablature. It's much better, IMO, to have one general-purpose piece of code than to have two separate special-purpose code chunks. So I tried to extend the parenthesize-stencil function in scm/stencil.scm. It compiles without error, but the regression file is cluttered up. Can you tell me what you mean by the regression file is cluttered up? Can you tell me which examples fail the regression test for graphical output? (The changes that indicate different amounts of memory don't bother me a bit). I feel that this is not the right approach, either. I still don't understand why I have to shift the TabNoteHead #'layer at all. As far as I see it, HarmonicParenthesesItem #'stencils is a list of stencils, containing the left and the right angle bracket, which are placed either side of the TabNoteHead #'stencil. So the order in which the stancils are placed should not change anything at all, but if the TabNoteHead #'stencil is set *before* the HarmonicParenthesesItem #'stencils, it seems that some whitespace occurs between the angle brackets, overriding the already placed TabNoteHead. Have you looked at the list of stencils created by parenthesis-item::calc-parentehesis-stencils grob and map stencil-whiteout (parenthesis-item::calc-parentehesis-stencils grob) to see how they differ? Sometimes lists get reversed during LilyPond processing. Perhaps this is happening to this list. You might see what happens if you reverse the list of stencils If on the other hand the whiteout would not appear, we could just use the parenthesize-tab-note-head function defined in scm/tablature.scm. This function could detect whether we have a harmonic and in this case would place the parentheses just further apart. Furthermore, I have a bad feeling to misuse your time reviewing my patch for error seeking issues, but I am stuck here. I don't view it as a misuse of time. But right now I'm very busy, so I may not get to it very quickly I like the general idea of not defining the same functionality over and over again, but on the other hand, the parenthesize-stencil function in scm/stencil.scm does not seem to be used anywhere else ... Parenthesize-stencil will be used for the new chord namer, so we need to keep it in stencil.scm and keep the current functionality. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Patch for issue #1116 (one stencil in fill-line) (issue1689041)
Are you still waiting for someone to review this? If so, here are a couple minor things: http://codereview.appspot.com/1689041/diff/2001/3001 File scm/define-markup-commands.scm (right): http://codereview.appspot.com/1689041/diff/2001/3001#newcode848 scm/define-markup-commands.scm:848: X RIGHT fill-space line-stencils))) These two set!s could be written more concisely as (set! line-stencils (stack-stencils-padding-list X RIGHT fill-space empty-stencil))) http://codereview.appspot.com/1689041/diff/2001/3001#newcode850 scm/define-markup-commands.scm:850: (if ( word-count 1) I know there aren't many comments in the code, but that doesn't mean you can't add one... http://codereview.appspot.com/1689041/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tablature: ties and harmonics (issue1669041)
On 2010/06/30 07:48:12, marc wrote: So I tried to extend the parenthesize-stencil function in scm/stencil.scm. It compiles without error, but the regression file is cluttered up. I can't test this. Would you mind uploading another version here which includes all the changes since the first patch set? I feel that this is not the right approach, either. I still don't understand why I have to shift the TabNoteHead #'layer at all. As far as I see it, HarmonicParenthesesItem #'stencils is a list of stencils, containing the left and the right angle bracket, which are placed either side of the TabNoteHead #'stencil. So the order in which the stancils are placed should not change anything at all, but if the TabNoteHead #'stencil is set *before* the HarmonicParenthesesItem #'stencils, it seems that some whitespace occurs between the angle brackets, overriding the already placed TabNoteHead. You added the default for 'whiteout to HarmonicParenthesesItem in your first patch. It applies the whiteout to the total extent: the two brackets plus the space between. I don't know why grobs with the same layer sometimes swap places, but there's nothing we can do about it apart from change 'layer to ensure visibility, unless you remove 'whiteout for the angle brackets. Cheers, Neil http://codereview.appspot.com/1669041/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
