On Nov 23, 2011, at 9:21 AM, Keith OHara wrote:
> On Mon, 21 Nov 2011 00:16:12 -0800, Keith OHara wrote:
>
>> On Sun, 20 Nov 2011 23:57:22 -0800, wrote:
>>
>>> I think that you're right for most cases, but for a piece with lots of
>>> accidentals that could potentially hang over barlines, this
On Mon, 21 Nov 2011 00:16:12 -0800, Keith OHara wrote:
On Sun, 20 Nov 2011 23:57:22 -0800, wrote:
I think that you're right for most cases, but for a piece with lots of
accidentals that could potentially hang over barlines, this complexity
in estimation seems to help.
Have an example where
passes make and no reg tests show up.
James
http://codereview.appspot.com/5323062/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Sun, 20 Nov 2011 23:57:22 -0800, wrote:
On Mon, 21 Nov 2011 07:06:53 +, k-ohara5...@oco.net wrote:
Well, any overestimation in your blocking heights also becomes an
overestimation in the tentative space between Staves/Lyrics/Dynamics
at the horizontal spacing step.
I think that you'r
On Mon, 21 Nov 2011 07:06:53 +, k-ohara5...@oco.net wrote:
Looks okay to me.
The ghost of the SpanBar (left over from the issue 910 patch)
sometimes
has an effect
\new GrandStaff <<
\new Staff { e'1 | eses'''4 r2. | e'1 }
\new Staff { e'1 | e'1 | eses4 r2. } >>
Something like
\
Looks okay to me.
The ghost of the SpanBar (left over from the issue 910 patch) sometimes
has an effect
\new GrandStaff <<
\new Staff { e'1 | eses'''4 r2. | e'1 }
\new Staff { e'1 | e'1 | eses4 r2. } >>
Something like
\override Score.SpanBar #'extra-spacing-height
= #'(+inf.0 . -
Passes make and reg tests are here
http://code.google.com/p/lilypond/issues/detail?id=2000#c32
James
http://codereview.appspot.com/5323062/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Passes Make and reg tests are all here
http://lilypond-stuff.1065243.n5.nabble.com/Tracker-issue-2000-12-November-td4986583.html
James
http://codereview.appspot.com/5323062/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org
Doesn't pass make
--snip--
[/home/jlowe/lilypond-git/build/out/share/lilypond/current/scm/lily-sort.scm]
[/home/jlowe/lilypond-git/build/out/share/lilypond/current/scm/document-functions.scm]
[/home/jlowe/lilypond-git/build/out/share/lilypond/current/scm/document-translation.scm]
[/home/jlowe/li
On Nov 11, 2011, at 5:22 PM, Peekay Ex wrote:
>
> Thanks, so just to be clear i can still test the patch en masse?
>
> --
> --
> James
Yup.
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lil
Mike,
On Fri, Nov 11, 2011 at 3:55 PM, m...@apollinemike.com
wrote:
> On Nov 11, 2011, at 4:44 PM, Peekay Ex wrote:
>
>> Mike,
>>
>> On Fri, Nov 11, 2011 at 3:34 PM, m...@apollinemike.com
>> wrote:
>>>
>>
>> ...
>>
>>> I posted an uber-patch online that can be separated out into several
>>> patc
On Nov 11, 2011, at 4:44 PM, Peekay Ex wrote:
> Mike,
>
> On Fri, Nov 11, 2011 at 3:34 PM, m...@apollinemike.com
> wrote:
>>
>
> ...
>
>> I posted an uber-patch online that can be separated out into several
>> patches.
>
>
>
> My only concern is that it will only get tested as an uber
Mike,
On Fri, Nov 11, 2011 at 3:34 PM, m...@apollinemike.com
wrote:
>
...
> I posted an uber-patch online that can be separated out into several
> patches.
My only concern is that it will only get tested as an uber patch and
unless you are going to push it all at once (albeit with severa
On Nov 10, 2011, at 7:49 PM, m...@apollinemike.com wrote:
> On Nov 10, 2011, at 10:38 AM, k-ohara5...@oco.net wrote:
>
>
>> If SpanBars have space reserved where and only where they print, issue
>> 910 would be solved.
>>
>> If BarLines and KeySignatures later receive extra-spacing-height to
>
passes make and reg tests all posted here:
http://lilypond-stuff.1065243.n5.nabble.com/Tracker-issue-2000-reg-test-diffs-10-Nov-2011-td4962666.html
James
http://codereview.appspot.com/5323062/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
ht
On Nov 10, 2011, at 10:38 AM, k-ohara5...@oco.net wrote:
> On 2011/11/10 14:51:22, MikeSol wrote:
>
>>> If we know the space allocated to a staff during horizontal spacing
>> (the
>>> ly:axis-group-interface::height, I think) and the goal (for issue
>> 1955) is to
>>> build a wall to block anythi
On 2011/11/10 14:51:22, MikeSol wrote:
If we know the space allocated to a staff during horizontal spacing
(the
ly:axis-group-interface::height, I think) and the goal (for issue
1955) is to
build a wall to block anything on the staff, then why build each wall
to a
custom, usually shorter,
As always, many thanks for your comments!
http://codereview.appspot.com/5323062/diff/53017/lily/pure-from-neighbor-engraver.cc
File lily/pure-from-neighbor-engraver.cc (right):
http://codereview.appspot.com/5323062/diff/53017/lily/pure-from-neighbor-engraver.cc#newcode72
lily/pure-from-neighbor
http://codereview.appspot.com/5323062/diff/53017/lily/pure-from-neighbor-engraver.cc
File lily/pure-from-neighbor-engraver.cc (right):
http://codereview.appspot.com/5323062/diff/53017/lily/pure-from-neighbor-engraver.cc#newcode72
lily/pure-from-neighbor-engraver.cc:72: //first, clump pure_releva
passes make and reg test diffs are all here:
http://lilypond-stuff.1065243.n5.nabble.com/Tracker-issue-2000-reg-test-diffs-9-Nov-2011-td4962666.html
James
http://codereview.appspot.com/5323062/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
h
On Nov 8, 2011, at 10:16 PM, k-ohara5...@oco.net wrote:
>
> http://codereview.appspot.com/5323062/diff/39005/lily/pure-from-neighbor-engraver.cc
> File lily/pure-from-neighbor-engraver.cc (right):
>
> http://codereview.appspot.com/5323062/diff/39005/lily/pure-from-neighbor-engraver.cc#newcode60
http://codereview.appspot.com/5323062/diff/39005/lily/pure-from-neighbor-engraver.cc
File lily/pure-from-neighbor-engraver.cc (right):
http://codereview.appspot.com/5323062/diff/39005/lily/pure-from-neighbor-engraver.cc#newcode60
lily/pure-from-neighbor-engraver.cc:60: pure_relevants_.push_back
"m...@apollinemike.com" writes:
> example. I've attached two versions of:
>
> \relative c {
>
> }
>
>
> one from current master and one from the most recent version of my
> patch set. If the version from current master is acceptable in
> traditional typesetting, then I'll revert. But a
Passes make and all reg test diffs here:
http://lilypond-stuff.1065243.n5.nabble.com/Tracker-issue-2000-reg-test-diffs-8-Nov-2011-td4962666.html
james
http://codereview.appspot.com/5323062/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https
On Tue, 08 Nov 2011 08:01:01 -0800, m...@apollinemike.com
wrote:
If the version from current master is acceptable in traditional
typesetting,then I'll revert. But all the (meager) evidence I find is to the
contrary(also see attached), which is why I'm standing by the most recent patch
set.
On Nov 7, 2011, at 9:33 PM, Keith OHara wrote:
> On Mon, 07 Nov 2011 20:51:14 -0800, m...@apollinemike.com
> wrote:
>
>> I'm OK with getting rid of all of this pure-from-neighbor and span-bar-stub
>> stuff and just create several SpanBars instead of one SpanBar with gaps in
>> its stencil. I
On Mon, 07 Nov 2011 20:51:14 -0800, m...@apollinemike.com
wrote:
I'm OK with getting rid of all of this pure-from-neighbor and span-bar-stub
stuff and just create several SpanBars instead of one SpanBar with gaps in its
stencil. I can reuse code I've already written, so it's not that bad.
On Nov 7, 2011, at 8:19 PM, Keith OHara wrote:
> Mike,
> Now that we understand that we can adjust 'extra-spacing-height
> for note-spacing, without messing up line-breaking or page-spacing,
> let's revisit the big picture.
>
> On Fri, 04 Nov 2011 00:12:01 -0700, m...@apollinemike.com
> wrote:
Mike,
Now that we understand that we can adjust 'extra-spacing-height
for note-spacing, without messing up line-breaking or page-spacing,
let's revisit the big picture.
On Fri, 04 Nov 2011 00:12:01 -0700, m...@apollinemike.com
wrote:
On Nov 3, 2011, at 11:39 PM, k-ohara5...@oco.net wrote:
On Mon, 07 Nov 2011 11:36:09 -0800, m...@apollinemike.com
wrote:
On Nov 7, 2011, at 10:46 AM, Keith OHara wrote:
I had not realized that the results of the pure-from-neighbor system influence
the page-spacing.
I misspoke - in this case, it does not. But it does potentially add unwanted
Passes make but lots of reg test diffs as usual
http://lilypond-stuff.1065243.n5.nabble.com/Tracker-issue-2000-reg-test-diffs-7-Nov-2011-td4962666.html
Jame
http://codereview.appspot.com/5323062/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
On Nov 7, 2011, at 10:46 AM, Keith OHara wrote:
>
>> This is saying "if the closest column is a grace-note-column, include
>> the next-closest column as well." This gets rid of any accidental
>> overlap problems at the expense of potentially adding a little extra
>> vertical space to the page-s
On Sun, 06 Nov 2011 23:34:37 -0800, wrote:
http://codereview.appspot.com/5323062/diff/28002/lily/pure-from-neighbor-interface.cc#newcode96
lily/pure-from-neighbor-interface.cc:96: && (grace == LEFT ? has_grace :
!has_grace))
On 2011/11/07 01:25:30, Keith wrote:
In fact, why even use a loop ove
http://codereview.appspot.com/5323062/diff/28002/lily/pure-from-neighbor-interface.cc
File lily/pure-from-neighbor-interface.cc (right):
http://codereview.appspot.com/5323062/diff/28002/lily/pure-from-neighbor-interface.cc#newcode84
lily/pure-from-neighbor-interface.cc:84: // uses drul array for
Until someone comes along who understands this, I'll display my
confusions.
http://codereview.appspot.com/5323062/diff/28002/lily/pure-from-neighbor-interface.cc
File lily/pure-from-neighbor-interface.cc (right):
http://codereview.appspot.com/5323062/diff/28002/lily/pure-from-neighbor-interface
passes make, lots of reg test diffs here
http://lilypond-stuff.1065243.n5.nabble.com/Tracker-issue-2000-reg-test-diffs-td4962666.html
James
http://codereview.appspot.com/5323062/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gn
On Nov 5, 2011, at 4:11 PM, k-ohara5...@oco.net wrote:
> http://codereview.appspot.com/5323062/diff/29001/lily/pure-from-neighbor-engraver.cc#newcode49
> lily/pure-from-neighbor-engraver.cc:49: SCM pure_relevant_p =
> ly_lily_module_constant ("pure-relevant?");
> Now, this fills 'items_' with thin
>> Pure relevant is used all over the code.
>
> Good point. There is even a predicate 'pure-relevant?'
> defining which grobs qualify.
>
Exactly. This is how the Pure_from_neighbor_engraver
evaluates which grobs have
pure height functions (line 49).
http://codereview.appspot.com/5323062/d
"m...@apollinemike.com" writes:
> On Nov 5, 2011, at 12:27 PM, Keith OHara wrote:
>
>>
>> I worry because you make the spacing given to bar lines rather
>> independent of the printed extent of bar lines, and the way you
>> calculate the space uses a part of LilyPond that I find hard to
>> unders
On Nov 5, 2011, at 12:27 PM, Keith OHara wrote:
>
> I worry because you make the spacing given to bar lines rather independent of
> the printed extent of bar lines, and the way you calculate the space uses a
> part of LilyPond that I find hard to understand.
It took me months to get my head ar
On Sat, 05 Nov 2011 04:19:47 -0700, m...@apollinemike.com
wrote:
On Nov 4, 2011, at 2:35 PM, Keith OHara wrote:
The bug happens when the piece is entirely hight notes. (I should add some
intelligence to handle this case, so that we can use 'skyline-vertical-padding
without this annoyance.)
On Nov 4, 2011, at 2:35 PM, Keith OHara wrote:
> The bug happens when the piece is entirely hight notes. (I should add some
> intelligence to handle this case, so that we can use
> 'skyline-vertical-padding without this annoyance.) Any single protrusion
> below the staff anywhere in the piece
Passes Make but lots of reg test diffs
http://lilypond-stuff.1065243.n5.nabble.com/Tracker-issue-2000-reg-test-diffs-td4962666.html
James
http://codereview.appspot.com/5323062/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.
On Fri, 04 Nov 2011 14:02:57 -0700, m...@apollinemike.com
wrote:
I agree it would be nice to change this, but did you really see the
problem in real music?
It's the lyrics. There are some very high notes where the lyrics don't tuck
under the barline, which required me to make some extra-o
On Nov 4, 2011, at 1:00 PM, Keith OHara wrote:
> On Fri, 04 Nov 2011 09:47:16 -0700, m...@apollinemike.com
> wrote:
>
>> I think that it is easier to tweak this sort of thing of bar lines know
>> about the existence of leftward-hanging grobs and can deal with them.
>
> I guess it is more flex
On Fri, 04 Nov 2011 09:47:16 -0700, m...@apollinemike.com
wrote:
I think that it is easier to tweak this sort of thing of bar lines know about
the existence of leftward-hanging grobs and can deal with them.
I guess it is more flexible if there is the option to have
'extra-spacing-height be
On Nov 4, 2011, at 1:52 AM, Keith OHara wrote:
> On Fri, 04 Nov 2011 00:12:01 -0700, m...@apollinemike.com
> wrote:
>> On Nov 3, 2011, at 11:39 PM, k-ohara5...@oco.net wrote:
>>> What is the overall plan for the new engravers?
>>
>> Currently, LilyPond has no mechanism to calculate the Y-extent
On Nov 4, 2011, at 1:02 AM, David Kastrup wrote:
> "m...@apollinemike.com" writes:
>
>> On Nov 3, 2011, at 11:39 PM, k-ohara5...@oco.net wrote:
>>
>>> http://codereview.appspot.com/5323062/diff/12001/lily/pure-from-neighbor-engraver.cc
>>> File lily/pure-from-neighbor-engraver.cc (right):
>>>
On Fri, 04 Nov 2011 00:12:01 -0700, m...@apollinemike.com
wrote:
On Nov 3, 2011, at 11:39 PM, k-ohara5...@oco.net wrote:
What is the overall plan for the new engravers?
Currently, LilyPond has no mechanism to calculate the Y-extents of Items in a relative
way. You can't say "make the heigh
"m...@apollinemike.com" writes:
> On Nov 3, 2011, at 11:39 PM, k-ohara5...@oco.net wrote:
>
>> http://codereview.appspot.com/5323062/diff/12001/lily/pure-from-neighbor-engraver.cc
>> File lily/pure-from-neighbor-engraver.cc (right):
>>
>> http://codereview.appspot.com/5323062/diff/12001/lily/pur
On Nov 3, 2011, at 11:39 PM, k-ohara5...@oco.net wrote:
> I'll try to make a patch so that note-spacing is not affected by
> potential collisions between grobs from different staff-like-contexts
> (fixing the rare Lyrics-barline interaction). Then we can restore
> skyline-vertical-padding.
>
> N
I'll try to make a patch so that note-spacing is not affected by
potential collisions between grobs from different staff-like-contexts
(fixing the rare Lyrics-barline interaction). Then we can restore
skyline-vertical-padding.
Net, with this patch and the other SpanBarStub patch, you've added 68
Passes Make but lots of reg test diffs here:
http://lilypond-stuff.1065243.n5.nabble.com/Tracker-issue-2000-reg-test-diffs-td4962666.html
James
http://codereview.appspot.com/5323062/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://list
On Nov 1, 2011, at 6:51 PM, Keith OHara wrote:
> If the idea is that your pure-from-neighbor stuff takes over this
> job, by giving extra-spacing-height based on surroundings, just make
> sure all things get the spacing they need:
> prefatory-separation.ly
> script-stack-horizontal.ly
> spacing-f
mike apollinemike.com apollinemike.com> writes:
> >
> > So if we take this patch, we should probably change the regression test,
> > as well, because the SpanBars will not actually be participating in the
> > horizontal collision system.
> > (e.g., if somebody does \remove "Bar_engraver", the
mike apollinemike.com apollinemike.com> writes:
>
> -) TabStaffs tend to make horizontal spacing tighter, as the average spring
between paper columns has an
> ideal length that is shorter than that of staves comprised of normal notes.
Very true. The lack of time-signature and key-signature ma
On Nov 1, 2011, at 12:52 AM, Keith OHara wrote:
>> This fixes the SpanBar regression ID'd by Phil.
>
> Well, not exactly. The failing regression test said:
> texidoc = "SpanBars participate in the horizontal collision system;
> the accidentals should not collide with the bar lines."
>
> This p
On 2011/11/01 08:25:48, mike_apollinemike.com wrote:
Given that the 0.6 skyline horizontal padding is,
according to the comment above it, only intended to block ledger lines
from
overlapping a bar line, I think that this blocking effect it has on
horizontal
spacing is an unintended side effec
On Oct 31, 2011, at 6:18 PM, m...@apollinemike.com wrote:
> On Oct 31, 2011, at 3:19 PM, Phil Holmes wrote:
>
>>
>> Mike - do you have a Windows machine? And a Windows .exe for your changes?
>> If so, you could run my pixel comparator.
>>
>> --
>> Phil Holmes
>>
>>
>
> Unfortunately, I do
> This fixes the SpanBar regression ID'd by Phil.
Well, not exactly. The failing regression test said:
texidoc = "SpanBars participate in the horizontal collision system;
the accidentals should not collide with the bar lines."
This patch implements issue 1955, keeping accidentals, fingerings,
On Oct 31, 2011, at 3:19 PM, Phil Holmes wrote:
>
> Mike - do you have a Windows machine? And a Windows .exe for your changes?
> If so, you could run my pixel comparator.
>
> --
> Phil Holmes
>
>
Unfortunately, I don't have a Windows machine, nor am I able to make a Windows
.exe :(
I'll be
- Original Message -
From:
To:
Cc: ;
Sent: Monday, October 31, 2011 9:08 AM
Subject: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)
Reviewers: ,
Message:
Hey all,
This fixes the SpanBar regression ID'd by Phil. It also fixes a few
other things:
1) The research I
>> Ideally, this should be another three different commits.
>
> The fixes are offshoots of the solution, meaning that the solution
> to this one problem serendipitously fixes the three others.
Ah, ok.
Werner
___
lilypond-devel mailing list
lilypo
On Oct 31, 2011, at 11:12 AM, Werner LEMBERG wrote:
>
>> This fixes the SpanBar regression ID'd by Phil.
>
> Thanks for working on this. Ideally, this should be one commit.
>
>> It also fixes a few other things: 1) [...] 2) [...] 3) [...]
>
> Ideally, this should be another three different co
> This fixes the SpanBar regression ID'd by Phil.
Thanks for working on this. Ideally, this should be one commit.
> It also fixes a few other things: 1) [...] 2) [...] 3) [...]
Ideally, this should be another three different commits.
Werner
__
Reviewers: ,
Message:
Hey all,
This fixes the SpanBar regression ID'd by Phil. It also fixes a few
other things:
1) The research I sent out about accidentals not hanging over barlines
(check my e-mails to the list from Oct. 6, Subject: First stab at
getting bar extents right) is actualize
66 matches
Mail list logo
