On 2011/05/01 00:45:20, mike_apollinemike.com wrote:
Pushed as 475a1f94b5733476d746d2c012809f3f2e6f0fcc.
Mike, that commit was just the merge, the fix was committed in b8dfb8
The way you committed, merged, and then pushed, puts a loop in the
history that confuses tools like git blame and
2011/5/4 Nicolas Sceaux nicolas.sce...@gmail.com:
Le 4 mai 2011 à 13:18, Francisco Vila a écrit :
Is this the intended output? Looks as if a C (incomplete) chord is
created where there is no previous chord.
{ c'8 q }
What output can be intended when the input is wrong?
Oh, I don't expect
I've got a new patch - do you want to look at it on your travels, or wait
until you get back?
--
Phil Holmes
- Original Message -
From: percival.music...@gmail.com
To: philehol...@googlemail.com; m...@philholmes.net;
gra...@percival-music.ca; em...@philholmes.net
Cc:
Reviewers: ,
Message:
I can already see that this may lead to circular dependencies, but
(miraculously) it passes the regtests and actually improves all but one
collision, whose results were bad before and are worse now (it squashes
the beam into a notehead).
Obviously, this patch is rather
Hello,
I'm looking at tidying up some parts of this in the NR (not changing anything
technically) and would like a clarification on something.
We state:
--snip--
The \makeStringTuning function is used to create a string tuning
without setting the stringTunings property in the current
On 5/5/11 10:46 AM, James Lowe james.l...@datacore.com wrote:
Hello,
I'm looking at tidying up some parts of this in the NR (not changing anything
technically) and would like a clarification on something.
We state:
--snip--
The \makeStringTuning function is used to create a string
2011/5/4 Francisco Vila paconet@gmail.com:
2011/5/3 Carl Sorensen c_soren...@byu.edu:
On 5/3/11 5:45 AM, Francisco Vila paconet@gmail.com wrote:
2011/5/3 Francisco Vila paconet@gmail.com:
Hello, I have noticed that master is now 2.15; we on the
lilypond/translation branch have
On 2011/05/05 16:30:28, MikeSol wrote:
(a) People to confirm that the circular dependency I fear (beam
placement
relying on rest placement relying on beam placement relying on...)
does not
exist.
Did you do a regtest run with an unoptimised binary?
I get cyclic dependency errors in three
On 2011/05/05 20:44:36, Neil Puttock wrote:
On 2011/05/05 16:30:28, MikeSol wrote:
(a) People to confirm that the circular dependency I fear (beam
placement
relying on rest placement relying on beam placement relying on...)
does not
exist.
Did you do a regtest run with an
An update to use lists rather than strings.
http://codereview.appspot.com/4428077/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
http://codereview.appspot.com/4428077/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On May 5, 2011, at 1:50 PM, n.putt...@gmail.com wrote:
On 2011/05/05 20:44:36, Neil Puttock wrote:
On 2011/05/05 16:30:28, MikeSol wrote:
(a) People to confirm that the circular dependency I fear (beam
placement
relying on rest placement relying on beam placement relying on...)
does not
On Thu, May 5, 2011 at 5:44 PM, n.putt...@gmail.com wrote:
Did you do a regtest run with an unoptimised binary?
I get cyclic dependency errors in three tests. Here's an example from
beam-collision-basic.ly:
we should add a note to always use the unoptimized debug binary for
the regtests.
13 matches
Mail list logo
