date:20130319


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 with this at all?


Creates more possibilities for vertical and horizontal skyline

functions.

I think this sentence applied to first version of the patch; it seems
unrelated to current patchset.

I'm sorry to say this, but i think this issue is unreviewable :/

https://codereview.appspot.com/7516048/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: let beam thickness depend on line thickness (fix 3173) (issue 7312091)


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/7312091/diff/1/scm/define-grob-properties.scm
File scm/define-grob-properties.scm (right):

https://codereview.appspot.com/7312091/diff/1/scm/define-grob-properties.scm#newcode93
scm/define-grob-properties.scm:93: (beam-thickness ,number-pair? "Beam
thickness.  It is the sum
On 2013/02/14 19:43:00, dak wrote:

You are confusing "sum" and "pair" in this comment.


You're right, sorry.  I've copied this from the description of
ledger-line-thickness, so that one needs clarifying as well.

Description:
let beam thickness depend on line thickness (fix 3173)

One of LilyPond's design principles is "optical sizing"
(described in Essay, section Engraving details), which means
that as the font-size gets smaller, all elements get relatively
thicker.

Before now beam-thickness was defined as a fraction of
staffSpace, which meant no optical sizing (the thickness of the
beam stayed constant relative to the height of the staff). This
patch changes beam-thickness property to be a pair of numbers
(a . b). The actual thickness is calculated according to the
formula  a * lineThickness + b * staffSpace  (similarly to ledger
line thickness).

Please review this at https://codereview.appspot.com/7312091/

Affected files:
  M lily/beam.cc
  M scm/define-grob-properties.scm
  M scm/define-grobs.scm


Index: lily/beam.cc
diff --git a/lily/beam.cc b/lily/beam.cc
index  
4a2e752947bcf753815e151e207f1cae6f7b562d..8a50039964ec77936dc6603905e488efbd53c551  
100644

--- a/lily/beam.cc
+++ b/lily/beam.cc
@@ -106,8 +106,11 @@ Beam::add_stem (Grob *me, Grob *s)
 Real
 Beam::get_beam_thickness (Grob *me)
 {
-  return robust_scm2double (me->get_property ("beam-thickness"), 0)
- * Staff_symbol_referencer::staff_space (me);
+  SCM bmth_pair = me->get_property ("beam-thickness");
+  Offset th = robust_scm2offset (bmth_pair, Offset (1, 0.38));
+
+  return th[X_AXIS] * Staff_symbol_referencer::line_thickness (me)
+ + th[Y_AXIS] * Staff_symbol_referencer::staff_space (me);
 }

 /* Return the translation between 2 adjoining beams. */
Index: scm/define-grob-properties.scm
diff --git a/scm/define-grob-properties.scm b/scm/define-grob-properties.scm
index  
c1a3a723cb89a601c2a65dd56719467a38088859..00cf25f276a1037a6257aa7e1006f41d49494d77  
100644

--- a/scm/define-grob-properties.scm
+++ b/scm/define-grob-properties.scm
@@ -90,8 +90,9 @@ shortest notes in a piece.  Normally, pieces are spaced  
as if notes at

 least as short as this are present.")
  (baseline-skip ,ly:dimension? "Distance between base lines of
 multiple lines of text.")
- (beam-thickness ,ly:dimension? "Beam thickness, measured in
-@code{staff-space} units.")
+ (beam-thickness ,number-pair? "Beam thickness.  It is the sum
+of 2@tie{}numbers: The first is the factor for line thickness,
+and the second for staff space.  Both contributions are added.")
  (beam-width ,ly:dimension? "Width of the tremolo sign.")
  (beamed-stem-shorten ,list? "How much to shorten beamed stems,
 when their direction is forced.  It is a list, since the value is
Index: scm/define-grobs.scm
diff --git a/scm/define-grobs.scm b/scm/define-grobs.scm
index  
cc4a9c76e935f7ba965f2904aedcfce460856724..dd04211cb4bf62bf5c82cc3a3ab3aa39c44af068  
100644

--- a/scm/define-grobs.scm
+++ b/scm/define-grobs.scm
@@ -342,7 +342,7 @@
;; rather long.
(auto-knee-gap . 5.5)
(beam-segments . ,ly:beam::calc-beam-segments)
-   (beam-thickness . 0.48) ; in staff-space
+   (beam-thickness . (1 . 0.38)) ; line-thickness + staff-space

;; We have some unreferenced problems here.
;;



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Creates more possibilities for vertical and horizontal skyline functions. (issue 7516048)

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, which is about manual beams over rests?
> What figured bass has to do with this at all?
> 
>> Creates more possibilities for vertical and horizontal skyline
> functions.
> 
> I think this sentence applied to first version of the patch; it seems
> unrelated to current patchset.
> 
> I'm sorry to say this, but i think this issue is unreviewable :/

Thanks for the feedback!  I've changed the message on Rietveld to be more in 
line with the current patch - you're right that it's bounced around quite a 
bit.  I've also added a couple comments.

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Let lilymidi display key signatures in a readable manner (issue 7836046)

2013-03-19 Thread lemzwerg


LGTM

https://codereview.appspot.com/7836046/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: report a programming error when trying to align on empty parent (issue 7533046)

2013-03-19 Thread mtsolo


LGTM

https://codereview.appspot.com/7533046/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Allows slurs to break at barlines. (issue 7424049)

2013-03-19 Thread lemzwerg



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} with a closing parenthesis.
Sorry to bother you again, but *two* backslashes are needed:
@code{\\broken}

https://codereview.appspot.com/7424049/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: don't abort aligning when grob's parent is a PaperColumn (issue 7564044)

2013-03-19 Thread mtsolo



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
defined someplace else, e.g. in note-column.cc?
I like where you're going with this.
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 is of length
one and is the parent.
Then, you can create a function
Self_alignment_interface::lyrics_algined_on_note_columns that invokes
aligned_on_grobs with a vector of note columns returned using the search
method in this function.  This function could be implemented in
paper-column.cc as get_generic_interface_extent such that it recurses
through a paper columns' element list, finds all grobs implementing
interface X and returns them.

https://codereview.appspot.com/7564044/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: reorganize self_alignment_interface (issue 7768043)

2013-03-19 Thread mtsolo



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
relative to its parent in respective axis.
In general, try to avoid using the word LilyPond in comments, as it is
in the LilyPond code base.

https://codereview.appspot.com/7768043/diff/19001/lily/self-alignment-interface.cc#newcode133
lily/self-alignment-interface.cc:133:
I don't see staff space being looked up anywhere in the function.

https://codereview.appspot.com/7768043/diff/19001/lily/self-alignment-interface.cc#newcode144
lily/self-alignment-interface.cc:144:
With respect to my last review, this function should accept a pointer to
a vector of grob pointers:

vector &hims

so that you can do the note column stuff for lyrics.

https://codereview.appspot.com/7768043/diff/19001/lily/self-alignment-interface.cc#newcode144
lily/self-alignment-interface.cc:144:
I don't have the energy to trigger another comment flame war, but a
comment like this may wind up diverging from what the code is doing (it
already does with the staff space thing).  Can you write the bare
minimum and comment the code below in places?  The code is already
clear: I can tell what you're doing and why you're doing it, so it
speaks for itself.

https://codereview.appspot.com/7768043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: don't abort aligning when grob's parent is a PaperColumn (issue 7564044)


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-alignment-interface.cc:130: // TODO: should this function be
defined someplace else, e.g. in note-column.cc?
On 2013/03/19 15:21:37, MikeSol wrote:

I like where you're going with this.
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 is of length one and is the parent.
Then, you can create a function
Self_alignment_interface::lyrics_algined_on_note_columns that invokes
aligned_on_grobs with a vector of note columns returned using the

search method

in this function.


I'll post a detailed answer in https://codereview.appspot.com/7768043/


This function could be implemented in paper-column.cc as
get_generic_interface_extent such that it recurses through
a paper columns'element list, finds all grobs implementing
interface X and returns them.


Good idea! Done.

https://codereview.appspot.com/7564044/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

R shorthand

2013-03-19 Thread Kieren MacMillan

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., with no duration) to 
represent a multimeasure rest, and it would "adapt" in duration to whatever 
time signature was in force at that moment.
3. Then R14 (e.g.) would represent 14 *measures*, not beats/counts — again, 
simpler, more elegant, and certainly more intuitive than the current situation.

Would it be difficult to implement such a scheme (play-on-words intended)?

Best regards,
Kieren.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: R shorthand

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 elegant solution would be to use R (i.e., with no
> duration) to represent a multimeasure rest, and it would "adapt" in
> duration to whatever time signature was in force at that moment.
> 3. Then R14 (e.g.) would represent 14 *measures*, not beats/counts —
> again, simpler, more elegant, and certainly more intuitive than the
> current situation.
>
> Would it be difficult to implement such a scheme (play-on-words
> intended)?

One idea is that this makes it easy to switch between r and R.  Also, R
is something that editors treat like note names.

We could promote using R1*3/4*14 in the documentation (for 5 measures of
3/4).  That's reasonably brainless, but indeed more verbose than
desirable.

Or we could offer \tacet 14 without any relation to durations.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: R shorthand

2013-03-19 Thread Marc Hohl


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 sense anyway.
2. The most elegant solution would be to use R (i.e., with no
duration) to represent a multimeasure rest, and it would "adapt" in
duration to whatever time signature was in force at that moment.
3. Then R14 (e.g.) would represent 14 *measures*, not beats/counts —
again, simpler, more elegant, and certainly more intuitive than the
current situation.


I am not sure about this. Yes, we are talking about full measure rests
any way, but R14 looks wrong to me.

If the duration could be omitted for R as you described, then I'd vote
for R being *one* measure and for R * 14 to get the desired 14 measures.


Would it be difficult to implement such a scheme (play-on-words
intended)?


One idea is that this makes it easy to switch between r and R.  Also, R
is something that editors treat like note names.

We could promote using R1*3/4*14 in the documentation (for 5 measures of


14 measures?


3/4).  That's reasonably brainless, but indeed more verbose than
desirable.

Or we could offer \tacet 14 without any relation to durations.


That sounds like a good thing to have. If this works with
\compressFullBarRests then it will be a nice feature.





___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: R shorthand

2013-03-19 Thread Shane Brandes

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 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., with no duration) to 
> represent a multimeasure rest, and it would "adapt" in duration to whatever 
> time signature was in force at that moment.
> 3. Then R14 (e.g.) would represent 14 *measures*, not beats/counts — again, 
> simpler, more elegant, and certainly more intuitive than the current 
> situation.
>
> Would it be difficult to implement such a scheme (play-on-words intended)?
>
> Best regards,
> Kieren.
> ___
> lilypond-user mailing list
> lilypond-u...@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: R shorthand

2013-03-19 Thread Kieren MacMillan

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 integer) will give you an x-measure multi-measure 
rest, regardless of the duration(s) of each measure.

Let's say you have the following passage: 7 measure of 4/4, 1 measure of 5/8, 2 
measures of 7/16, and 3 measures of 3/4.
R13 would give you a multi-measure rest which is as long as the whole section.

So what would constitute an "awkward length", if R simply gives you the 
duration of the measure, whatever it is?
Are you not asking for a multi-measure rest which has the same duration as the 
measure it fills?
If so, how does that make any sense? What are you doing in the rest of that 
measure (that can't be better done another way)?

Thanks,
Kieren.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: R shorthand

2013-03-19 Thread Joram Berger

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 current behaviour
if given? I mean could this change request be implemented without
affecting the recommended way at present? Probably not, because of
ambiguities, and because the following notes would take the same duration.

Cheers,
Joram

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: reorganize self_alignment_interface (issue 7768043)

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 is of length one and is the parent.
Then, you can create a function
Self_alignment_interface::lyrics_algined_on_note_columns that invokes
aligned_on_grobs with a vector of note columns returned using the

search method

in this function.

On 2013/03/19 15:28:45, MikeSol wrote:

With respect to my last review, this function should accept a pointer

to a

vector of grob pointers:

vector &hims

so that you can do the note column stuff for lyrics.

I don't think this (defining special lyrics_algined_on_note_columns
callback) is optimal approach.

With your suggestion, here's how i expect alignment stuff would look
like:
- there'd be a method Self_alignment_interface::aligned_on_grobs that
can align a grob on another grob(s)
- we'd have two callbacks:
Self_alignment_interface::lyrics_aligned_on_note_columns
and
Self_alignment_interface::lyrics_aligned_on_parent_notehead
- we'd have to decide when which callback should be used. How should
LyricText definition in define-grobs.scm look like? We should use
lyrics_aligned_on_note_columns when lyrics are unassociated, and
lyrics_aligned_on_parent_notehead when there is an associatedVoice - how
to write that in define-grobs?

And the same thing will be repeated for many other grobs, for example
DynamicTexts: we'll have to specify different callback for DynamicTexts
attached to NoteHeads, and different one for standalone Dynamics (e.g.
in Dynamic Context).

How alignment stuff would look like with my approach:
- aligned_on_grobs would be more complicated, because it'd have to grab
NoteColumn extent if 'him' turns out to be a PaperColumn
- we'd have one callback for everything
- we won't have to think about anything when defining grobs. We'd just
write X-offset = ly:self-alignment-interface::align-grob, and it would
be aligned_on_grobs' job to align on appropriate grob if the default one
(parent) is inappropriate.

The difference is conceptual: aligning on NoteColumn is an exception, an
emergency exit needed only when grob doesn't have an ordinary parent.
As far as i know, if grob's parent is a NoteHead or some other "normal"
grob, we always want to align on that; and when grob's parent is a
PaperColumn, we always want to align grob on an appropriate NoteColumn.

As for using a vector 'hims' instead of single 'him', maybe it's a good
idea, but i don't see any uses for it (besides your above suggestion,
which seems to be unnecessary).

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
relative to its parent in respective axis.
On 2013/03/19 15:28:45, MikeSol wrote:

