headers
mike@apollinemike.com | 1 Apr 2011 03:05

Re: Adds stem acknowledgement to beam collision engraver to fix issue 795. (issue4337045)

On Mar 31, 2011, at 6:39 PM, percival.music.ca <at> gmail.com wrote:

> Lots of changes to stem lengths, but it compiles and nothing makes me go
> "definitely ick".
> 
> http://codereview.appspot.com/4337045/

I'm a fan of most of the changes in the regtests.

I'm amazed you got it to compile, though.  Mine segfaulted, at which point I changed it to disregard stems
with beams.  New patch set uploaded.

Cheers,
MS
Permalink | Reply | 0 comments |
headers
Mark Polesky | 1 Apr 2011 08:03
Picon
Favicon

Re: Clarification for \null in \header markups

James Lowe wrote:
> I am making a patch for some updates for Titles and
> Headers and a para in the doc currently says:
>
> "Text fields left unset in a \header block are replaced
> with \null markups so space is not wasted...."
>
> Then there is an  <at> c from Mark Polesky asking if this is
> true?
>
> I wondered if anyone knew or if it even matters that we
> state this or not.

James,

Yikes, my last post was 100 days ago!  Anyway, I'm just
writing to clarify for everyone else, you must be referring
to this unpublished patch of mine from December:
http://codereview.appspot.com/3667041
The text and  <at> c you mention do not appear in the savannah
repo.

I'm chiming in here mostly because I put a lot of work into
that patch, and the consensus was that the content was good
but the format wasn't quite right.  I subsequently got too
busy to fix it, but there are some good parts there that (I
think) should clear up some confusing things for a lot of
users.

So if someone (you or anyone else) has time and interest, it
(Continue reading)

Permalink | Reply | 3 comments |
headers
Phil Holmes | 1 Apr 2011 10:17
Favicon

Re: 2.13.56 regtests

Has anyone looked at these differences in note placement?  Were they 
deliberate?  If they're not, then they'd have to count as a regression.

--

-- 
Phil Holmes
Bug Squad
Permalink | Reply | 1 comment |
headers
James Lowe | 1 Apr 2011 14:36
Favicon

RE: Clarification for \null in \header markups

Mark,

)-----Original Message-----
)From: Mark Polesky [mailto:markpolesky <at> yahoo.com]
)Sent: 01 April 2011 07:04
)To: 'lilypond-devel <at> gnu.org'; James Lowe
)Subject: Re: Clarification for \null in \header markups
)
)James Lowe wrote:
)> I am making a patch for some updates for Titles and Headers and a para
)> in the doc currently says:
)>
)> "Text fields left unset in a \header block are replaced with \null
)> markups so space is not wasted...."
)>
)> Then there is an  <at> c from Mark Polesky asking if this is true?
)>
)> I wondered if anyone knew or if it even matters that we state this or
)> not.
)
)
)James,
)
)Yikes, my last post was 100 days ago!  Anyway, I'm just writing to clarify for
)everyone else, you must be referring to this unpublished patch of mine
)from December:
)http://codereview.appspot.com/3667041
)The text and  <at> c you mention do not appear in the savannah repo.
)
)I'm chiming in here mostly because I put a lot of work into that patch, and
(Continue reading)

Permalink | Reply | 2 comments |
headers
mike@apollinemike.com | 1 Apr 2011 14:45

Ties over line breaks w/ accidentals

I'm not sure what good default behavior would be for:

{<fis a cis'>1 ~ \break <fis a cis'>1 }

but it seems that the tie for a-natural should either be killed or made slightly longer.

It prints fine w/o the accidental on the f:

{<f a cis'>1 ~ \break <f a cis'>1 }

Thoughts?

Cheers,
MS
Permalink | Reply | 1 comment |
headers
Dmytro O. Redchuk | 1 Apr 2011 14:51
Picon

Re: Ties over line breaks w/ accidentals

On Fri 01 Apr 2011, 08:45 mike <at> apollinemike.com wrote:
> I'm not sure what good default behavior would be for:
> 
> {<fis a cis'>1 ~ \break <fis a cis'>1 }
I guess it (the tie) should be a bit longer, see 1219:
http://code.google.com/p/lilypond/issues/detail?id=1219

