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 input/re
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
int
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 w
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
https://codereview.appspot.com/7
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
>
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} w
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
def
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
r
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
lily/self-alignm
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., wit
Kieren MacMillan 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 anyway.
> 2. The most elegan
Am 19.03.2013 20:41, schrieb David Kastrup:
Kieren MacMillan 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
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
wrote:
> 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 encouragin
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 int
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
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 that
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/
___
l
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.
>
> https://codereview.appspot.c
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 i
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 a
On 19 mars 2013, at 23:37, Werner LEMBERG 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 pie
Hi,
On Tue, Mar 19, 2013 at 11:40 PM, 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 fast as possible.
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 t
On Tue, 19 Mar 2013 19:38:10 -0400
Kieren MacMillan 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
> > setting the value, whi
Kieren MacMillan 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 what the measure
> dur
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 w
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.
>
>
On 20 mars 2013, at 00:27, Janek Warchoł wrote:
> Hi,
>
> On Tue, Mar 19, 2013 at 11:40 PM, 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
"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 a fake slur s
On 20 mars 2013, at 06:07, David Kastrup wrote:
> "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 fa
>> I vote for \broken. For me, it doesn't imply two pieces. This was
>> David's first, quick suggestion, and I think it's good for exactly
>> this reason.
>
> when I see \broken\< or \broken\!, this does not really help me
> figure out where to use them. \broken\! actually looks, uh, broken.
>
> Since \partial is already taken, what about \cut? The
> spanner gets cut a bit, right?
I can even imagine to use to commands, \start and \end to get, say,
`\start(' or `\end\>'. Who knows, maybe this destinction is
advantageous sometime in the future.
Werner
___
> I can even imagine to use to commands, \start and \end to get, say,
> `\start(' or `\end\>'. Who knows, maybe this destinction is
> advantageous sometime in the future.
Maybe even better \startOf and \endOf.
Werner
___
lilypond-devel mailing l
On 20 mars 2013, at 07:25, Werner LEMBERG wrote:
>
>> I can even imagine to use to commands, \start and \end to get, say,
>> `\start(' or `\end\>'. Who knows, maybe this destinction is
>> advantageous sometime in the future.
>
> Maybe even better \startOf and \endOf.
>
>
>Werner
The pr
"m...@mikesolomon.org" writes:
> On 20 mars 2013, at 06:07, David Kastrup wrote:
>
>> "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 so
On 20 mars 2013, at 07:50, David Kastrup wrote:
> "m...@mikesolomon.org" writes:
>
>> On 20 mars 2013, at 06:07, David Kastrup wrote:
>>
>>> "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
41 matches
Mail list logo