In general, try to avoid using the word LilyPond in comments, as it is

in the

LilyPond code base.

Done.

https://codereview.appspot.com/7768043/diff/19001/lily/self-alignment-interface.cc#newcode133
lily/self-alignment-interface.cc:133:
On 2013/03/19 15:28:45, MikeSol wrote:

I don't see staff space being looked up anywhere in the function.

Well, staffspace is the unit in which XY-offsets are measured, so it's
implied by LilyPond herself. I've reworded the comment to make it
clearer.

https://codereview.appspot.com/7768043/diff/19001/lily/self-alignment-interface.cc#newcode144
lily/self-alignment-interface.cc:144:
On 2013/03/19 15:28:45, MikeSol wrote:

I don't have the energy to trigger another comment flame war,
but a comment like this may wind up diverging from what the code
is doing (it already does with the staff space thing).
Can you write the bare minimum and comment the code below in places?
The code is already clear: I can tell what you're doing and why
you're doing it, so it speaks for itself.

I've trimmed the comments and tried to make them less
implementation-specific.
However, as a rule, i will continue to write as much comments as is
reasonable (of course, let me know whenever i write *too much*
comments!), because of two things:
- i really want to make reading the code /as easy as possible/ for a
newcomer (i know that i'd benefit from these comments if they were
written when i was first reading the code)
- i want to make review process as easy as possible, to encourage
everyone (including non-c++ people) to review my code ;) My rule is
"reading commit message should make it clear what the patch does and
why, and after first reading of the code&comments it should be clear how
it's done, at least at the concept level".

https://codereview.appspot.com/7768043/

___
lilypond-devel mailing list
l

Re: R shorthand

2013-03-19 Thread Shane Brandes

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 extra undeclared information. Of course
maybe i am wrong on that. But I do believe making sure the user is
forced to think out the value of R duration is probably more useful
than any minimal convenience, especially as Joram points out that
would make r and R functionality divergent.

Shane

On Tue, Mar 19, 2013 at 4:52 PM, Joram Berger  wrote:
> 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 current behaviour
> if given? I mean could this change request be implemented without
> affecting the recommended way at present? Probably not, because of
> ambiguities, and because the following notes would take the same duration.
>
> Cheers,
> Joram
>
> ___
> lilypond-user mailing list
> lilypond-u...@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Allows slurs to break at barlines. (issue 7424049)

2013-03-19 Thread dak


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/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Removes kludges in stencil-based skyline code. (issue 7516048)


LGTM :)

https://codereview.appspot.com/7516048/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Allows slurs to break at barlines. (issue 7424049)

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.com/7424049/

I vote for detached.

Cheers,
MS

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

shall we change self-alignment-interface to alignment-interface?

2013-03-19 Thread Janek Warchoł

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 properties self-alignment-[XY]: i was confused by them
for a long time, because they affect not only grob's own alignment,
but also to which point of its parent is the grob attached.

cheers,
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Allows slurs to break at barlines. (issue 7424049)

>> 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 good for exactly
this reason.


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: reorganize self_alignment_interface (issue 7768043)

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 algined_on_parent
> becomes a
>> subset of this where the vector is of length one and is the parent.
>> Then, you can create a function
>> Self_alignment_interface::lyrics_algined_on_note_columns that invokes
>> aligned_on_grobs with a vector of note columns returned using the
> search method
>> in this function.
> 
> On 2013/03/19 15:28:45, MikeSol wrote:
>> With respect to my last review, this function should accept a pointer
> to a
>> vector of grob pointers:
> 
>> vector &hims
> 
>> so that you can do the note column stuff for lyrics.
> 
> I don't think this (defining special lyrics_algined_on_note_columns
> callback) is optimal approach.
> 
> With your suggestion, here's how i expect alignment stuff would look
> like:
> - there'd be a method Self_alignment_interface::aligned_on_grobs that
> can align a grob on another grob(s)
> - we'd have two callbacks:
>  Self_alignment_interface::lyrics_aligned_on_note_columns
>  and
>  Self_alignment_interface::lyrics_aligned_on_parent_notehead
> - we'd have to decide when which callback should be used.  How should
> LyricText definition in define-grobs.scm look like?  We should use
> lyrics_aligned_on_note_columns when lyrics are unassociated, and
> lyrics_aligned_on_parent_notehead when there is an associatedVoice - how
> to write that in define-grobs?
> 
> And the same thing will be repeated for many other grobs, for example
> DynamicTexts: we'll have to specify different callback for DynamicTexts
> attached to NoteHeads, and different one for standalone Dynamics (e.g.
> in Dynamic Context).
> 
> How alignment stuff would look like with my approach:
> - aligned_on_grobs would be more complicated, because it'd have to grab
> NoteColumn extent if 'him' turns out to be a PaperColumn
> - we'd have one callback for everything
> - we won't have to think about anything when defining grobs.  We'd just
> write X-offset = ly:self-alignment-interface::align-grob, and it would
> be aligned_on_grobs' job to align on appropriate grob if the default one
> (parent) is inappropriate.
> 
> The difference is conceptual: aligning on NoteColumn is an exception, an
> emergency exit needed only when grob doesn't have an ordinary parent.
> As far as i know, if grob's parent is a NoteHead or some other "normal"
> grob, we always want to align on that; and when grob's parent is a
> PaperColumn, we always want to align grob on an appropriate NoteColumn.
> 
> As for using a vector 'hims' instead of single 'him', maybe it's a good
> idea, but i don't see any uses for it (besides your above suggestion,
> which seems to be unnecessary).

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.  One 
example in the code base that I don't like: check out line 136.  Granted, 
whoever created it doesn't like it either from the looks of the comment.  It 
makes the code harder to read, maintain and understand.  The worst offender by 
far is the metronome mark - there are so many exceptions concerning who its 
parent is that it leads to actual problems with layout in certain cases.