> but it seems that the tie for a-natural should either be killed or made slightly longer.
> 
> It prints fine w/o the accidental on the f:
> 
> {<f a cis'>1 ~ \break <f a cis'>1 }
This _exactly_ the same picture as above (well, yes, the tie is a very little
bit longer thought).

--

-- 
  Dmytro O. Redchuk
  Bug Squad
Permalink | Reply | 0 comments |
headers
Graham Percival | 1 Apr 2011 17:08
Picon
Favicon

Re: 2.13.56 regtests

On Fri, Apr 01, 2011 at 09:17:10AM +0100, Phil Holmes wrote:
> Has anyone looked at these differences in note placement?  Were they
> deliberate?  If they're not, then they'd have to count as a
> regression.

I glanced at it initially and saw nothing bad, but when there's
animation as well, it really *does* look suspicious.

Thanks, added as:
http://code.google.com/p/lilypond/issues/detail?id=1589

Cheers,
- Graham
Permalink | Reply | 0 comments |
headers
percival.music.ca | 1 Apr 2011 17:13
Picon

Re: Adds stem acknowledgement to beam collision engraver to fix issue 795. (issue4337045)

What happened to
   input/regression/staccato-pos.ly
   input/regression/beam-multiple-cross-staff.ly
?  it looks like those are currently broken, and this patch fixes it?
Is this just my system acting weird, or did we really miss two broken
regtests earlier?

oh wait, the beam-multiple- regtest has a collision between beam and
notehead.  It still looks better than before, but you might want to take
a look at it.

http://codereview.appspot.com/4337045/
Permalink | Reply | 0 comments |
headers
Graham Percival | 1 Apr 2011 17:26
Picon
Favicon

Re: landscape mode vs. new paper size

On Sun, Mar 27, 2011 at 12:50:07PM +0000, James Lowe wrote:
> That's OK, we can still do this with 'proper' paper sizes with
> internationally defined names rather than our own custom ones. 
>
> For example, we could define some 'C' sizes which are used for
> defining envelopes, are as internationally recognised as 'A'
> sizes but come in landscape dimensions small enough to be useful
> for us to use in the doc, I think. 

ok, great!

Could we get this part moving?  i.e. make a separate patch for the
NR 3 chapter -- just add an extra  <at> lilypond to the very end of the
chapter, if nothing else comes to mind -- that shows a tagline.

The goal(s) are:
1. get at least one paper size defined
2. get the  <at> lilypond[options] finalized
3. feel good that after working for 3 months, there's at least one
commit on this topic.  :)

Treat the breakbefore issue as completely separate for now.

Cheers,
- Graham
Permalink | Reply | 1 comment |
headers
James Lowe | 1 Apr 2011 17:58
Favicon

RE: landscape mode vs. new paper size

Graham,

)-----Original Message-----
)From: Graham Percival [mailto:graham <at> percival-music.ca]
)Sent: 01 April 2011 16:27
)To: James Lowe
)Cc: lilypond-devel <at> gnu.org
)Subject: Re: landscape mode vs. new paper size
)
)On Sun, Mar 27, 2011 at 12:50:07PM +0000, James Lowe wrote:
)> That's OK, we can still do this with 'proper' paper sizes with
)> internationally defined names rather than our own custom ones.
)>
)> For example, we could define some 'C' sizes which are used for
)> defining envelopes, are as internationally recognised as 'A'
)> sizes but come in landscape dimensions small enough to be useful for
)> us to use in the doc, I think.
)
)ok, great!
)
)Could we get this part moving?  i.e. make a separate patch for the NR 3
)chapter -- just add an extra  <at> lilypond to the very end of the chapter, if
)nothing else comes to mind -- that shows a tagline.
)
)The goal(s) are:
)1. get at least one paper size defined
)2. get the  <at> lilypond[options] finalized
)3. feel good that after working for 3 months, there's at least one commit
)on this topic.  :)
)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane