multiple floating point ops (add, multiply, etc.)
On Thu, Feb 9, 2012 at 9:24 PM, m...@apollinemike.com
m...@apollinemike.com wrote:
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
, that might be less necessary.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
that I don't get the forward declaration
error?
It's not possible. A vectorX internally creates a pointer to X,
which is why it doesn't need to know about X, but drul_array doesn't
work like that.
Just include stencil.hh and be done with it.
--
Han-Wen Nienhuys - han...@xs4all.nl - http
, not developers.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo
), and if needed then look in (lily)?
yep.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
from the
lily module.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
if #{ #} could be made to work, but I not
enough insight into how it works.
What is the rationale for putting the markups in a separate module?
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond
.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
of LilyPond is $16,000,000
Over 1 million lines of code.
The estimated developer time is 309 man years
LilyPond is a *real* software project.
Just an interesting fact.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
how I ever kept things running without having any
sort of testing framework.
Let's not forget that some of the red tape we have today is there for
good reason.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel
a single document source rather than an immaculate
database.
on the contrary: the regtest is a tely document, so bleed will cause
spurious diffs in the regtest, at least in the pixel comparison.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
the
internal dependencies of properties, it may shift things around.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
, the original
behavior of the rietveld upload is completely unchanged, so you
lose nothing!
Have you tried sending your commits back to Evan ? IIRC, he is very
responsive.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
-jX and lilypond -djob-count=X is not pretty. It would be an
interesting exercise to see if lilypond-book coud use a recursive make
invocation to schedule document sub-jobs.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
impressive for a package as complex as
LilyPond, considering that it has a bizarre documentation process,
translated docs, python bindings, fonts that are run through metapost
and fontforge, a complex regression test, and needs weird acrobatics
to find its gazilion different init files.
--
Han-Wen Nienhuys
until this is sorted
out. I'm gonna hold off until I get some responses back, though, to
make sure that people are cool with this.
Shouldnt this just use a callback to calc is-knee ?
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
move the macos-lilypad application. However, I haven't
touched that in ages, and don't own a functioning mac anymore.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https
but to no avail. Could you enlighten
me?
(my idea to fix 1546 is to include X-extent of the left note column in
shift_amount).
see Note_collision_interface::calc_positioning_done (SCM smob); it's
width of the notehead of clashgroup 0.
--
Han-Wen Nienhuys - han...@xs4all.nl - http
objects that should have
died. The GC allocation strategy may still cause memory to go up
overall, as it will accomodate for the peak memory use (ie. the most
expensive file).
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
-quanting.cc
M lily/include/beam-scoring-problem.hh
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
effect on the minimum and ideal distances of paper columns. This is not the
case (see attached).
? it's not the heights but the widths that should go into separation-item?
Have you verified that the new flag grob gets taken into account in
note-spacing.cc ?
--
Han-Wen Nienhuys - han
know if you
still want them to return intervals and I'll upload that as a separate
patch.
IIRC, you were already calculating all the values needed to return
intervals. If that is so, please use them. It makes the caller code
easier to follow.
--
Han-Wen Nienhuys - han...@xs4all.nl - http
on unimportant syntactical details.
We could adopt the following GOP rule about writing functions:
Use your brain when you write and arrange a function.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing
, though, so this pattern here is not uncommon.
You could also try to allocate them on the stack.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo
On Wed, Aug 24, 2011 at 10:57 AM, David Kastrup d...@gnu.org wrote:
Han-Wen Nienhuys hanw...@gmail.com writes:
Skylines are smobs. The usual way to delete them would be to
unprotect them once they have been registered by some
garbage-collectable object (or a SCM variable that is being used
today unless anyone sees a better alternative.
this will generate square endings on the ledgers.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org
if the
accidental covers a ledger only halfway? The ledgers would look like
a ***
a ***
*
*
(a = acc, * = ledger)
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https
don't have any documentation any
more about the valid values... :(
You've hit the proverbial nail on its proverbial head. It is for this
reason that I'm wary about renaming.
Yes, but please rename anyway. You could put the 'style values in the
doc of flag-interface.
--
Han-Wen Nienhuys
it has been just hanging out not doing
anything for at least a year).
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Sat, Aug 20, 2011 at 6:06 AM, Jan Nieuwenhuizen jann...@gnu.org wrote:
Han-Wen Nienhuys writes:
Given that Cmake has a large following (examples include KDE and
LLVM), I'd be comfortable with switching to that.
Interesting; have you ever used Cmake?
Lately I've been doing tweaks
/mailman/listinfo/lilypond-devel
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
, so we have to
interpret '() as false.
Scheme has a similar confusion in that all non-#f values are
interpreted to be true.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
,
ledger_size,
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
output at all,
and performance not by much. Why not skip it altogether and avoid the
complexity?
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman
side, if we use this, we will be the first GNU program to
be compatible with the elisp compatibility mode in GUILE that has been
almost ready for the last 15 years.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel
as a design goal. In any
case, the respective define in current master (2.whatever) is
I should probably start using sarcasm tags.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel
to stems in certain conditions.
#2) sounds neat, but maybe Janek (who has spent some time messing
around with flags) wants to weigh in.
If it is a viable path, you should probably do it before applying this patch.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
conversions because they are very wrong, ie,
SCM x = ...
if (x) {
..
}
for the rest, making lilypond SCM typing clean is just a lot of work
with no benefits at all.
(and I am speaking as a GUILE developer here as well)
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl
the genericity suggested by the GUILE docs
are a joke.
If you feel compelled to change large swaths of source code by
substituting x == SCM_EOL with scm_is_eq(x, SCM_EOL), then I can't
stop you, but to me it just looks like a waste of time.
--
Han-Wen Nienhuys - han...@xs4all.nl - http
(lilypond-book, musicxml2ly, convert-ly):
http://codereview.appspot.com/4908041
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond
On Sun, Aug 14, 2011 at 1:25 PM, mts...@gmail.com wrote:
THE UGLY:
Because this patch effects stem extents across the board, the regtest
comparisons are nightmarish to check. The layout probably does not
change at all in most regtests (at least not to the naked eye), but
because of the
), I'd be comfortable with switching to that.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
up if someone is interested in cleaning
things.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
parameters, but given that this uses an arbitrary number 2.5, it's
better to have that number together with other numbers.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https
status = 1
warning(..) // prints, succesful exist status.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
the Scheme lists not reverse
direction may have seemed easier at the time.
The performance overhead (even if you used non-destructive reverse) is
probably neglible; I wouldn't bother measuring it.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
On Fri, Jul 29, 2011 at 2:15 AM, lemniskata.bernoull...@gmail.com wrote:
Reviewers: hanwenn,
Message:
http://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg01051.html
2011/7/27 Han-Wen Nienhuys hanw...@gmail.com:
Due to rounding, PDF viewers can err
the placement of the barline
, rather than the outside.
both have disadvantages. (what does finale's barline at the end of a
staff look like?)
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https
, there is a
slur/tuplet-number collision.
Cheers,
MS
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
a collision strategy work? Since this situation is
symmetric, any solution within the current framework would be
cyclical. You could break the tie by having the top adjust to the
bottom (or vice versa), but I think people expect to get a symmetric
resolution in cases like these.
--
Han-Wen Nienhuys - han
and initialized there.
Ah, I forgot. LGTM then.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Thu, Jul 21, 2011 at 8:11 AM, Karl Hammar k...@aspodata.se wrote:
Han-Wen Nienhuys:
...
Werner, can you have a look at http://codereview.appspot.com/4819041 ?
/draw_round_box % width height x y blot
{
- setlinewidth % w h x y
- 0 setlinecap
- 1 setlinejoin
On Thu, Jul 21, 2011 at 12:31 PM, Karl Hammar k...@aspodata.se wrote:
Han-Wen Nienhuys:
On Thu, Jul 21, 2011 at 8:11 AM, Karl Hammar k...@aspodata.se wrote:
Han-Wen Nienhuys:
Werner, can you have a look at http://codereview.appspot.com/4819041 ?
There is no blot on the stack below
On Thu, Jul 21, 2011 at 11:27 PM, Han-Wen Nienhuys hanw...@gmail.com wrote:
After dup there is two blots, gt consumes one and setlinewidth
the other.
I'm sorry - I misunderstood; I thought you saw a problem with the code
rather than the comments.
pushed
ly_lily_module_constant? It memoizes, so it is efficient.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
(glissando stems).
Could you put this in a separate patch?
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Wed, Jul 20, 2011 at 11:30 PM, Han-Wen Nienhuys hanw...@gmail.com wrote:
http://codereview.appspot.com/4777044/diff/7001/lily/beam.cc#newcode706
lily/beam.cc:706: Interval positions = robust_scm2interval
((*s)-get_property (head-positions), Interval (0,0));
rather than changing all callers
in place X but the
property head-positions called in place Y?). That's the reason I swapped out
the function with property calls. But, again, I'm a relative newb - whatever
you think is best I'll do.
You'd move the current code for head_positions() into a
calc_head_positions callback.
--
Han-Wen
ask on a GhostScript mailing list,
showing the demo file which exhibits the problem.
I asked around (the ex-maintainer of GS works at google); we concluded
that it was better to use fill for non-rounded boxes, rather than
doing filldraw.
--
Han-Wen Nienhuys - han...@xs4all.nl - http
ask on a GhostScript mailing list,
showing the demo file which exhibits the problem.
Werner, can you have a look at http://codereview.appspot.com/4819041 ?
Thanks!
(I am assuming you are somewhat fluent in Postscript)
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
creates loops would never finish compiling. We do
obj-relative_coordinate(system, axis)
in some place, and if there were a loop, this would never exit.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing
clef glyph until 2.18. Then
we'll reconsider deleting it permanently.
It's only a glyph. We can just delete it directly. That also helps
combat the inevitable code duplication between the MF code of the old
and new clef.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
(?).
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Fri, Jul 1, 2011 at 1:09 PM, Han-Wen Nienhuys hanw...@gmail.com wrote:
The problem with this is that, in the axis-group-interface, the TupletNumber
either:
(1) Does not have an outside staff priority and therefore is included in the
staff's skyline, which pushes the bracket too high.
(2
.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Wed, Jul 13, 2011 at 5:12 PM, m...@apollinemike.com
m...@apollinemike.com wrote:
On Jul 13, 2011, at 4:42 PM, Han-Wen Nienhuys wrote:
On Wed, Jul 13, 2011 at 11:27 AM, m...@apollinemike.com
m...@apollinemike.com wrote:
Wouldnt it be much easier for the tuplet number's extents
you do a real measurement ? Have the code print out timestamps at
start end of translation, and run a 10 times with and without.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
actually caused by gub changes.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
?
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
is the glissando-index property for? I can't see
it being read anywhere.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
be put on notes
with much less hassle.
One idea:
\tweak #'glissando-connect #1 c f
d e
would generate 1 glissando from C to D.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond
(not
centered on the bracket?)
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
the same OS and architecture), and I am going
to open-source it.
It could speed up GUB and regtest checking for those that have access
to several machines.
Anybody interested?
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
the regtests, so it is easier to push changes that
went through regtest checks.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
in a ~100 places or
so. If you are starting to use a property for length, your code
should have a 100 places changed.
I think you scheme code will be easier to follow if you just define a
function that computes the length, if given a spanner.
--
Han-Wen Nienhuys - han...@xs4all.nl - http
]++;
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https
with already exports its properties. Engraver::get_property is just a
convenience for the C++ side.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org
) * (multiplicity.length () + 1);
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
should be split in two (one for the bound-info, one for the
extent adjustment), and it is lacking a regtest to demonstrate what it
achieves.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel
of global list or table.
it's very well possible that the check for this is ony switched on in
debugging, but it is an error in any event.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel
LilyPond in multiple passes. Lemme know if it looks all right.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
the textinfo into the event.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
. It has more internal checking and error reporting. It
compiles faster to boot
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond
));
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond
On Fri, Apr 29, 2011 at 9:59 AM, m...@apollinemike.com
m...@apollinemike.com wrote:
On Apr 28, 2011, at 10:26 PM, Han-Wen Nienhuys wrote:
On Thu, Apr 28, 2011 at 12:37 PM, mts...@gmail.com wrote:
Reviewers: ,
Message:
If I understand it correctly, Han-Wen's original collision code
=
- (!collision_free[DOWN].is_empty()) ?
- collision_free[DOWN] :
- collision_free[UP];
-
- beam_left_y = point_in_interval (v, 2.0);
these are not beam slopes.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
, hanwenn wrote:
comment why we are doing this.
If we don't do this, this continues to be a problem:
I mean: add a short comment to the code.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond
not really into the lilypond spirit of things yet. We don't
strive to be perfect; the objective is just to be better than the last
release. It's ok to not handle some cases if it's too hairy.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
? This code looks a bit
kludgey.
alternatively, put all staff_syms into a setGrob* and check if the length 1.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org
On Mon, Apr 25, 2011 at 6:43 PM, m...@apollinemike.com
m...@apollinemike.com wrote:
On Apr 25, 2011, at 5:37 PM, Han-Wen Nienhuys wrote:
On Mon, Apr 25, 2011 at 9:45 AM, mts...@gmail.com wrote:
I realized that it was way too restrictive to have cross-staff beams
avoid stems and beams
a global minimum/maximum to initate search
for (cov : grobs[start : .. ]) {
// consider adding cov to b.
}
}
}
on second thought, this may be too tricky for a first cut.
http://codereview.appspot.com/4432063/
--
Han-Wen Nienhuys - han...@xs4all.nl - http
- $mf
print 'include \$(depth)/config\$(if \$(conf),-\$(conf),).make'
--
1.7.3.5
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
--
Han-Wen Nienhuys - han...@xs4all.nl - http
with a list of intervals rather than just
an up/down choice. I think the simple quick solution is to disable
stems for beam collisions for now.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
You're passing all of the music through the typesetting process which
is just unnecessary.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo
master.
Anybody have any ideas?
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
that is impossible to pass from
the top, so we revert to the bottom.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
701 - 800 of 3768 matches
Mail list logo