I definitely like your idea of coming up with a single function, though.  
Perhaps try the following:

-) always decompose axis-groups into elements (recursively if need be)
-) create a non_musical flag that, if set, weeds out all grobs where 
non-musical is set to #t

This may achieve the same effect but it is a lot more general, as the 
distinction is between musical and non-musical rather than between note column 
and everything else.

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Allows slurs to break at barlines. (issue 7424049)


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 pieces.  This was
> David's first, quick suggestion, and I think it's good for exactly
> this reason.
> 
> 
>Werner

I amend my statement - I should have said that I don't have a preference.  
Anything that people like is fine.

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: reorganize self_alignment_interface (issue 7768043)

2013-03-19 Thread Janek Warchoł

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.
> One example in the code base that I don't like: check out line 136.

In which file?  line 136 of self-alignment-interface.cc from master is empty.

> Granted, whoever created it doesn't like it either from the looks of the 
> comment.
> It makes the code harder to read, maintain and understand.
> The worst offender by far is the metronome mark - there are so many exceptions
> concerning who its parent is that it leads to actual problems with layout in 
> certain cases.

Sure, that's no good at all.

> I definitely like your idea of coming up with a single function, though.  
> Perhaps try the following:
>
> -) always decompose axis-groups into elements (recursively if need be)

