http://codereview.appspot.com/5626052/diff/114002/lily/skyline.cc
File lily/skyline.cc (right):
http://codereview.appspot.com/5626052/diff/114002/lily/skyline.cc#newcode111
lily/skyline.cc:111: if (start_height != end_height)
Does anyone know the reason for this change?
For some unusual input
On 29 août 2012, at 06:18, Keith OHara k-ohara5...@oco.net wrote:
On Tue, 28 Aug 2012 01:00:39 -0700, m...@mikesolomon.org
m...@mikesolomon.org wrote:
On 28 août 2012, at 06:08, k-ohara5...@oco.net wrote:
\override Accidental #'vertical-skylines = #'()
...
(you should set them to
On 28 août 2012, at 06:08, k-ohara5...@oco.net wrote:
Still works well, still the same speed, and now the code makes much more
sense.
The 25% extra time required to set a short score goes down if I
\override Accidental #'vertical-skylines = #'()
\override TextScript
m...@mikesolomon.org m...@mikesolomon.org writes:
On 28 août 2012, at 06:08, k-ohara5...@oco.net wrote:
Still works well, still the same speed, and now the code makes much more
sense.
The 25% extra time required to set a short score goes down if I
\override Accidental
On Tue, 28 Aug 2012 01:00:39 -0700, m...@mikesolomon.org m...@mikesolomon.org
wrote:
On 28 août 2012, at 06:08, k-ohara5...@oco.net wrote:
\override Accidental #'vertical-skylines = #'()
...
(you should set them to ly:grob::simple-vertical-skylines-from-stencil instead
of '()).
Still works well, still the same speed, and now the code makes much more
sense.
The 25% extra time required to set a short score goes down if I
\override Accidental #'vertical-skylines = #'()
\override TextScript #'vertical-skylines = #'()
\override TextScript #'horizontal-skylines =
On 2012/08/17 19:25:29, Keith wrote:
On Fri, 17 Aug 2012 10:16:25 -0700, mailto:mts...@gmail.com wrote:
http://codereview.appspot.com/5626052/diff/106004/lily/axis-group-interface.cc#newcode780
lily/axis-group-interface.cc:780: while (dirty);
On 2012/08/17 08:12:56, Keith wrote:
I am
On 2012/08/18 10:12:00, MikeSol wrote:
Agreed. I'd love for this to go faster.
The goal is not speed, but comprehensibility of code.
The code is much shorter with direct use of distance() so there is less
for the human reader to hold in his head.
There was, however, no measurable
On 2012/08/21 07:32:15, Keith wrote:
There was, however, no measurable difference in speed on my
piano-music test case.
at least, no speed difference from my attempt at simplification
http://codereview.appspot.com/6462087/
I haven't tried Joe's.
On 2012/08/18 10:12:00, MikeSol wrote:
\relative c'' {
\override TupletBracket #'outside-staff-priority = #1
\override TupletNumber #'font-size = #5
\times 2/3 { a4\trill a\trill^foo a\trill }
}
I added this as a regtest. If you comment out the rider business,
you'll see that
On 21 août 2012, at 03:42, k-ohara5...@oco.net wrote:
On 2012/08/18 10:12:00, MikeSol wrote:
\relative c'' {
\override TupletBracket #'outside-staff-priority = #1
\override TupletNumber #'font-size = #5
\times 2/3 { a4\trill a\trill^foo a\trill }
}
I added this as a regtest.
On 2012/08/21 07:42:38, Keith wrote:
On 2012/08/18 10:12:00, MikeSol wrote:
\relative c'' {
\override TupletBracket #'outside-staff-priority = #1
\override TupletNumber #'font-size = #5
\times 2/3 { a4\trill a\trill^foo a\trill }
}
I added this as a regtest. If you comment
Works nice.
But so far the density of problems in the code as been pretty high.
These problems seem to be in corner cases for which the code is
(unnecessarily?) complex. It is not clear why the _use_ of skylines has
to change so much at the same time as the _shapes_ of skylines change.
Maybe
On Tue, 21 Aug 2012 20:43:03 -0700, joenee...@gmail.com wrote:
Have you tried setting TupletNumber's priority to be smaller than
TupletBracket? It results TupletNumber moving twice as far as it should
That is a problem with the simple code.
What is the desired output, though, if someone
Thanks for the performance tests! I have no problem changing the
function avoid_outside_staff_collisions to be faster - it's just that I
haven't wrapped my head around how distance alone can do it.
http://codereview.appspot.com/5626052/diff/106004/lily/axis-group-interface.cc
File
patch
real17m55.095s
user17m10.848s
sys 0m11.381s
git master
real16m16.228s
user15m30.543s
sys 0m10.624s
http://codereview.appspot.com/5626052/diff/106004/lily/axis-group-interface.cc
File lily/axis-group-interface.cc (right):
http://codereview.appspot.com/5626052/diff/106004/lily/axis-group-interface.cc
File lily/axis-group-interface.cc (right):
http://codereview.appspot.com/5626052/diff/106004/lily/axis-group-interface.cc#newcode651
lily/axis-group-interface.cc:651: ---/
I've
On 17 août 2012, at 07:19, joenee...@gmail.com wrote:http://codereview.appspot.com/5626052/diff/106004/lily/axis-group-interface.ccFile lily/axis-group-interface.cc (right):http://codereview.appspot.com/5626052/diff/106004/lily/axis-group-interface.cc#newcode651lily/axis-group-interface.cc:651:
On 17 août 2012, at 10:21, m...@mikesolomon.org m...@mikesolomon.org wrote:
On 17 août 2012, at 07:19, joenee...@gmail.com wrote:
http://codereview.appspot.com/5626052/diff/106004/lily/axis-group-interface.cc
File lily/axis-group-interface.cc (right):
I've forgotten why I added the horizontal skyline stuff so I've taken it
out in a new version that I'll post after regtests.
http://codereview.appspot.com/5626052/diff/106004/lily/axis-group-interface.cc
File lily/axis-group-interface.cc (right):
On Fri, 17 Aug 2012 10:16:25 -0700, mts...@gmail.com wrote:
http://codereview.appspot.com/5626052/diff/106004/lily/axis-group-interface.cc#newcode780
lily/axis-group-interface.cc:780: while (dirty);
On 2012/08/17 08:12:56, Keith wrote:
I am beginning to understand the new code. Would you
On Sat, Aug 18, 2012 at 5:34 AM, Keith OHara k-ohara5...@oco.net wrote:
On Fri, 17 Aug 2012 10:16:25 -0700, mts...@gmail.com wrote:
http://codereview.appspot.com/**5626052/diff/106004/lily/axis-**
On 17 août 2012, at 16:57, Joe Neeman joenee...@gmail.com wrote:
On Sat, Aug 18, 2012 at 5:34 AM, Keith OHara k-ohara5...@oco.net wrote:
On Fri, 17 Aug 2012 10:16:25 -0700, mts...@gmail.com wrote:
http://codereview.appspot.com/5626052/diff/106004/lily/axis-group-interface.cc#newcode780
Joe Neeman joeneeman at gmail.com writes:
We need not let the distance function between A[UP] and B[DOWN] dictate,
because having positive distance between A[DOWN] and B[UP] is another
solution.
If you check out the dev/jneem-skylines (which is a simplified but not (yet)
This is barely slower than master on an orchestral score and parts
patch master
real16m16.228sreal 15m54.212s
user15m30.543suser 15m5.920s
sys 0m10.624s sys 0m10.649s
but piano music (Chopin op45) takes 25% longer
real
http://codereview.appspot.com/5626052/diff/105001/lily/axis-group-interface.cc
File lily/axis-group-interface.cc (right):
http://codereview.appspot.com/5626052/diff/105001/lily/axis-group-interface.cc#newcode778
lily/axis-group-interface.cc:778: Note we only use 75% of padding and
apply the
Thanks for the review!
http://codereview.appspot.com/5626052/diff/105001/input/regression/text-script-vertical-skylines.ly
File input/regression/text-script-vertical-skylines.ly (right):
Worked nicely on some piano music and a Dvorak symphony.
The code is bewildering. So far I've mostly read the comments.
The bit with the activation-factor is pretty ugly.
What was the size of the problem ? Did the script that should have fit
lack space of padding, 0.5*padding, or epsilon ?
On Sat, Jul 14, 2012 at 8:33 PM, mts...@gmail.com wrote:
http://codereview.appspot.com/**5626052/diff/85004/lily/**
skyline.cc#newcode302http://codereview.appspot.com/5626052/diff/85004/lily/skyline.cc#newcode302
lily/skyline.cc:302: while (dirty);
On 2012/07/14 14:01:08, joeneeman wrote:
I actually only wanted to get rid of the whitespace errors plagueing
every test of this patch, but one programming error jumped out so badly
at me that I had to flag it as well.
http://codereview.appspot.com/5626052/diff/79059/lily/axis-group-interface.cc
File lily/axis-group-interface.cc
On 4 juil. 2012, at 21:58, Janek Warchoł wrote:
On Wed, Jul 4, 2012 at 3:36 PM, m...@apollinemike.com
m...@apollinemike.com wrote:
No idea when i'll have time to finish Tie Report, but as tie shapes
are screwed in general, i wouldn't care much about this change. New
shape isn't worse than
On Thu, Jul 5, 2012 at 5:23 PM, m...@apollinemike.com
m...@apollinemike.com wrote:
New patch set up that fixes all of the problems Janek pointed out
I confirm, but the fun doesn't end yet :P
\relative f' { c4( d e f) g1 }
\addlyrics { bl lah }
\relative f'' { c4( b a g) f1 }
\addlyrics {
On Mon, Jul 2, 2012 at 1:03 AM, k-ohara5...@oco.net wrote:
I did a quick test on some music. http://k-ohara.oco.net/Lilypond/
Ledger lines might not be getting the space they need. In rare cases,
all the systems were overlaid on the top of the page. Several objects
might need an increase
On 3 juil. 2012, at 10:18, Janek Warchoł wrote:
Hi all,
my favorite patch returned! Yay!
I did some testing and the results are here:
http://lilypond-stuff.1065243.n5.nabble.com/file/n5705594/patchset37-results.tar.gz
Thanks Janek! Very valuable stuff.
(sorry, too big for an attachment
On Wed, Jul 4, 2012 at 11:31 AM, m...@apollinemike.com
m...@apollinemike.com wrote:
Thanks Janek! Very valuable stuff.
:)
(sorry, too big for an attachment - 200 kB)
In short:
- staffswitch lines are broken
This is because VoiceFollower is not set as (cross-staff . #t) in
On 4 juil. 2012, at 15:17, Janek Warchoł wrote:
On Wed, Jul 4, 2012 at 11:31 AM, m...@apollinemike.com
m...@apollinemike.com wrote:
Thanks Janek! Very valuable stuff.
:)
(sorry, too big for an attachment - 200 kB)
In short:
- staffswitch lines are broken
This is because
- Original Message -
From: m...@apollinemike.com
To: Janek Warchoł janek.lilyp...@gmail.com
In short:
- staffswitch lines are broken
This is because VoiceFollower is not set as (cross-staff . #t) in
define-grobs.scm. I'm not sure why...this seems like a good idea
irrespective of
On Wed, Jul 4, 2012 at 3:36 PM, m...@apollinemike.com
m...@apollinemike.com wrote:
No idea when i'll have time to finish Tie Report, but as tie shapes
are screwed in general, i wouldn't care much about this change. New
shape isn't worse than previous one, i'd say.
I think that there's
Hi all,
my favorite patch returned! Yay!
I did some testing and the results are here:
http://lilypond-stuff.1065243.n5.nabble.com/file/n5705594/patchset37-results.tar.gz
(sorry, too big for an attachment - 200 kB)
In short:
- staffswitch lines are broken
- barnumbers collide with ties
- some
On 2 juil. 2012, at 01:03, k-ohara5...@oco.net wrote:
I like the direction in which this goes, making things closer, because
it is easier for users to add padding when needed than to persuade
LilyPond to space things more closely.
I did a quick test on some music.
On Tue, 03 Jul 2012 10:51:05 -0700, m...@apollinemike.com
m...@apollinemike.com wrote:
Could you tell me the page and the document where the system overlay happens?
Second page of the bassoon part.
http://k-ohara.oco.net/Lilypond/TightSkylines/woods-Bassoon1.pdf
The source is one directory
It's back...
The only thing that doesn't the work the way I'd expect it is
Skyline::padded. It seems to not be adding the padding correctly (Joe -
any ideas)? This causes tighter than desired spacing in
alignment-order.ly. Other than that it is all reviewable! For those
who were keeping
mts...@gmail.com writes:
It's back...
The only thing that doesn't the work the way I'd expect it is
Skyline::padded. It seems to not be adding the padding correctly (Joe -
any ideas)? This causes tighter than desired spacing in
alignment-order.ly. Other than that it is all reviewable!
On 1 juil. 2012, at 17:08, David Kastrup wrote:
mts...@gmail.com writes:
It's back...
The only thing that doesn't the work the way I'd expect it is
Skyline::padded. It seems to not be adding the padding correctly (Joe -
any ideas)? This causes tighter than desired spacing in
I like the direction in which this goes, making things closer, because
it is easier for users to add padding when needed than to persuade
LilyPond to space things more closely.
I did a quick test on some music. http://k-ohara.oco.net/Lilypond/
Ledger lines might not be getting the space they
http://codereview.appspot.com/5626052/diff/78001/lily/skyline.cc
File lily/skyline.cc (right):
http://codereview.appspot.com/5626052/diff/78001/lily/skyline.cc#newcode693
lily/skyline.cc:693: Skyline::padded (Real horizon_padding) const
The horizon_padding built in to Skyline::Skyline had nice
http://codereview.appspot.com/5626052/diff/78001/lily/skyline.cc
File lily/skyline.cc (right):
http://codereview.appspot.com/5626052/diff/78001/lily/skyline.cc#newcode693
lily/skyline.cc:693: Skyline::padded (Real horizon_padding) const
On 2012/07/01 23:04:17, Keith wrote:
The horizon_padding
Hey all,
An update on this patch.
After having correctly skylined dynamics, I'm realizing that serifed fonts and
italicized fonts are posing a problem for snug vertical alignment. Joe and I
have been back and forth about a solution and he has graciously accepted to
tag-team the problem with
2012/3/6 Janek Warchoł janek.lilyp...@gmail.com
On Tue, Mar 6, 2012 at 11:48 PM, Joe Neeman joenee...@gmail.com wrote:
2012/3/6 janek.lilyp...@gmail.com
Mike all,
i did a quick compile with patchset 36 and unfortunately didn't notice
significant speedups from previous version.
2012/3/7 Janek Warchoł janek.lilyp...@gmail.com
On Wed, Mar 7, 2012 at 11:43 AM, Joe Neeman joenee...@gmail.com wrote:
2012/3/6 Janek Warchoł janek.lilyp...@gmail.com
Actually, small/zero horizontal padding might give better results in
some places, but that needs thorough investigation.
On Wed, Mar 7, 2012 at 10:50 PM, Joe Neeman joenee...@gmail.com wrote:
2012/3/7 Janek Warchoł janek.lilyp...@gmail.com
On Wed, Mar 7, 2012 at 11:43 AM, Joe Neeman joenee...@gmail.com wrote:
2012/3/6 Janek Warchoł janek.lilyp...@gmail.com
Actually, small/zero horizontal padding might give
Mike all,
i did a quick compile with patchset 36 and unfortunately didn't notice
significant speedups from previous version.
Compilation time differences vary widely depending on music (from 5% to
100% longer)
PROCESSING ../dynamics.ly WITH MASTER: --
real0m0.762s
user
2012/3/6 janek.lilyp...@gmail.com
Mike all,
i did a quick compile with patchset 36 and unfortunately didn't notice
significant speedups from previous version.
Could you try the dev/jneem branch in git? It has some optimizations. If
that doesn't help, could you please send me some of the
On Tue, Mar 6, 2012 at 11:48 PM, Joe Neeman joenee...@gmail.com wrote:
2012/3/6 janek.lilyp...@gmail.com
Mike all,
i did a quick compile with patchset 36 and unfortunately didn't notice
significant speedups from previous version.
Could you try the dev/jneem branch in git? It has some
On Fri, Mar 2, 2012 at 7:38 AM, m...@apollinemike.com
m...@apollinemike.com wrote:
Not a prob, Janek, and thank you _very_ much for your help.
You've put as much time as I have into this thing, and I couldn't
have gotten it to where it is w/o your feedback.
Thanks! :)
Janek
I couldn't resist the temptation of compiling new patchset.
Here are the compilation times i've got (no time to check how output
looks like, though):
PROCESSING ../dynamics.ly WITH MASTER: --
real0m0.732s
PROCESSING ../dynamics.ly WITH SKYLINES:
real0m0.787s
From what i see, the skylines are now more precise than they need to
be - every glyph has a skyline of 10 or so boxes, even if it's a
single letter! (see attached)
I second this.
I think the proper solution would be to:
a) set minimal step size to 0.2 staffspace (or more in case of
bigger
2012/3/1 Janek Warchoł janek.lilyp...@gmail.com:
From what i see, the skylines are now more precise than they need to
be - every glyph has a skyline of 10 or so boxes, even if it's a
single letter! (see attached)
I think the proper solution would be to:
a) set minimal step size to 0.2
Han-Wen Nienhuys hanw...@gmail.com writes:
2012/3/1 Janek Warchoł janek.lilyp...@gmail.com:
From what i see, the skylines are now more precise than they need to
be - every glyph has a skyline of 10 or so boxes, even if it's a
single letter! (see attached)
I think the proper solution would
On Thu, Mar 1, 2012 at 7:57 AM, David Kastrup d...@gnu.org wrote:
From what i see, the skylines are now more precise than they need to
be - every glyph has a skyline of 10 or so boxes, even if it's a
single letter! (see attached)
I think the proper solution would be to:
a) set minimal step
On Mar 1, 2012, at 11:52 AM, Han-Wen Nienhuys wrote:
2012/3/1 Janek Warchoł janek.lilyp...@gmail.com:
From what i see, the skylines are now more precise than they need to
be - every glyph has a skyline of 10 or so boxes, even if it's a
single letter! (see attached)
I think the proper
Han-Wen Nienhuys hanw...@gmail.com writes:
On Thu, Mar 1, 2012 at 7:57 AM, David Kastrup d...@gnu.org wrote:
From what i see, the skylines are now more precise than they need to
be - every glyph has a skyline of 10 or so boxes, even if it's a
single letter! (see attached)
I think the proper
Janek Warchoł wrote Thursday, March 01, 2012 12:01 AM
The bad news is that for scores containing a lot of lyrics (like my
SATB pieces) compilation times are now 3-4 times longer than wiith
master. For instrumental scores the situation look better, it's 1.5-2
times longer. I can live with
On Thu, Mar 1, 2012 at 8:01 AM, David Kastrup d...@gnu.org wrote:
Han-Wen Nienhuys hanw...@gmail.com writes:
2012/3/1 Janek Warchoł janek.lilyp...@gmail.com:
From what i see, the skylines are now more precise than they need to
be - every glyph has a skyline of 10 or so boxes, even if it's a
On Mar 1, 2012, at 12:17 PM, Trevor Daniels wrote:
Janek Warchoł wrote Thursday, March 01, 2012 12:01 AM
The bad news is that for scores containing a lot of lyrics (like my
SATB pieces) compilation times are now 3-4 times longer than wiith
master. For instrumental scores the situation
On Mar 1, 2012, at 12:23 PM, Han-Wen Nienhuys wrote:
Well, perhaps there is another method. I just want to point out that
it is a waste to represent the extent of the letter 'n' with 10 boxes,
and we should be able to do better.
I agree that it's excessive. To me, do better means
On Thu, Mar 1, 2012 at 12:00 PM, m...@apollinemike.com
m...@apollinemike.com wrote:
On Mar 1, 2012, at 11:52 AM, Han-Wen Nienhuys wrote:
It's neat that you are generating such precise skylines, but can you
show places where this makes an appreciable difference for texts?
Janek had sent out a
As for compilation times with patchset 32, SATB choral files compile
two times longer than master, and instrumentals 1.0-1.5 times longer
than master.
Mike, i am very sorry but i have to pause my involvement in this issue
a bit. I'm very short on time and testing takes a lot of time :/
cheers,
On Mar 2, 2012, at 6:28 AM, Janek Warchoł wrote:
As for compilation times with patchset 32, SATB choral files compile
two times longer than master, and instrumentals 1.0-1.5 times longer
than master.
Mike, i am very sorry but i have to pause my involvement in this issue
a bit. I'm very
On Feb 29, 2012, at 2:05 AM, Joe Neeman wrote:
On Tue, Feb 28, 2012 at 1:32 PM, m...@apollinemike.com
m...@apollinemike.com wrote:
Hey all,
I've put up a new version that doesn't issue warnings.
Any change of getting an updated git branch, too?
Done.
A lot of the too-close-spacing
Hey Mike,
I did a quick check of newest patchset (30) and the results look
great! There are some flaws, but i'd say they're not your patch's
fault. Rather, it seems that the new super-precise skylines unveil
imperfections in vertical spacing code.
The bad news is that for scores containing a
On Mar 1, 2012, at 1:01 AM, Janek Warchoł wrote:
Hey Mike,
I did a quick check of newest patchset (30) and the results look
great! There are some flaws, but i'd say they're not your patch's
fault. Rather, it seems that the new super-precise skylines unveil
imperfections in vertical
On Thu, Mar 1, 2012 at 8:14 AM, m...@apollinemike.com
m...@apollinemike.com wrote:
On Mar 1, 2012, at 1:01 AM, Janek Warchoł wrote:
I did a quick check of newest patchset (30) and the results look
great! There are some flaws, but i'd say they're not your patch's
fault. Rather, it seems that
Hey all,
I have a new patch up that simplifies the old one a great deal and uses
freetype to get outlines.
The only problem with it (that I know of) exists for some non-standard fonts.
If you run input/regression/utf-8.ly through this, you'll see LilyPond get very
angry about not being able
Hey all,
I've put up a new version that doesn't issue warnings.
The only problem I'm running into now is that the outlines aren't always 100%
exact. This causes really close kerning and sometimes even overlap (check out
figured-bass-implicit.ly). An easy (albeit kludgy) solution would be to
On Tue, Feb 28, 2012 at 1:32 PM, m...@apollinemike.com
m...@apollinemike.com wrote:
Hey all,
I've put up a new version that doesn't issue warnings.
Any change of getting an updated git branch, too?
___
lilypond-devel mailing list
On Fri, Feb 24, 2012 at 12:50 AM, m...@apollinemike.com
m...@apollinemike.com wrote:
On Feb 24, 2012, at 12:07 AM, Janek Warchoł wrote:
dynamic texts aren't skylined, their outlines are still rectangles.
The issue is that dynamics are created via Pango and thus I can only use
rectangles
for
On Feb 26, 2012, at 1:08 PM, Janek Warchoł wrote:
On Fri, Feb 24, 2012 at 12:50 AM, m...@apollinemike.com
m...@apollinemike.com wrote:
On Feb 24, 2012, at 12:07 AM, Janek Warchoł wrote:
dynamic texts aren't skylined, their outlines are still rectangles.
The issue is that dynamics are
m...@apollinemike.com m...@apollinemike.com writes:
On Feb 26, 2012, at 1:08 PM, Janek Warchoł wrote:
On Fri, Feb 24, 2012 at 12:50 AM, m...@apollinemike.com
m...@apollinemike.com wrote:
On Feb 24, 2012, at 12:07 AM, Janek Warchoł wrote:
dynamic texts aren't skylined, their outlines are
should we rather try to break inside Pango to be able to create
precise outlines for everything that is processed by Pango? The
advantage of this approach would be that lyrics and markups would
be skylined even better.
The reason we are using Pango in the first place is because it is
On Feb 26, 2012, at 7:37 PM, Werner LEMBERG wrote:
AFAIK, Pango returns a list of glyph indices and coordinates to
position glyphs. It's straightforward to feed those indices directly
into FreeType's `FT_Load_Glyph' function which is able to return an
`FT_Outline' structure holding the
On Sun, Feb 26, 2012 at 11:25 AM, m...@apollinemike.com
m...@apollinemike.com wrote:
On Feb 26, 2012, at 7:37 PM, Werner LEMBERG wrote:
AFAIK, Pango returns a list of glyph indices and coordinates to
position glyphs. It's straightforward to feed those indices directly
into FreeType's
On Sun, Feb 26, 2012 at 8:25 PM, m...@apollinemike.com
m...@apollinemike.com wrote:
On Feb 26, 2012, at 7:37 PM, Werner LEMBERG wrote:
AFAIK, Pango returns a list of glyph indices and coordinates to
position glyphs. It's straightforward to feed those indices directly
into FreeType's
Hey all,
The newest patch set implements several of Joe's suggestions but takes a time
hit because I am using the fancy skylines for Scripts. This makes
script-accidental-collision.ly look better (as well as a few other regtests)
but it slows things down even more.
I think that the coding is
On Thu, Feb 23, 2012 at 1:35 AM, m...@apollinemike.com
m...@apollinemike.com wrote:
Hey all,
The newest patch set implements several of Joe's suggestions but takes a
time hit because I am using the fancy skylines for Scripts. This makes
script-accidental-collision.ly look better (as well
http://codereview.appspot.com/5626052/diff/34001/lily/skyline.cc
File lily/skyline.cc (right):
http://codereview.appspot.com/5626052/diff/34001/lily/skyline.cc#newcode362
lily/skyline.cc:362: result.push_front (Building (last_end, -infinity_f,
-infinity_f, iv[LEFT] - 2 * horizon_padding));
http://codereview.appspot.com/5626052/diff/30003/lily/skyline.cc
File lily/skyline.cc (right):
http://codereview.appspot.com/5626052/diff/30003/lily/skyline.cc#newcode393
lily/skyline.cc:393: Skyline::Skyline (Building b, Real start, Axis
horizon_axis, Direction sky)
On 2012/02/22 09:34:43,
http://codereview.appspot.com/5626052/diff/40001/lily/stencil-integral.cc
File lily/stencil-integral.cc (right):
http://codereview.appspot.com/5626052/diff/40001/lily/stencil-integral.cc#newcode932
lily/stencil-integral.cc:932: MAKE_SCHEME_CALLBACK (Grob,
http://codereview.appspot.com/5626052/diff/40001/lily/stencil-integral.cc
File lily/stencil-integral.cc (right):
http://codereview.appspot.com/5626052/diff/40001/lily/stencil-integral.cc#newcode932
lily/stencil-integral.cc:932: MAKE_SCHEME_CALLBACK (Grob,
On 2012/02/23 12:37:04, MikeSol wrote:
http://codereview.appspot.com/5626052/diff/40001/lily/stencil-integral.cc
File lily/stencil-integral.cc (right):
http://codereview.appspot.com/5626052/diff/40001/lily/stencil-integral.cc#newcode932
lily/stencil-integral.cc:932: MAKE_SCHEME_CALLBACK
On 2012/02/23 13:35:29, dak wrote:
On 2012/02/23 12:37:04, MikeSol wrote:
http://codereview.appspot.com/5626052/diff/40001/lily/stencil-integral.cc
File lily/stencil-integral.cc (right):
http://codereview.appspot.com/5626052/diff/40001/lily/stencil-integral.cc#newcode932
Am 23.02.2012 14:35, schrieb d...@gnu.org:
On 2012/02/23 12:37:04, MikeSol wrote:
http://codereview.appspot.com/5626052/diff/40001/lily/stencil-integral.cc
File lily/stencil-integral.cc (right):
http://codereview.appspot.com/5626052/diff/40001/lily/stencil-integral.cc#newcode932
On 2012/02/23 14:09:12, MikeSol wrote:
On 2012/02/23 13:35:29, dak wrote:
On 2012/02/23 12:37:04, MikeSol wrote:
http://codereview.appspot.com/5626052/diff/40001/lily/stencil-integral.cc
File lily/stencil-integral.cc (right):
Marc Hohl m...@hohlart.de writes:
As the person who wrote a lot of stuff for tablature and removed the
stems and stuff by default,
made them transparent
I second that it is an ugly workaround.
Ideally, I had removed the stem/flag engraver completely from
TabVoice, but then again, the slur
Hi Mike,
I've tested the latest patch on a few real-world scores and there
appears to be a bit of weirdness going on with TupletNumbers when a
DynamicText's nearby:
\relative c' {
\times 2/3 { c8^\p c c }
}
Cheers,
Neil
http://codereview.appspot.com/5626052/
Am 23.02.2012 15:59, schrieb David Kastrup:
Marc Hohlm...@hohlart.de writes:
As the person who wrote a lot of stuff for tablature and removed the
stems and stuff by default,
made them transparent
Yes, of course ;-)
I second that it is an ugly workaround.
Ideally, I had removed the
On Thu, Feb 23, 2012 at 3:13 AM, mts...@gmail.com wrote:
http://codereview.appspot.com/**5626052/diff/30003/lily/**skyline.cchttp://codereview.appspot.com/5626052/diff/30003/lily/skyline.cc
File lily/skyline.cc (right):
http://codereview.appspot.com/**5626052/diff/30003/lily/**
On Feb 24, 2012, at 12:07 AM, Janek Warchoł wrote:
Hey Mike,
On Thu, Feb 23, 2012 at 10:35 AM, m...@apollinemike.com
m...@apollinemike.com wrote:
Janek - all of the problems you pointed out before should be fixed in this
newest patch set - thank you very much for spotting them.
Hi,
sorry, Mike - i got confused and forgotten that a patchset newer than
what i had is here, on Rietveld.
I see that you've fixed hairpins and added skylines to accidentals,
flags and beams - great!
Unfortunately I've spotted some problems with DynamicSigns - they are
too high (as of patchset
On Wed, Feb 22, 2012 at 9:04 AM, janek.lilyp...@gmail.com wrote:
tota-pulchra.ly:
master 0m8.400s
previous skylines 0m15.649s
skylines from patchset 21: 0m15.649s
sorry, this should read 0m12.030s
___
lilypond-devel mailing list
1 - 100 of 204 matches
Mail list logo
