The most recent patch set copies direction from SlurEvents and
PhrasingSlurEvents, but this doesn't seem to work as intended (it fails
silently). Everything else is operational.
https://codereview.appspot.com/7424049/
___
lilypond-devel mailing list
This will be nice.
Notice that the Stanza number in
'input/regression/hara-kiri-stanza-number.ly' lost its alignment.
https://codereview.appspot.com/7574048/diff/1/scm/define-grob-interfaces.scm
File scm/define-grob-interfaces.scm (right):
LGTM. I can't help with the problem you are mentioning, but I have the
feeling that the overall code has improved (and probably become simpler
also) w.r.t. previous versions of the patch. Congrats!
https://codereview.appspot.com/7424049/diff/53001/input/regression/repeat-slur.ly
File
I'm confused by the new text. I also fail to see the motivation for
explaining this; no-one has reported any confusion with the behavior.
You might just say
Notice that \keepWithTag can change the pitches used as reference for
later pitches written using relative input mode. The d below is
Mike,
i've read the patch 3 times and i don't understand how it solves the
problem.
I see that you remove some weird c++ code, but why can you do this?
Also, why marking some grobs as cross-staff helps with solving issue
3242, which is about manual beams over rests?
What figured bass has to do
Reviewers: lemzwerg, dak,
Message:
Thanks for reviews. Before i can continue with this patch, i have to
investigate a possible new way of specifying property values (inspired
by David here
http://code.google.com/p/lilypond/issues/detail?id=3173#c5)
best,
JAnek
On 19 mars 2013, at 12:49, janek.lilyp...@gmail.com wrote:
Mike,
i've read the patch 3 times and i don't understand how it solves the
problem.
I see that you remove some weird c++ code, but why can you do this?
Also, why marking some grobs as cross-staff helps with solving issue
3242,
LGTM
https://codereview.appspot.com/7836046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/7533046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
https://codereview.appspot.com/7424049/diff/62001/input/regression/repeat-slur.ly
File input/regression/repeat-slur.ly (right):
https://codereview.appspot.com/7424049/diff/62001/input/regression/repeat-slur.ly#newcode9
input/regression/repeat-slur.ly:9: broken slur at a bar, use
@code{\broken}
https://codereview.appspot.com/7564044/diff/9001/lily/self-alignment-interface.cc
File lily/self-alignment-interface.cc (right):
https://codereview.appspot.com/7564044/diff/9001/lily/self-alignment-interface.cc#newcode130
lily/self-alignment-interface.cc:130: // TODO: should this function be
https://codereview.appspot.com/7768043/diff/19001/lily/self-alignment-interface.cc
File lily/self-alignment-interface.cc (right):
https://codereview.appspot.com/7768043/diff/19001/lily/self-alignment-interface.cc#newcode128
lily/self-alignment-interface.cc:128: /* LilyPond positions every grob
Thanks for reviewing, Mike! I'm uploading new patchset.
https://codereview.appspot.com/7564044/diff/9001/lily/self-alignment-interface.cc
File lily/self-alignment-interface.cc (right):
https://codereview.appspot.com/7564044/diff/9001/lily/self-alignment-interface.cc#newcode130
Hello all,
While answering Helge's post about multi-measure rests, I had a couple of
R-elated observations/thoughts:
1. We shouldn't be encouraging code like R4*3 in a 4/4 measure, right? So the
duration ultimately makes no sense anyway.
2. The most elegant solution would be to use R (i.e.,
Kieren MacMillan kieren_macmil...@sympatico.ca writes:
Hello all,
While answering Helge's post about multi-measure rests, I had a couple
of R-elated observations/thoughts:
1. We shouldn't be encouraging code like R4*3 in a 4/4 measure, right?
So the duration ultimately makes no sense
Am 19.03.2013 20:41, schrieb David Kastrup:
Kieren MacMillan kieren_macmil...@sympatico.ca writes:
Hello all,
While answering Helge's post about multi-measure rests, I had a couple
of R-elated observations/thoughts:
1. We shouldn't be encouraging code like R4*3 in a 4/4 measure, right?
So
Kieren,
What happens when we need an awkward length R like R1*12/8*14?
Shane
On Tue, Mar 19, 2013 at 3:05 PM, Kieren MacMillan
kieren_macmil...@sympatico.ca wrote:
Hello all,
While answering Helge's post about multi-measure rests, I had a couple of
R-elated observations/thoughts:
1. We
Hi Shane,
What happens when we need an awkward length R like R1*12/8*14?
I'm not sure what you mean by awkward length…
I'm suggesting that R (with no duration given) should give you a one-measure
multi-measure rest, regardless of what the measure duration is.
And that Rx (where x is an
Even while I am a bit sceptical whether the syntax for R should differ
from r, I see your point.
Rather than R14 for a 14 measure rest, I would suggest to keep the
syntax close to the one before: R*14 (This way I would almost be
convinced ;) )
Could the duration be optional this way, keeping the
Hi Mike all,
On 2013/03/19 15:21:37, MikeSol wrote:
I like where you're going with this.
cool! :)
I would recommend creating a function algined_on_grobs that accepts a
grob, an
vector of grobs to align to, and an axis. Then algined_on_parent
becomes a
subset of this where the vector
I see now, but one would think that might cause more difficult
programming necessitating the keeping tracking of various R values
through out the piece as defined by a time signature as opposed to us
setting the value, which probably would also slow down lilypond having
to parse and hang on to
On 2013/03/19 15:22:41, MikeSol wrote:
Two backslashes
After some consideration, I consider the name \broken suboptimal since
it implies two pieces. Two other possibilities would be \detached and
\fake.
https://codereview.appspot.com/7424049/
___
LGTM :)
https://codereview.appspot.com/7516048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 19 mars 2013, at 22:26, d...@gnu.org wrote:
On 2013/03/19 15:22:41, MikeSol wrote:
Two backslashes
After some consideration, I consider the name \broken suboptimal since
it implies two pieces. Two other possibilities would be \detached and
\fake.
Hi,
I think the name self alignment interface is confusing: after all,
the class contains not only methods for aligning grobs on themselves,
but also for aligning them on their parents or other grobs.
What about changing class' (and file) name to alignment-interface, or sth else?
Similarly with
After some consideration, I consider the name \broken suboptimal since
it implies two pieces. Two other possibilities would be \detached and
\fake.
I vote for detached.
I vote for \broken. For me, it doesn't imply two pieces. This was
David's first, quick suggestion, and I think it's
On 19 mars 2013, at 22:04, janek.lilyp...@gmail.com wrote:
Hi Mike all,
On 2013/03/19 15:21:37, MikeSol wrote:
I like where you're going with this.
cool! :)
I would recommend creating a function algined_on_grobs that accepts a
grob, an
vector of grobs to align to, and an axis. Then
On 19 mars 2013, at 23:37, Werner LEMBERG w...@gnu.org wrote:
After some consideration, I consider the name \broken suboptimal since
it implies two pieces. Two other possibilities would be \detached and
\fake.
I vote for detached.
I vote for \broken. For me, it doesn't imply two
Hi,
On Tue, Mar 19, 2013 at 11:40 PM, m...@mikesolomon.org
m...@mikesolomon.org wrote:
The main reason that I suggest this is that exceptions in the code base lead
to harder maintenance.
I am guilty of adding some from time to time (i.e. in stencil integral) but I
try to get rid of them as
Hi Shane,
one would think that might cause more difficult
programming necessitating the keeping tracking of various R values
through out the piece as defined by a time signature as opposed to us
setting the value, which probably would also slow down lilypond having
to parse and hang on to
On Tue, 19 Mar 2013 19:38:10 -0400
Kieren MacMillan kieren_macmil...@sympatico.ca wrote:
Hi Shane,
one would think that might cause more difficult
programming necessitating the keeping tracking of various R values
through out the piece as defined by a time signature as opposed to us
Kieren MacMillan kieren_macmil...@sympatico.ca writes:
Hi Shane,
What happens when we need an awkward length R like R1*12/8*14?
I'm not sure what you mean by awkward length…
I'm suggesting that R (with no duration given) should give you a
one-measure multi-measure rest, regardless of
On 2013/03/19 22:37:14, wl_gnu.org wrote:
After some consideration, I consider the name \broken suboptimal
since
it implies two pieces. Two other possibilities would be \detached
and
\fake.
I vote for detached.
I vote for \broken. For me, it doesn't imply two pieces. This was
On 20 mars 2013, at 03:24, d...@gnu.org wrote:
On 2013/03/19 22:37:14, wl_gnu.org wrote:
After some consideration, I consider the name \broken suboptimal
since
it implies two pieces. Two other possibilities would be \detached
and
\fake.
I vote for detached.
I vote for \broken.
On 20 mars 2013, at 00:27, Janek Warchoł janek.lilyp...@gmail.com wrote:
Hi,
On Tue, Mar 19, 2013 at 11:40 PM, m...@mikesolomon.org
m...@mikesolomon.org wrote:
The main reason that I suggest this is that exceptions in the code base lead
to harder maintenance.
I am guilty of adding some
m...@mikesolomon.org m...@mikesolomon.org writes:
Trying to put myself in the shoes of the average user, \fake would not
mean a function that uses a fake post event, but rather a function
that produces a \fake something. I would think this makes a fake
slur, which is not the case.
It makes
On 20 mars 2013, at 06:07, David Kastrup d...@gnu.org wrote:
m...@mikesolomon.org m...@mikesolomon.org writes:
Trying to put myself in the shoes of the average user, \fake would not
mean a function that uses a fake post event, but rather a function
that produces a \fake something. I would
37 matches
Mail list logo