What do you mean by axis-groups?  'hims' (a vector of grobs that me
shoulld be aligned to)?

> -) create a non_musical flag that, if set, weeds out all grobs where 
> non-musical is set to #t

I'm not quite surehow non-musical grobs are related to alignment code.
 Do you mean that this flag would be responsible for "getting rid of
PaperColumn parent"?

cheers,
JAenk

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: R shorthand

2013-03-19 Thread Kieren MacMillan

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 that extra undeclared information.

Possibly — that's exactly why I posted the question.

> But I do believe making sure the user is
> forced to think out the value of R duration is probably more useful
> than any minimal convenience, especially as Joram points out that
> would make r and R functionality divergent.

r and R functionality is already divergent (e.g., placement) — so that's hardly 
an additional concern at this point.

Best,
Kieren.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: R shorthand

2013-03-19 Thread Urs Liska

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, which probably would also slow down lilypond having
> > to parse and hang on to that extra undeclared information.
> 
> Possibly — that's exactly why I posted the question.
> 
> > But I do believe making sure the user is
> > forced to think out the value of R duration is probably more useful
> > than any minimal convenience, especially as Joram points out that
> > would make r and R functionality divergent.
> 
> r and R functionality is already divergent (e.g., placement) — so that's 
> hardly an additional concern at this point.
Actually Kieren's suggestion would cause this divergence to reflect more the 
traditional engraving practice.
Actually a full (multi) measure rest is just a symbol representing _one 
measure_, regardless of its actual length.

Urs

> 
> Best,
> Kieren.
> ___
> lilypond-user mailing list
> lilypond-u...@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: R shorthand

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
> duration is.

I just realized that the total musical length of music expressions is
established _before_ iteration (and some manipulations require it to be
known), while the varying measure length is established by properties
set _during_ iteration.

So whatever the syntax: no can do.  Surprising as that may seem.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Allows slurs to break at barlines. (issue 7424049)

2013-03-19 Thread dak

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
David's first, quick suggestion, and I think it's good for exactly
this reason.

The first suggestion just picked this off the proposed music event name.
 Here is why I consider \fake or \detached better:

when I see \broken\< or \broken\!, this does not really help me figure
out where to use them.  \broken\! actually looks, uh, broken.  How do
you break an end spanner?

