a
'stencil lookup scheme that would buy nothing over just using the
stencil callback other than selection of different stencils for up/down.
Since you could do that kind of decision equally well in a stencil
callback, that would be quite redundant, however.
The ability to just override the stenci
On 2019/02/23 22:40:44, dak wrote:
Sure, but you are trying to override stencils, aren't you? Why do you
even place an entry for "script-stencil" then instead of just placing
an
entry for "stencil"?
Oh. I’ve been an idiot from the start: it simply never occurred to me
t
e. I mixed up "unsmob" and "eval": a stencil expression becomes
> a Stencil when it’s eval’d, not unsmobbed.
No, it doesn't. There is ly:interpret-stencil-expression for tracing a
stencil expression via a generic callback function but that's for
interpreting stencils when drawing,
On 2019/02/22 22:11:58, dak wrote:
There is some fundamental confusion here. A stencil expression is a
list. It
never satisfies the ly:stencil? predicate and always satisfies the
pair?
predicate.
Oh, I see. I mixed up "unsmob" and "eval": a stencil expression becomes
a Stencil when it’s
On 2019/02/22 21:51:39, Valentin Villenave wrote:
On 2019/02/22 21:00:08, dak wrote:
> You are confusing stencils with stencil expressions. Stencils
satisfy
> ly:stencil? and you can extract their stencil expression (which
usually is a
> pair) with ly:stencil-expr .
Yes, but w
On 2019/02/22 21:00:08, dak wrote:
You are confusing stencils with stencil expressions. Stencils satisfy
ly:stencil? and you can extract their stencil expression (which
usually is a
pair) with ly:stencil-expr .
Yes, but what we’re dealing with in this function is a stencil
expression, isn’t
ferring to the Script.stencil property? That wouldn’t be of
much use since this property affects all Script objects whereas
script-stencil definitions allow to define many distinct articulations.
So your callback would have to refer to an alist to look up appropriate
glyphs/stencils anyway.
T
l expressions do
syntactically satisfy
the scm_is_pair test above. So all I could come up with was to let the
test
unfold in case it’s a valid glyph lookup, and only then test for a
possible
Stencil smob.
You are confusing stencils with stencil expressions. Stencils satisfy
ly:stencil? an
Hi all,
currently ParenthesesItem.stencils is set to
parentheses-item::calc-parenthesis-stencils, which basically returns
font-glyphs. The only method to customize those glyphs is to apply
different font-size.
As far as I know we don't have an alternative for
parentheses-item::calc-parenthesis
On Fri, 19 Jun 2015 23:50:50 -0700, d...@gnu.org wrote:
https://codereview.appspot.com/243610043/diff/1/lily/balloon.cc#newcode94
lily/balloon.cc:94: b.widen (padding, padding);
Basically we have two options here: not draw a box at all (it would be
my guess that this is probably what happened
Keith OHara k-ohara5...@oco.net writes:
On Fri, 19 Jun 2015 23:50:50 -0700, d...@gnu.org wrote:
https://codereview.appspot.com/243610043/diff/1/lily/balloon.cc#newcode94
lily/balloon.cc:94: b.widen (padding, padding);
Basically we have two options here: not draw a box at all (it would be
author Lukas Pietsch lukas.piet...@freenet.de
Sun, 8 Mar 2015 10:34:32 + (10:34 +)
committer James Lowe pkx1...@gmail.com
Sun, 8 Mar 2015 10:39:06 + (10:39 +)
commit b7fdbfc2ceb805cfca5b386b43e1dec831702b17
(I downloaded the diff file from Rietveld
Patch counted down - please push
https://codereview.appspot.com/201520044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2015/03/03 18:53:18, luk.pietsch wrote:
On 2015/03/03 18:34:24, J_lowe wrote:
It seems to me that from the email thread on the lists this patch
still needs
some work.
James
Not that I'm aware; have I missed something? The thread where we were
discussing
further revisions the other
Lukas,
It seems to me that from the email thread on the lists this patch still
needs some work.
James
https://codereview.appspot.com/201520044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
On 2015/03/03 18:34:24, J_lowe wrote:
It seems to me that from the email thread on the lists this patch
still needs
some work.
James
Not that I'm aware; have I missed something? The thread where we were
discussing further revisions the other day was about a different patch,
the one about
Patchy the autobot says: passes tests. Includes a full make doc
https://codereview.appspot.com/201520044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
https://codereview.appspot.com/201520044/diff/1/scm/output-ps.scm
File scm/output-ps.scm (right):
https://codereview.appspot.com/201520044/diff/1/scm/output-ps.scm#newcode308
scm/output-ps.scm:308: (if (or (not fill?)( thickness 0)) gsave stroke
grestore )
That sounds like unnecessary effort in
LGTM.
https://codereview.appspot.com/9295044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
I saw that there were some translation merges and David put in his elisp
fix as well, but I think I already ran my tests against that yesterday.
Anyway, to save time for pathcy, when ever I see a merge has taken place
I test a random patch (regardless if it fails) so that Patchy has a new
did give a box-skyline to delayed-computation
stencils like page references.
I'll try removing my changes around delayed stencils.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2013/06/14 02:32:29, Keith wrote:
I'll have time to try make doc and re-upload, this weekend.
I could not yet get `make doc` to complete, probably due to some problem
in my build-directory setup.
https://codereview.appspot.com/9295044/
___
On 2013/06/12 19:02:55, dak wrote:
https://codereview.appspot.com/9295044/diff/37001/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):
https://codereview.appspot.com/9295044/diff/37001/scm/define-markup-commands.scm#newcode1911
scm/define-markup-commands.scm:1911:
On 2013/06/13 07:45:09, Keith wrote:
On 2013/06/12 19:02:55, dak wrote:
https://codereview.appspot.com/9295044/diff/37001/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):
On Thu, 13 Jun 2013 01:02:34 -0700, d...@gnu.org wrote:
On 2013/06/13 07:45:09, Keith wrote:
It could be 'dimension-stencil as it lives alongside 'rotate-stencil,
'scale-stencil, etc.,
Well, rotate and scale are verbs and dimension isn't, so that
particular form has me less than enthused.
Keith OHara k-ohara5...@oco.net writes:
On Thu, 13 Jun 2013 01:02:34 -0700, d...@gnu.org wrote:
On 2013/06/13 07:45:09, Keith wrote:
It could be 'dimension-stencil as it lives alongside 'rotate-stencil,
'scale-stencil, etc.,
Well, rotate and scale are verbs and dimension isn't, so that
https://codereview.appspot.com/9295044/diff/51001/scm/harp-pedals.scm
File scm/harp-pedals.scm (right):
https://codereview.appspot.com/9295044/diff/51001/scm/harp-pedals.scm#newcode128
scm/harp-pedals.scm:128: (apply ly:stencil-add
Uh, (apply x (cons* y z t)) is just the same as
(apply x y z t)
https://codereview.appspot.com/9295044/diff/51001/lily/stencil-integral.cc
File lily/stencil-integral.cc (right):
https://codereview.appspot.com/9295044/diff/51001/lily/stencil-integral.cc#newcode385
lily/stencil-integral.cc:385: Interval x_ext = robust_scm2interval
(scm_car (expr), Interval ()
On Thu, 13 Jun 2013 02:13:55 -0700, d...@gnu.org wrote:
https://codereview.appspot.com/9295044/diff/51001/scm/harp-pedals.scm#newcode128
scm/harp-pedals.scm:128: (apply ly:stencil-add
Uh, (apply x (cons* y z t)) is just the same as
(apply x y z t)
isn't it?
Don't ask me; I learned Scheme
https://codereview.appspot.com/9295044/diff/51001/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):
https://codereview.appspot.com/9295044/diff/51001/scm/define-markup-commands.scm#newcode1913
scm/define-markup-commands.scm:1913: #:properties (pad-around-markup)
Remove
On 2013/06/13 16:40:46, dak wrote:
https://codereview.appspot.com/9295044/diff/51001/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):
https://codereview.appspot.com/9295044/diff/51001/scm/define-markup-commands.scm#newcode1913
scm/define-markup-commands.scm:1913:
.
For graphical objects, we can set 'vertical-skylines separately from
'horizontal- to independently choose whether to look into the stencil,
or just the extents, to trace each skyline.
In stencils, there is an aggregate of drawing commands that are
interpreted for the various output targets, and also
d...@gnu.org wrote Wednesday, June 12, 2013 6:42 AM
I disagree. There is harm in having both since it makes people think
about which to use in which situation. Since we have \pad-x and \pad-y,
\pad-around makes more sense to keep. Not only does the name help with
knowing just what is
https://codereview.appspot.com/9295044/diff/37001/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):
https://codereview.appspot.com/9295044/diff/37001/scm/define-markup-commands.scm#newcode1911
scm/define-markup-commands.scm:1911: (list 'explicit-extent-stencil x y
One possibly-interesting choice is whether the stencil-padding
functions should
always replace the skyline with a box, or make the union of the
skyline with the
box. Clearly \with-dimensions needs to replace the skyline with a box
for your
kludge \with-dimensions #'(0 . 0) #'(0 . 0) .
On 2013/06/11 06:40:13, lemzwerg wrote:
Yes, the union, since the documentation of \pad-to box says `at least
the X-EXT,
Y-EXT space'. However, the documentation strings for all \pad-XXX
functions
should be updated accordingly.
But \pad-around #-1 does work to reduce the extent of
But \pad-around #-1 does work to reduce the extent of markup,
and there is no reason to disallow that.
OK. However, we need good documentation examples...
In particular, I can't see any difference
between \pad-around and \pad-markup.
There is no harm in having both.
Of course not, but
On 2013/06/11 16:15:45, Keith wrote:
I see that they are completely identical, even after your patch!
This should
probably be fixed too, both in the docs and in the code...
There is no harm in having both. There might be people who habitually
use
each, and we cannot convert-ly their
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
1 - 100 of 266 matches
Mail list logo
