Original Message
> Only unnecessary lengthening now is some stems on
> cue notes, but it really sticks out.
Well, as they say, "pictures or it didn't happen" The cue from the
trumpets looks desperate for attention.
> I could only reduce it to four
> required ingredients: manu
I only re-checked that one score, after the patch to overcome the
autobeam confusion. Only unnecessary lengthening now is some stems on
cue notes, but it really sticks out. I could only reduce it to four
required ingredients: manual beams, 32nd notes, dots, and CueVoice.
\music = \relative c'' {
http://codereview.appspot.com/3934041/diff/2001/lily/note-collision.cc
File lily/note-collision.cc (right):
http://codereview.appspot.com/3934041/diff/2001/lily/note-collision.cc#newcode276
lily/note-collision.cc:276: // magic numbers...
already been said, referring to this block. I wanted assu
LGTM.
Carl
http://codereview.appspot.com/3934041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
New patches pushed.
Thanks,
Carl
http://codereview.appspot.com/3928041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
New patch set that moves the stem up - regtests check out OK.http://codereview.appspot.com/3934041/For some reason, the side-by-side diffs don't work for the last file, but as you'll see in the unified diff, the change is trivial.Attached is a PDF of the regtest I created for this patch.Cheers,MS
Done - attached is a fresh patch set. The first three are what's already on
Rietveld, and the 4th is Carl's formatting & copyright changes.
Cheers,
MS
0004-Changes-suggested-by-Carl.patch
Description: Binary data
0003-Intermediary-37-patch.patch
Description: Binary data
0002-Fixes-formatti
LGTM.
Don't forget to fix your copyright on beam-collision-engraver.
One set of braces to be removed.
Thanks,
Carl
http://codereview.appspot.com/3928041/diff/17001/lily/beam-collision-engraver.cc
File lily/beam-collision-engraver.cc (right):
http://codereview.appspot.com/3928041/diff/17001
Latest patch set uploaded with full side-by-side-diffs.
Thanks,
Carl
http://codereview.appspot.com/3928041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Hey Keith,
I believe the new patch set fixes that problem.
Cheers,
MS
On Jan 8, 2011, at 9:01 PM, Keith OHara wrote:
> Mike,
> I like it on small scores.
>
> I let your patch compile a symphony and got several unneeded stem
> lengthenings per page. I started carving out a reasonable-sized .l
Mike,
I like it on small scores.
I let your patch compile a symphony and got several unneeded stem
lengthenings per page. I started carving out a reasonable-sized .ly to
send for you to test, but that might actually take longer than you
recognizing the problem from the output. Three images at
On 1/8/11 5:41 PM, "Mike Solomon" wrote:
> Following Carl's advice, I ran a make-check and got the following issue:
>
> command failed: /Users/mikesolomon/devel/lilypond/out/bin/lilypond -I ./ -I
> ./out-test -I ../../input -I /Users/mikesolomon/devel/lilypond/Documentation
> -I /Users/mikesolom
Following Carl's advice, I ran a make-check and got the following issue:
command failed: /Users/mikesolomon/devel/lilypond/out/bin/lilypond -I ./ -I
./out-test -I ../../input -I /Users/mikesolomon/devel/lilypond/Documentation -I
/Users/mikesolomon/devel/lilypond/Documentation/snippets -I
../../
> And now for something completely different: when looking at those
> examples, I thought that it might be nice if beam slope was actually
> based on physical pitch rather than note position, so that something
> like f-fis gets slope, and something like eis-f doesn't.
Yes, this would be very help
> Attached is a leaner and meaner patch that requires no other patches
> (it bases off of the master) and implements this.
Very nice!
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-dev
Konstantin,
A proof of concept piece of software would take me more time than I currently
have. I can, however, try to put something together that shows how info is
passed together in Lilypond, and will do so over the next week.
Cheers,
MS
On Jan 8, 2011, at 6:30 PM, Konstantin wrote:
> Hell
Hello Mike,
it would be very helpful to me if you could make a proof of concept piece of
software. I speak only english (Java/C++) and no chinese (Lilypond/Scheme) ;-)
Regards,
Konstantin
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://
Patch set relative to current head,
and one typo fixed in an output message.
Email patch to follow shortly to Graham.
Carl wrote> ... git-cl upload master
Thanks, Carl.
I committed locally first, so relative to my local this gave an empty
diff. git-cl upload origin/master
So I see that Rietveld
LGTM.
http://codereview.appspot.com/3793046/diff/6001/python/convertrules.py
File python/convertrules.py (right):
http://codereview.appspot.com/3793046/diff/6001/python/convertrules.py#newcode2970
python/convertrules.py:2970: r" top-system-spacing #'space = #(/
obsolete-\1 staff-space)",
newli
On 8 January 2011 21:55, wrote:
> Testing might require a (trivial) merge with Carl's "Change
> stringTunings ..." commit. I have a merged patch but hesitate to upload
> because I haven't yet seen how Rietveld displays such patches. If I get
> bold, but make a mess with Set 3, just look at Patc
On 2011/01/08 17:53:54, Neil Puttock wrote:
Do you mind holding fire until I've had chance to look at it?
Holding fire.
Testing might require a (trivial) merge with Carl's "Change
stringTunings ..." commit. I have a merged patch but hesitate to upload
because I haven't yet seen how Rietveld dis
On Sat, 08 Jan 2011 06:19:16 -0800, Carl Sorensen wrote:
On Fri, 07 Jan 2011 15:50:40 -0800, Carl Sorensen wrote:
A default value of skyline-horizontal-padding of 1.2 gets
skyline-horizontal-padding.ly to work well.
An override to System 'skyline-horizontal-padding = #0 in
stem-length-estima
On 1/8/11 12:48 PM, "Mike Solomon" wrote:
> All is fixed. Attached is the original patch plus one with Carl's suggested
> formatting changes.
>
> I ran all of the regtests and nothing breaks.
>
> I'd like one other person to test these patches out w/ the attached .ly
> document to confirm. Th
On 1/8/11 12:52 PM, "Neil Puttock" wrote:
> On 8 January 2011 19:48, Mike Solomon wrote:
>
>> I ran all of the regtests and nothing breaks.
>
> This is not good enough.
>
> You *must* do a proper regression test comparison.
As defined in the CG, this means:
Run
make test-baseline
bef
On 1/8/11 12:51 PM, "David Kastrup" wrote:
> Mike Solomon writes:
>
>> All is fixed. Attached is the original patch plus one with Carl's
>> suggested formatting changes.
>>
>> I ran all of the regtests and nothing breaks.
>>
>> I'd like one other person to test these patches out w/ the at
On 1/8/11 12:48 PM, "Mike Solomon" wrote:
> All is fixed. Attached is the original patch plus one with Carl's suggested
> formatting changes.
>
Latest patch is posted on Rietveld, as
http://codereview.appspot.com/3928041/
Thanks,
Carl
___
li
On 8 January 2011 19:48, Mike Solomon wrote:
> I ran all of the regtests and nothing breaks.
This is not good enough.
You *must* do a proper regression test comparison.
Withough doing make check, I can already see it will fail since you
haven't documented covering-note-heads in beam.cc and
def
Mike Solomon writes:
> All is fixed. Attached is the original patch plus one with Carl's
> suggested formatting changes.
>
> I ran all of the regtests and nothing breaks.
>
> I'd like one other person to test these patches out w/ the attached
> .ly document to confirm. Then, if there are no oth
All is fixed. Attached is the original patch plus one with Carl's suggested
formatting changes.
I ran all of the regtests and nothing breaks.
I'd like one other person to test these patches out w/ the attached .ly
document to confirm. Then, if there are no other other comments, please push
t
Carl,
Thanks for the comments!
I've integrated all but one of them - when you say "Also add to TabStaff," what
do you mean? I was under the impression that TabStaff would inherit this
engraver because it inherits from Staff.
Cheers,
MS
On Jan 8, 2011, at 1:38 PM, carl.d.soren...@gmail.com wro
Carl,
Thanks for the comments!
I've integrated all but one of them - when you say "Also add to TabStaff," what
do you mean? I was under the impression that TabStaff would inherit this
engraver because it inherits from Staff.
Cheers,
MS
On Jan 8, 2011, at 1:38 PM, carl.d.soren...@gmail.com wro
On Sat, Jan 08, 2011 at 05:53:51PM +, Neil Puttock wrote:
> On 8 January 2011 05:47, wrote:
> > Looks fine, although I haven't actually tested it, but since it's not in
> > the core program I'm less concerned. Could you email me the git patch
> > and I'll push it?
>
> Do you mind holding fi
Reviewers: MikeSol,
Message:
Looks great, Mike!
You have some code indentation issues that don't match our style. Other
than that, I think it's good to go.
Of course, we do need a regression test as well.
Thanks,
Carl
http://codereview.appspot.com/3928041/diff/1/lily/beam-collision-engrav
On 1/8/11 11:02 AM, "Mike Solomon" wrote:
> Not a problem.
> Attached is a leaner and meaner patch that requires no other patches (it bases
> off of the master) and implements this.
> I've compiled all of the regtests and it breaks none of them. And, after
> briefly perusing the output, I don
Mike Solomon writes:
> Not a problem.
> Attached is a leaner and meaner patch that requires no other patches
> (it bases off of the master) and implements this.
> I've compiled all of the regtests and it breaks none of them. And,
> after briefly perusing the output, I don't think it drastically
On 8 January 2011 05:47, wrote:
> Looks fine, although I haven't actually tested it, but since it's not in
> the core program I'm less concerned. Could you email me the git patch
> and I'll push it?
Do you mind holding fire until I've had chance to look at it?
Cheers,
Neil
___
2011/1/8 Werner LEMBERG :
> BTW, has someone done some research in trying to find printed,
> well-engraved examples?
I've only got one off the top of my head, the final example on this page:
http://www.musicbyandrew.ca/finale-lilypond-2.html
It's only one data point, but it does argue in favour o
> "Karl" == Karl Hammar writes:
Karl> On line 22 in the ly-file:
Karl> %% Accidentals are valid only once (same as
Karl> Shouldn't the accidental be valid for the next note and any same
Karl> repeted note, this has bothered me with the current white mesural
Karl>
On 1/7/11 9:16 PM, "Keith OHara" wrote:
> On Fri, 07 Jan 2011 15:50:40 -0800, Carl Sorensen wrote:
>>
>> A default value of skyline-horizontal-padding of 1.2 gets
>> skyline-horizontal-padding.ly to work well.
>>
>> An override to System 'skyline-horizontal-padding = #0 in
>> stem-length-estim
Werner LEMBERG writes:
>>> I'm not sure whether using the `natural' angle is really that good
>>> – we are entering quite complicated formatting issues... Perhaps
>>> applying a damping factor to make the beams less steep?
>>
>> I think the usual beam slope calculation (which involves dampening
>> I'm not sure whether using the `natural' angle is really that good
>> $(Q#|(B we are entering quite complicated formatting issues... Perhaps
>> applying a damping factor to make the beams less steep?
>
> I think the usual beam slope calculation (which involves dampening)
> should be more or
Werner LEMBERG writes:
I'm not exactly sure what the desired output would be for issue
37, but my code assumes that if there are collision problems, flat
beams look best.
>>> +1
>>
>> Don't agree: the beams usually give an impression of the overall
>> pitch tendency. Flat beams o
>>> I'm not exactly sure what the desired output would be for issue
>>> 37, but my code assumes that if there are collision problems, flat
>>> beams look best.
>> +1
>
> Don't agree: the beams usually give an impression of the overall
> pitch tendency. Flat beams over a rising melody line look st
>> Good idea! I have to figure out the centering issues and how to convert
>> SCM to Interval, but this is a nice way.
>
> robust_scm2interval
thanks. I made the bare changes, it was quite straightforward after
all these exchanges; now comes convert-ly and the regtests.
I guess it will take much
Mike Solomon writes:
> Forgot the test I ran...
Lines 2 and 10 appear to have beams touching notes. Perhaps the slanted
beams occupy more vertical space than the straight ones?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.or
"Keith OHara" writes:
> Original Message
>> From: "Carl Sorensen"
>> Sent: Friday, January 07, 2011 3:28 PM
>
>>
>> I was hoping that by setting the default, we'd get good spacing and we
>> wouldn't need the override.
>>
>
> I hadn't seen this exchange when I commented on the
46 matches
Mail list logo