However, \fake\< or \fake\! immediately make clear that we are talking
about something still being used in the function of a starting and
ending spanner, respectively.  I like it somewhat better than \detached,
but of course the latter is a bit more dignified.  It's also longer.

https://codereview.appspot.com/7424049/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Allows slurs to break at barlines. (issue 7424049)

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.  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.
> 
> The first suggestion just picked this off the proposed music event name.
> Here is why I consider \fake or \detached better:
> 
> when I see \broken\< or \broken\!, this does not really help me figure
> out where to use them.  \broken\! actually looks, uh, broken.  How do
> you break an end spanner?
> 
> However, \fake\< or \fake\! immediately make clear that we are talking
> about something still being used in the function of a starting and
> ending spanner, respectively.

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.

I like \detached because it describes accurately what is going on - if I were 
reading the manual and saw that \detached ( created a slur detached from 
noteheads, I'd remember the command.  \broken slightly less because we are not 
always breaking something (we are only doing that with \breakSlur).

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: reorganize self_alignment_interface (issue 7768043)


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 integral) but 
>> I try to get rid of them as fast as possible.
>> One example in the code base that I don't like: check out line 136.
> 
> In which file?  line 136 of self-alignment-interface.cc from master is empty.

separation-item.cc - sorry for the omission.

> 
>> Granted, whoever created it doesn't like it either from the looks of the 
>> comment.
>> It makes the code harder to read, maintain and understand.
>> The worst offender by far is the metronome mark - there are so many 
>> exceptions
>> concerning who its parent is that it leads to actual problems with layout in 
>> certain cases.
> 
> Sure, that's no good at all.
> 
>> I definitely like your idea of coming up with a single function, though.  
>> Perhaps try the following:
>> 
>> -) always decompose axis-groups into elements (recursively if need be)
> 
> What do you mean by axis-groups?  'hims' (a vector of grobs that me
> shoulld be aligned to)?
> 
>> -) create a non_musical flag that, if set, weeds out all grobs where 
>> non-musical is set to #t
> 
> I'm not quite surehow non-musical grobs are related to alignment code.
> Do you mean that this flag would be responsible for "getting rid of
> PaperColumn parent"?
> 

I'll try to propose a patch later today - it's easier to do that than 
explaining with words.

Cheers,
MS


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Allows slurs to break at barlines. (issue 7424049)

"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 start or end.  When using \unfoldRepeats, the fake
slur starts and ends will actually get dropped.

If we have something like

g f e d( 
\repeat { c d) e f ( }
\alternatives {
  { g) a b( a \fake) }
  { \fake( e) d c( d \fake) }
  { \fake( d) c d( e }
}
d c) d c

Then when doing \unfoldRepeats, all fakes are removed and the remaining
non-faked slur end points are actually combined instead of getting their
respective slurs stopped short at the discontinuity of a repeat bar
line.

> I like \detached because it describes accurately what is going on - if
> I were reading the manual and saw that \detached ( created a slur
> detached from noteheads, I'd remember the command.

But it doesn't.  It provides a temporary artificially detached start or
end point of a slur.  It is not the slur that is detached but rather its
true anchor elsewhere.

> \broken slightly less because we are not always breaking something (we
> are only doing that with \breakSlur).

Not even then.  The name is not accurate.

I'll agree that \fake is somewhat cheesy.  But it's nicer than
\onlyWhenNotUnfolded or \whenFolded or so.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Allows slurs to break at barlines. (issue 7424049)

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 fake
>> slur", which is not the case.
> 
> It makes a fake slur start or end.

The word "fake" still doesn't sit right with me...  There is nothing fake about 
the slur:

{ a \fake ( b c d ) }

It is real.  The function, to me, should describe an attribute of the slur.  
The slur looks detached and broken, but not fake.

There are commands like slurDashed, slurDotted, etc. that describe what the 
output will be like.  I think it's important to stay in that logic.  If we're 
going to use this for many spanners, my vote would be \broken.  The slurs look 
broken, and things like beams and hairpins will definitely look broken as well 
if we split them using the same sort of algorithm.  To me, something can look 
"broken" and this designation does not have any bearing on if all the pieces 
are there or not.  It is a quality of the object.

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Allows slurs to break at barlines. (issue 7424049)


>> 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.
> How do you break an end spanner?
> 
> However, \fake\< or \fake\! immediately make clear that we are
> talking about something still being used in the function of a
> starting and ending spanner, respectively.  I like it somewhat
> better than \detached, but of course the latter is a bit more
> dignified.  It's also longer.

Hmm, I don't like \detached.  It has no connection to a partial slur
whatsoever.  Since \partial is already taken, what about \cut?  The
spanner gets cut a bit, right?


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Allows slurs to break at barlines. (issue 7424049)


> 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

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Allows slurs to break at barlines. (issue 7424049)


> 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 list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Allows slurs to break at barlines. (issue 7424049)

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 problem with \cut is that it is both a verb and adjective - the thing looks 
"cut", but people might think that cutting is done.
As for start/end, all spanners are started and ended by definition, so this may 
be confusing.

My vote:

1) \broken
2) \detached
3) \cut
4) \alignSpannerToNonMusicalPaperColumn
5) \fake

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Allows slurs to break at barlines. (issue 7424049)

"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 something.  I would think "this makes
>>> a fake slur", which is not the case.
>> 
>> It makes a fake slur start or end.
>
> The word "fake" still doesn't sit right with me...  There is nothing
> fake about the slur:
>
> { a \fake ( b c d ) }

Mike, that code does not even make any sense.  You would not place a
fake slur start or fake slur end anywhere except right after or right
before a visual discontinuity from a repeat construct.  You probably did
not understand what I wrote, probably because "it makes a fake slur
start or end" is not grammatically clear.  I mean "It makes a fake
slur-start or a fake slur-end" by that.

> It is real.

The slur is real.  The end point isn't.

> The function, to me, should describe an attribute of the slur.

But it doesn't.  It describes an attribute of its visual start or end
point.

> The slur looks detached and broken, but not fake.

But the attachment is fake, and the slur will get properly attached to
the proper end points when repeats are unfolded.

> There are commands like slurDashed, slurDotted, etc. that describe
> what the output will be like.

And the output will be like that even when repeats are unfolded.

> I think it's important to stay in that logic.  If we're going to use
> this for many spanners, my vote would be \broken.

But it is not the slur that is "broken" but rather its visual connection
to _one_ or even _two_ of its end points.  You can perfectly well and
meaningfully have an alternative written as

{ \fake\( c d e f \fake\) }

and when unfolding, the phrasing slur will start at some point preceding
this passage and end at some point succeeding it.

> The slurs look broken,

If you want to, but the whole of
( \broken) \broken( \broken) \broken( )
is just _one_ slur broken into three pieces, not one whole slur and two
broken slurs.  That logic is more apparent with writing
( \fake) \fake( \fake) \fake( )

The breaking occurs at artificial points not related to the music
function of the slur, and it will get dissolved when unfolding repeats.

The break of the slur does not occur where \broken is written, but
rather it is at a visual discontinuity logically connected with matching
pairs of \broken) ... \broken(.  Your above example suggests that this
relation does not seem clear to you.

> and things like beams and hairpins will definitely look broken as well
> if we split them using the same sort of algorithm.

Sure, and again the split will be between matching pairs of artificial
end and start points that are not logical end and start points and will
disappear when repeats are unfolded and the broken construct gets joined
visually as well as logically.

> To me, something can look "broken" and this designation does not have
> any bearing on if all the pieces are there or not.  It is a quality of
> the object.

No, it is a quality of the respective visual (but not logical) start and
end points.  And I would prefer a naming choice that makes it easier for
people to understand what they are doing.  You are making a strong case
for this being hard enough to make it prudent to avoid fallacious
naming.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Allows slurs to break at barlines. (issue 7424049)