Re: problem with \with-dimensions

2013-03-17 Thread Werner LEMBERG

> Is this snippet part of the documentation?

I can't remember; I think I got it from the LSR.

> If you want to achieve the positioning of two opposite fermata signs
> over a bar line (or more generally print two simultaneous
> RehearsalMark possibly with different settings), I'd suggest to use
> Neil's "multi-mark-engraver" instead.

Thanks!


Werner

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


Re: problem with \with-dimensions

2013-03-17 Thread Werner LEMBERG

> I'm not sure what changed.  [...]
>
>-7.2
>-0.25))

Exactly this is the bug, I believe.  For some unknown reasons,

  \with-dimensions #'(0 . 0) #'(0 . 0)

no longer produces a markup which has no extension.  I'll submit a bug
report.


Werner

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


Re: Change \transpose to \relative in ancient.itely (issue 7538043)

2013-03-17 Thread dak

On 2013/03/18 00:00:13, aleksandr.andreev wrote:


Sorry, I should have checked the output more carefully. (Then again,

Pál said

above that the changes "didn't matter").


Ancient music usually tries very hard to avoid ledger lines which is one
of the reasons for its multitude of clefs.  So being an octave off tends
to make the examples quite untypical.

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


Re: Change \transpose to \relative in ancient.itely (issue 7538043)

2013-03-17 Thread aleksandr . andreev

On 2013/03/16 09:09:29, dak wrote:

So many pitches are wrong in this patch that I think we should revert

it and

have it redone carefully.



I do not have push access, so I cannot do much at this point. Can you
revert it then?


Possibly using some automatism (like Frescobaldi's absolute/relative
conversions, making sure that one gets the starting pitch right).



I've never used Frescobaldi, so I don't know much about this.


As it stands, this just changes too much.



Sorry, I should have checked the output more carefully. (Then again, Pál
said above that the changes "didn't matter"). Anyway, if you want to
revert this, that is OK with me.


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


Re: alignment of unattached lyrics - opinions needed

2013-03-17 Thread Janek Warchoł
ok, here's a standalone patch that improves handling of unassociated lyrics:
https://codereview.appspot.com/7564044/
In the attachment you'll find a test file with output produced by proposed code.


foo.ly
Description: Binary data


foo.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


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

2013-03-17 Thread janek . lilypond

Reviewers: dak,

Message:
Please review.
You'll find a sample test file in tracker issue:
http://code.google.com/p/lilypond/issues/detail?id=3254

Description:
don't abort aligning when grob's parent is a PaperColumn

This results in all lyrics being aligned according to self-alignment-X,
including unassociated lyrics that were previously all left-aligned.

this should pass regtests with expected differencies in the following
files:
lyrics centered instead of left-aligned:
alignment-order.ly
midi/lyrics-addlyrics-midi.ly
page-spacing-nonstaff-lines-between.ly
page-spacing-nonstaff-lines-top.ly
lyric-no-association-rhythm.ly
hairpin-ending.ly
markup-special-characters.ly
span-bar.ly
lyric-tweak.ly
instrument-name.ly
instrument-name-pedal-lyrics.ly

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

Affected files:
  M lily/self-alignment-interface.cc


Index: lily/self-alignment-interface.cc
diff --git a/lily/self-alignment-interface.cc  
b/lily/self-alignment-interface.cc
index  
59adfc3e6ca04d878349f6e3425843c703694c45..c3c8d6cfa01278afcd9ea9274d98b259d2b2cc5a  
100644

--- a/lily/self-alignment-interface.cc
+++ b/lily/self-alignment-interface.cc
@@ -131,10 +131,17 @@ SCM
 Self_alignment_interface::aligned_on_parent (Grob *me, Axis a)
 {
   Grob *him = me->get_parent (a);
-  if (Paper_column::has_interface (him))
-return scm_from_double (0.0);

-  Interval he = him->extent (him, a);
+  Interval he;
+  if (Paper_column::has_interface (him))
+// PaperColumn extents aren't reliable (they depend on size and  
alignment
+// of grobs that are children of the PaperColumn), so we cannot use  
them.

+// Therefore we just fake an average NoteHead extent.
+// This situation (i.e. having PaperColumn as a parent) happens for  
example

+// for unassociated lyrics (i.e. lyrics without associatedVoice).
+he = Interval (0, 1.4);
+  else
+he = Interval (him->extent (him, a));

   SCM sym = (a == X_AXIS) ? ly_symbol2scm ("self-alignment-X")
 : ly_symbol2scm ("self-alignment-Y");



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


Re: Fw: problem with \with-dimensions

2013-03-17 Thread Thomas Morley
2013/3/17 Werner LEMBERG :
>
> May I ask for a reply?  It's rather unusual on this list that
> something stays uncommented :-)
>
>
> Werner

Hi Werner,

I'm not sure what changed.
Though, testing the snippet below with 2.16.2 and 2.17.12 (it will
work for both) you'll notice a collision with 2.16.2 and not with the
newer version.
With 2.17.12 there's a lot of white space ...

\markup #(lilypond-version)

  { \voiceTwo c2  c\ }

  \relative c'' {
c1
\override Score.RehearsalMark #'extra-offset =
  #(cons 0 (if (and (> (cadr (ly:version)) 16)
   (>= (caddr (ly:version)) 12))
   -7.2
   -0.25))
\mark \markup {
  \with-dimensions #'(0 . 0) #'(0 . 0)
  {
\column {
  \musicglyph #"scripts.ufermata"
  \vspace #1
  \musicglyph #"scripts.dfermata"
}
  }
}
\bar "|."
  }

Sorry to be of not more help,
  Harm

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


Re: problem with \with-dimensions

2013-03-17 Thread Xavier Scheuer
On 15 March 2013 09:12, Werner LEMBERG  wrote:
>
> [git 1b5411df from today]
>
>
> This snippet
>
>   \relative c'' {
> c1
>   \override Score.RehearsalMark.break-visibility = #end-of-line-visible
>   \override Score.RehearsalMark.extra-offset = #'(0 . -.25)
> \mark \markup {
>   \with-dimensions #'(0 . 0) #'(0 . 0) {
> \column {
>   \musicglyph #"scripts.ufermata"
>   \vspace #1
>   \musicglyph #"scripts.dfermata"
> }
>   }
> } \bar "|."
>   }
>
> no longer works as expected, see image.  At least with 2.17.0, I get
> the fermatas correctly positioned (using old syntax, of course).  Has
> something changed?  Is this a bug?

Hi Werner,

Is this snippet part of the documentation?
If you want to achieve the positioning of two opposite fermata signs
over a bar line (or more generally print two simultaneous RehearsalMark
possibly with different settings), I'd suggest to use Neil's
"multi-mark-engraver" instead.

I made a request to add this feature in LilyPond by default and this is
now one of the most starred issue of the tracker (many French users
would like this).
http://code.google.com/p/lilypond/issues/detail?id=3166

Otherwise, yes, I think this is a bug but I think Mike is already
taking care of it (IIUC last mails about skylines etc.), with the help
of David and Keith (IIRC).

Cheers,
Xavier

-- 
Xavier Scheuer 

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


Fw: problem with \with-dimensions

2013-03-17 Thread Werner LEMBERG

May I ask for a reply?  It's rather unusual on this list that
something stays uncommented :-)


Werner

--- Begin Message ---

[git 1b5411df from today]


This snippet

  \relative c'' {
c1
  \override Score.RehearsalMark.break-visibility = #end-of-line-visible
  \override Score.RehearsalMark.extra-offset = #'(0 . -.25)
\mark \markup {
  \with-dimensions #'(0 . 0) #'(0 . 0) {
\column {
  \musicglyph #"scripts.ufermata"
  \vspace #1
  \musicglyph #"scripts.dfermata"
}
  }  
} \bar "|."
  }

no longer works as expected, see image.  At least with 2.17.0, I get
the fermatas correctly positioned (using old syntax, of course).  Has
something changed?  Is this a bug?


Werner
<>--- End Message ---
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Remove obscure GNOME-backend related commands from Emacs LilyPond-mode (issue 7583044)

2013-03-17 Thread janek . lilypond

LGTM

https://codereview.appspot.com/7583044/

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


Re: reorganize self_alignment_interface - part 1 (issue 7768043)

2013-03-17 Thread janek . lilypond

ok, now i see that i've unnecessarily mixed two different things:
rewriting self-alignment-interface (this patch) and changing behaviour
of unassociated LyricTexts
(http://lists.gnu.org/archive/html/lilypond-devel/2013-03/msg00231.html).
 These changes are orthogonal, and i'll keep them separated in next
patchsets.

JAnek

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

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


Re: alignment of unattached lyrics - opinions needed

2013-03-17 Thread Janek Warchoł
Hi hackers,

(replies are not in chronological order)

On Sun, Mar 17, 2013 at 11:21 AM, m...@mikesolomon.org
 wrote:
> I saw in one of your patch sets that you use the word "parent"
> to name a function that takes grobs me and him.  If there is
> no longer a parental relationship built into the function,
> it's worth changing the name of the function.

Definitely.  If you look closely you'll see that i've had written a
TODO comment about this very thing ;)

On Sun, Mar 17, 2013 at 12:32 PM, m...@mikesolomon.org
 wrote:
> Janek - what would an appropriate note-column be?  If there are several, how
> do we know from user input which one the lyric should align to?

Well, if there is a NoteColumn at the same musical moment we can
assume that the lyric should be aligned to it.  The problem appears
when there is *no* NoteColumn at the musical moment when the lyric
appears (I don't imagine any situation in which for one lyric there
would be several NoteColums to choose from).
An example:
<<
  { c'4 d'2 e'4 }
  \new Lyrics \lyricmode { \skip 4 la4 li4 }
>>

"la" happens one quarter note after the beginning of the piece, which
is the same musical moment as the half note d, so we can assume it
should be aligned to it.  "li" appears a quarter note later, and
there's no NoteColumn starting at that moment.  There's no object to
which "li" should be aligned - there's nothing at this musical moment
except a PaperColumn containing this LyricText.

Anyway, i agree that aligning LyricTexts happening at some point of
time to notecolumns that happen at the same point of time should not
require associating voices.

On Sun, Mar 17, 2013 at 2:57 PM, David Kastrup  wrote:
>"Trevor Daniels"  writes:
>> The whole point of using explicit rhythms with lyrics is to position
>> them when they should _not_ be aligned with the rhythm of notes.
>
> It's not the "whole point".  Another point is to be able to
> enter/manipulate correct lyrics independent from notes.

I see that.  However,

On Sat, Mar 16, 2013 at 12:36 PM, Trevor Daniels  wrote:
> Well, we need to be able to control the left/center alignment depending on
> whether the syllable extends over several or just one note column

this is exactly the problem with unassociated lyrics.  Without an
associatedVoice i don't quite know how to determine if a syllable is a
melisma or not (-> should it be left-aligned or centered?).  We would
have to count NoteColumns happening between consecutive LyricTexts,
but how to do that?  Is this possible at all?

On Sun, Mar 17, 2013 at 2:38 PM, Trevor Daniels  wrote:
> The thing we are lacking is the ability to self-align them on that point
> with either center or left alignment, or better, any real alignment.

A basic solution to this problem was already present in patchset 1 of
https://codereview.appspot.com/7768043/
What i don't know is how to grab the respective notecolumn (i've tried
get_column () but it didn't work for me).
So, here's where i need help: *how to get a NoteColumn when i have a
pointer to a PaperColumn?*

suggestions appreciated.
Janek

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


Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)

2013-03-17 Thread thomasmorley65

On 2013/03/17 16:25:55, Joseph Rushton Wakeling wrote:

On 2013/03/17 14:37:52, thomasmorley65 wrote:



> > I want to say that they are always printed with the line going up
irrespective
> > of the side of the staff, but I could be wrong.



There are Ferneyhough scores with dynamics above the staff -- some of

the piano

works (e.g. Lemma-Icon-Epigram), and some of the vocal works.  See

e.g. the

second movement of his 4th String Quartet which has a part for

soprano:

http://www.youtube.com/watch?v=hVaDOz7bWU0



In this you see flared hairpins above the staff, and also dynamic

brackets above

the staff (e.g. at about 1:33 where there's a great long  bracket

above the

soprano part).


Thanks!
And while above the staff dynamic brackets have the hook down.

https://codereview.appspot.com/7615043/

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


Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)

2013-03-17 Thread thomasmorley65

On 2013/03/17 12:42:02, mike7 wrote:


You'd have to have a wrapper function with a call to ly:scale-stencil

with a -1

to the Y axis based on the direction of the grob.


Sure.
Or in
(define (my-c-p-s ...
as it is done for `decresc?´


This is doable, but I'd wait to see from someone who knows how these

things work

if this is actually how they are printed.
I want to say that they are always printed with the line going up

irrespective

of the side of the staff, but I could be wrong.


The only Ferneyhough-score I've at home prints the dynamics always below
the system.
("Cassandra's Dream Song" for Solo Flute, Edition Peters, 1975)
Perhaps ask on the user-list.


Thanks for the review!


You're welcome.
Most of your patches are work with C++, which I don't know.
Since the current one provides some very nice feature using scheme, I
had a closer look.
Perhaps you noticed that I already used this approach to answer an
user-question.

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


Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)

2013-03-17 Thread m...@mikesolomon.org

On 17 mars 2013, at 17:46, joseph.wakel...@gmail.com wrote:

> On a related issue: one thing that's probably clear looking at
> Ferneyhough scores is the way in which the vertical placement of hairpin
> endpoints is strongly coupled with the vertical placement of dynamic
> marks.
> 
> I don't think it's really appropriate to bundle all of this together
> into one feature request, but it would probably be useful as a
> complementary feature request to do some re-evaluation of Lilypond's
> vertical placement of hairpin end-points, and whether it's possible to
> automate the placement of angled hairpins so as to optimize the relative
> positions of hairpin start- and endpoints and nearby dynamic marks.
> 
> N.B. this is useful for all music, not just Ferneyhough.  It's a fairly
> consistent bugbear of mine that hairpin start- and endpoints are not
> better placed relative to dynamic marks.
> 
> I think this has already been touched on to an extent in the discussion
> above ... ?
> 
> https://codereview.appspot.com/7615043/

It's more swingable now that skylines are based on stencils for many grobs 
instead of extents.
This is the sorta thing I know how to do but that'd take a while.
If you can open a tracker issue w/ the full request, I'll try to get to it (I 
have some time next week and then again in late April).

Cheers,
MS


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


Re: Removes '-signs in vectors - follow-up (issue 7834043)

2013-03-17 Thread thomasmorley65

On 2013/03/17 16:24:16, janek wrote:

This patch needs a review from someone more knowledgeable in

docs/snippets than

me.


+1

All I did was:
I copied the files from /Documentation/snippets into
/Documentation/snippets/new.
Removed the '-signs, deleted the comments above the old
version-statement, changed the version and ran
scripts/auxiliar/makelsr.py

Concerning the version: The whole point of the issue is that '-signs in
vectors are superfluous.
Also, they were superfluous with former versions, perhaps always.
So I choosed 2.17.15 somewhat arbitrary, though, I see no problem here.

I didn't touch anything else. All other changes were made by
scripts/auxiliar/makelsr.py

https://codereview.appspot.com/7834043/

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


Re: Documents make-partial-ellipse-stencil (issue 7497046)

2013-03-17 Thread Marc Hohl

Am 17.03.2013 17:27, schrieb m...@mikesolomon.org:


On 17 mars 2013, at 17:22, m...@hohlart.de wrote:


Just one nitpick.


https://codereview.appspot.com/7497046/diff/1/scm/stencil.scm
File scm/stencil.scm (right):

https://codereview.appspot.com/7497046/diff/1/scm/stencil.scm#newcode251
scm/stencil.scm:251: "Makes a list of angle/radius paris at intervals of
PI/2 for
s/paris/pairs/



Too much time in France...
Pretty soon I'll be writing sentences like "angle/radius godewaersvelde"


Well, this will make the reviewing process *very* interesting ;-)



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


Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)

2013-03-17 Thread m...@mikesolomon.org

On 17 mars 2013, at 17:25, joseph.wakel...@gmail.com wrote:

> 
> 
> Final remark: while it's nice to see Ferneyhough getting namechecked
> might it be worth naming this alteration as flared-hairpin rather than
> ferneyhough-hairpin?

My suggestion was flairpin, which is infinitely cheesier and thus way cooler.

Cheers,
MS

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


Re: Issue 2924: Doc: \startMeasureCount and \stopMeasureCount needs documenting (issue 7678047)

2013-03-17 Thread janek . lilypond

LGTM


https://codereview.appspot.com/7678047/

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


Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)

2013-03-17 Thread joseph . wakeling

On a related issue: one thing that's probably clear looking at
Ferneyhough scores is the way in which the vertical placement of hairpin
endpoints is strongly coupled with the vertical placement of dynamic
marks.

I don't think it's really appropriate to bundle all of this together
into one feature request, but it would probably be useful as a
complementary feature request to do some re-evaluation of Lilypond's
vertical placement of hairpin end-points, and whether it's possible to
automate the placement of angled hairpins so as to optimize the relative
positions of hairpin start- and endpoints and nearby dynamic marks.

N.B. this is useful for all music, not just Ferneyhough.  It's a fairly
consistent bugbear of mine that hairpin start- and endpoints are not
better placed relative to dynamic marks.

I think this has already been touched on to an extent in the discussion
above ... ?

https://codereview.appspot.com/7615043/

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


Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)

2013-03-17 Thread Joseph Rushton Wakeling
On 03/17/2013 05:28 PM, m...@mikesolomon.org wrote:
> My suggestion was flairpin, which is infinitely cheesier and thus way cooler.

I know, but ... at the end of the day, less clear in meaning than either
ferneyhough-hairpin or flared-hairpin.  Sad but IMO true. :-P


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


Re: Make a PostEvents container class for packaging several postevents (issue 7742044)

2013-03-17 Thread janek . lilypond

LGTM

https://codereview.appspot.com/7742044/

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


Issue 3251: set-default-paper-size bleeds over to subsequent file compilations (issue 7568048)

2013-03-17 Thread janek . lilypond

I like the description.  It's very clear.
LGTM
thanks!
Janek

https://codereview.appspot.com/7568048/

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


Re: Script for running pixel-based regtest comparisons (issue 7578046)

2013-03-17 Thread janek . lilypond

LGTM

https://codereview.appspot.com/7578046/

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


Re: bar line interface / repat structure considerations

2013-03-17 Thread Marc Hohl

Am 13.03.2013 17:05, schrieb Janek Warchoł:

Hi Marc&all,

On Wed, Mar 13, 2013 at 10:09 AM, Marc Hohl  wrote:

make
sure you sit comfortable and have a nice cup of coffee, tea or whatever
around...


these words actually reminded me that i had a tea waiting, and thanks
to you it didn't get totally cold before i drank it :)


You're welcome ;-)


a) replace the current mechanism by a command
(define-bar-line 
( :prebreak 
:postbreak 
:span-bar 
:prebreak-span 
:postbreak-span ))

where :prebreak, :postbreak, :spanbar, :prebreak-span and :postbreak-span
arguments are optional,and we define (in quasi-Lua syntax :-)

 =  or 
 =  or #f

 =  or 
 =  or 
 =  or 


I like this, except that i'm not sure whether the keywords :prebreak
:postbreak etc don't clutter the view too much.


I am not sure whether there are alternatives despite from the
method we use now (a list of strings in which the order of the
arguments is predefined - which is overkill for upto six arguments IMHO.

On the other hand, I don't think that many users need their own
bar line definitions, and then again, the view may be cluttered,
but easy to understand.

Marc

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


Re: Documents make-partial-ellipse-stencil (issue 7497046)

2013-03-17 Thread janek . lilypond

LGTM

https://codereview.appspot.com/7497046/

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


Documents make-partial-ellipse-stencil (issue 7497046)

2013-03-17 Thread marc

Just one nitpick.


https://codereview.appspot.com/7497046/diff/1/scm/stencil.scm
File scm/stencil.scm (right):

https://codereview.appspot.com/7497046/diff/1/scm/stencil.scm#newcode251
scm/stencil.scm:251: "Makes a list of angle/radius paris at intervals of
PI/2 for
s/paris/pairs/

https://codereview.appspot.com/7497046/

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


Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)

2013-03-17 Thread joseph . wakeling

On 2013/03/17 14:37:52, thomasmorley65 wrote:

> This is doable, but I'd wait to see from someone who knows how these

things

work
> if this is actually how they are printed.
> I want to say that they are always printed with the line going up

irrespective

> of the side of the staff, but I could be wrong.



The only Ferneyhough-score I've at home prints the dynamics always

below the

system.


There are Ferneyhough scores with dynamics above the staff -- some of
the piano works (e.g. Lemma-Icon-Epigram), and some of the vocal works.
See e.g. the second movement of his 4th String Quartet which has a part
for soprano:
http://www.youtube.com/watch?v=hVaDOz7bWU0

In this you see flared hairpins above the staff, and also dynamic
brackets above the staff (e.g. at about 1:33 where there's a great long
 bracket above the soprano part).

The more general remark is that even if Ferneyhough did only place his
dynamic markings below the staff, you couldn't assume that would remain
true of all composers wanting to use Ferneyhough-like dynamic indicators
in their scores :-)

Final remark: while it's nice to see Ferneyhough getting namechecked
might it be worth naming this alteration as flared-hairpin rather than
ferneyhough-hairpin?

https://codereview.appspot.com/7615043/

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


Re: Removes '-signs in vectors - follow-up (issue 7834043)

2013-03-17 Thread janek . lilypond

This patch needs a review from someone more knowledgeable in
docs/snippets than me.


https://codereview.appspot.com/7834043/diff/2001/Documentation/snippets/new/applying-note-head-styles-depending-on-the-step-of-the-scale.ly
File
Documentation/snippets/new/applying-note-head-styles-depending-on-the-step-of-the-scale.ly
(right):

https://codereview.appspot.com/7834043/diff/2001/Documentation/snippets/new/applying-note-head-styles-depending-on-the-step-of-the-scale.ly#newcode1
Documentation/snippets/new/applying-note-head-styles-depending-on-the-step-of-the-scale.ly:1:
\version "2.17.15"
I'm no expert on documentation and snippets, but this change (and some
other ones, too) look suspicious.

https://codereview.appspot.com/7834043/diff/2001/Documentation/snippets/preventing-final-mark-from-removing-final-tuplet.ly
File
Documentation/snippets/preventing-final-mark-from-removing-final-tuplet.ly
(right):

https://codereview.appspot.com/7834043/diff/2001/Documentation/snippets/preventing-final-mark-from-removing-final-tuplet.ly#newcode27
Documentation/snippets/preventing-final-mark-from-removing-final-tuplet.ly:27:

this looks suspicious to my eyes (again, i'm no expert on snippets and
docs)

https://codereview.appspot.com/7834043/diff/2001/Documentation/snippets/separating-key-cancellations-from-key-signature-changes.ly
File
Documentation/snippets/separating-key-cancellations-from-key-signature-changes.ly
(right):

https://codereview.appspot.com/7834043/diff/2001/Documentation/snippets/separating-key-cancellations-from-key-signature-changes.ly#newcode47
Documentation/snippets/separating-key-cancellations-from-key-signature-changes.ly:47:
} % begin verbatim
...and this one, too.

https://codereview.appspot.com/7834043/

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


Re: Documents make-partial-ellipse-stencil (issue 7497046)

2013-03-17 Thread m...@mikesolomon.org

On 17 mars 2013, at 17:22, m...@hohlart.de wrote:

> Just one nitpick.
> 
> 
> https://codereview.appspot.com/7497046/diff/1/scm/stencil.scm
> File scm/stencil.scm (right):
> 
> https://codereview.appspot.com/7497046/diff/1/scm/stencil.scm#newcode251
> scm/stencil.scm:251: "Makes a list of angle/radius paris at intervals of
> PI/2 for
> s/paris/pairs/
> 

Too much time in France...
Pretty soon I'll be writing sentences like "angle/radius godewaersvelde"


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


Re: Prohibit non-postevents from music functions to be used as post-event (issue 7866043)

2013-03-17 Thread janek . lilypond

commit message says:

Prohibit non-postevents from music functions to be used
as post-event


Do i understand correctly that this sentence is equivalent to "Prohibit
non-postevents returned by music functions to be used as post-events"?
If so, i'd prefer that second wording; the original looks less
straighforward to me.

thanks,
Janek

https://codereview.appspot.com/7866043/

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


Re: Change name of Patch Handler to Patch Meister in CG (issue 7498045)

2013-03-17 Thread janek . lilypond

LGTM

https://codereview.appspot.com/7498045/

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


Check for mfplain.mp (issue 3233). (issue 7789047)

2013-03-17 Thread janek . lilypond

Hi,

maybe for other developers there is no problem, but for me it would be
clearer if the commit message said

configure: check for mfplain.mp (issue 3233).

thanks,
Janek

https://codereview.appspot.com/7789047/

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


Make \relative { ... } interpret the first pitch as an absolute one (issue 7518047)

2013-03-17 Thread janek . lilypond

LGTM

https://codereview.appspot.com/7518047/

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


Re: alignment of unattached lyrics - opinions needed

2013-03-17 Thread David Kastrup
"Trevor Daniels"  writes:

> m...@mikesolomon.org wrote Sunday, March 17, 2013 11:32 AM
>
>
>>On 17 mars 2013, at 12:29, Neil Puttock  wrote:
>>
>>> 
>>> On Mar 17, 2013 11:10 AM, "m...@mikesolomon.org"
>>>  wrote:
>>> 
 In the stop_translation_timestep method of the lyric engraver,
 lyrics are
given note heads as parents.  Could you send a minimal where the
 lyrics are unassociated from note-heads?
>>> 
>>> \lyrics { do re mi }
>>> 
>>> If there's no associated voice the lyrics have no parent until the
>>> Paper_column_engraver steps in.
>
>> Cool cool - thanks!
>> Then, going back to Janek's question, Janek - what would an
>> appropriate note-column be?  If there are several, how do we know
>> from user > input which one the lyric should align to?
>
> The whole point of using explicit rhythms with lyrics is to position
> them when they should _not_ be aligned with the rhythm of notes.

It's not the "whole point".  Another point is to be able to
enter/manipulate correct lyrics independent from notes.

> The syllables should be positioned according the the rhythm values
> attached to them.  This may or may not coincide with a note at that
> point.

Quite so.  All points of time that can be found in the lyrics should be
aligned to the respective note columns.  All points of time not found in
the lyrics are not relevant (meaning that notes should not get pushed to
the right to accommodate lyrics anchored to an earlier point of time
and/or notecolumn).

> The thing we are lacking is the ability to self-align them on that
> point with either center or left alignment, or better, any real
> alignment.

Yes, that's one thing.  Another is that the concept of an associated
voice does not make all that much sense to me.  The important relation
for \addlyrics between voice and lyrics is to reestablish the timing of
the lyrics.  The things that happen beyond that are hard to fathom.

-- 
David Kastrup

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


Re: alignment of unattached lyrics - opinions needed

2013-03-17 Thread Trevor Daniels

m...@mikesolomon.org wrote Sunday, March 17, 2013 11:32 AM


>On 17 mars 2013, at 12:29, Neil Puttock  wrote:
>
>> 
>> On Mar 17, 2013 11:10 AM, "m...@mikesolomon.org"  
>> wrote:
>> 
>>> In the stop_translation_timestep method of the lyric engraver, lyrics are 
>>>given note heads as parents.  Could you send a minimal where the lyrics are 
>>>unassociated from note-heads?
>> 
>> \lyrics { do re mi }
>> 
>> If there's no associated voice the lyrics have no parent until the 
>> Paper_column_engraver steps in.

> Cool cool - thanks!
> Then, going back to Janek's question, Janek - what would an appropriate 
> note-column be?  If there are several, how do we know from user > input which 
> one the lyric should align to?

The whole point of using explicit rhythms with lyrics is to position them 
when they should _not_ be aligned with the rhythm of notes.  The syllables 
should be positioned according the the rhythm values attached to them.
This may or may not coincide with a note at that point.

The thing we are lacking is the ability to self-align them on that point
with either center or left alignment, or better, any real alignment.

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


PATCHES - countdown for 20th March - 19:00 GMT

2013-03-17 Thread James
Hello,

*Countdown – March 20th 2013 – 19:00 GMT* *
* *
* *
* *
*




 
3238
Build Julien Rioux Push Patch: Fixup default prefix replacement in
aclocal.m4  
3237
Enhancement David Kastrup Push Patch: Harmonize point-and-click information
for #xxx and $xxx
3234
Enhancement c/o James Lowe Push Make midiMaximumVolume take effect without
initial dynamic
1698
Defect Mike Solomon Push Slurs and ties are not correct over repeats




 
3134
Enhancement Mike Solomon Countdown Patch: Removes the translate_axis call
from axis-group-interface outside-staff positioning.
3247
Enhancement
David Kastrup Countdown Patch: Prohibit non-postevents from music functions
to be used as post-event
3233
Build
Julien Rioux Countdown configure should check if texlive-metapost is
installed  
3010
Documentation
Thomas Morely Countdown Removes '-signs from vectors
3239
Enhancement
Janek Warchol Countdown Patch: reorganize self_alignment_interface - part 1
3204
Crash
c/o James Lowe Countdown articulate: can't compile music containing
alternatives  
3245
Enhancement
David Kastrup Countdown Patch: Make \relative { ... } interpret the first
pitch as an absolute one
3226
Enhancement
Mike Solomon Countdown Patch: Change name of Patch Handler to Patch Meister
in CG  
3244
Enhancement
David Kastrup Countdown Patch: Remove -d old-relative compatibility option
3231
Enhancement
David Kastrup Countdown Patch: Make reference pitch for \relative
non-optional  
3161
Enhancement
Mike Solomon Countdown Patch: Standardizes use of empty extents in pure
heights and skylines.




 
2924
Documentation
David Nalesnik review Doc: \startMeasureCount and \stopMeasureCount needs
documenting  
3230
Enhancement
Mike Solomon review Patch: Adds Ferneyhough hairpins to LilyPond.
3242
Ugly
Mike Solomon review Manual beaming ov

Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)

2013-03-17 Thread m...@mikesolomon.org
On 17 mars 2013, at 13:36, thomasmorle...@googlemail.com wrote:

> On 2013/03/17 07:27:37, MikeSol wrote:
>> On 2013/03/13 21:38:59, thomasmorley65 wrote:
> 
>> > https://codereview.appspot.com/7615043/diff/23001/scm/output-lib.scm
>> > File scm/output-lib.scm (right):
>> >
>> >
> 
> https://codereview.appspot.com/7615043/diff/23001/scm/output-lib.scm#newcode1061
>> > scm/output-lib.scm:1061: (thick (* thick (layout-line-thickness
> grob)))
>> > At first sight I was surprised about `layout-line-thickness´. Than I
>> remembered,
>> > it is defined in bar-line.scm
>> > How about making it public, moving it to lily-library.scm?
>> > It could be used then in local custom-definitions.
>> > Same with `layout-blot-diameter´.
>> > I know, it's another topic, though, what do you think about it?
> 
>> Great idea!
> 
> I'd have expected _this_ change in another patch.
> At least it should be mentioned in the commit-message.

Will do.

> 
>> >
> 
> https://codereview.appspot.com/7615043/diff/23001/scm/output-lib.scm#newcode1078
>> > scm/output-lib.scm:1078:
>> > What do you think about predefining sth like
>> > ferneyhoughHairpinOn/Off
>> > constanteHairpinOn/Off
>> > in /lyproperty-init.ly?
>> > i.e.
>> > ferneyhoughHairpinOn =
>> > \override Hairpin #'stencil = #ferneyhough-hairpin
> 
>> I'm not against this idea at all - I'd like to see it proposed in a
> different
>> patch set, if possible.  I am teerible at judging UI issues
> because I hack
>> so much.  It is true that shortcuts help, but there are many, many
> overrides
>> that are shortcut-worthy.  I'm not sure what standard determines which
> overrides
>> should get shortcuts and which shouldn't, so I leave that to a future
> (and
>> important!) conversation.
> 
> ok
> 
>> >
> 
> https://codereview.appspot.com/7615043/diff/23001/scm/output-lib.scm#newcode1082
>> > scm/output-lib.scm:1082: (define-public constante-hairpin
>> > I'm not happy with constante-hairpin.
> [...]
> 
>> The constante indication means that the dynamic should not change at
> all, so the
>> decision to use a hairpin that grows in a given direction is
> admittedly a hack.
>> The idea of dimMolto (or crescMolto) with constante is a contradiction
> (get very
>> quiet while not changing dynamic).
> 
> Yep.
> And this contradiction _is_ disturbing.

Agreed.

> 
>> Insofar as a hairpin represents a change in
>> dynamics, constante should, in theory, be a different grob.  My
> solution is not
>> ideal, but I think it is an OK middle-ground short of the creation of
> a separate
>> grob.  If people think it is too hackish, I will propose a new patch
> with a
>> Constante grob (or make the hairpin grow-direction = #CENTER default
> to
>> constante, which'd be difficult but doable).
> 
> For now I'd tend to let it as it stands.
> Nevertheless, it _is_ hackish and I think it should be replaced by one
> of your proposals later.

Agreed.

> 
> 
> Though, how about:
> 
>> Is it possible to make the hook-direction depending on the position of
> the
>> Hairpin i.e below or above the staff?
> ?
> 
> 

You'd have to have a wrapper function with a call to ly:scale-stencil with a -1 
to the Y axis based on the direction of the grob.
This is doable, but I'd wait to see from someone who knows how these things 
work if this is actually how they are printed.
I want to say that they are always printed with the line going up irrespective 
of the side of the staff, but I could be wrong.

Thanks for the review!

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


Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)

2013-03-17 Thread thomasmorley65

On 2013/03/17 07:27:37, MikeSol wrote:

On 2013/03/13 21:38:59, thomasmorley65 wrote:



> https://codereview.appspot.com/7615043/diff/23001/scm/output-lib.scm
> File scm/output-lib.scm (right):
>
>


https://codereview.appspot.com/7615043/diff/23001/scm/output-lib.scm#newcode1061

> scm/output-lib.scm:1061: (thick (* thick (layout-line-thickness

grob)))

> At first sight I was surprised about `layout-line-thickness´. Than I
remembered,
> it is defined in bar-line.scm
> How about making it public, moving it to lily-library.scm?
> It could be used then in local custom-definitions.
> Same with `layout-blot-diameter´.
> I know, it's another topic, though, what do you think about it?



Great idea!


I'd have expected _this_ change in another patch.
At least it should be mentioned in the commit-message.


>


https://codereview.appspot.com/7615043/diff/23001/scm/output-lib.scm#newcode1078

> scm/output-lib.scm:1078:
> What do you think about predefining sth like
> ferneyhoughHairpinOn/Off
> constanteHairpinOn/Off
> in /lyproperty-init.ly?
> i.e.
> ferneyhoughHairpinOn =
> \override Hairpin #'stencil = #ferneyhough-hairpin



I'm not against this idea at all - I'd like to see it proposed in a

different

patch set, if possible.  I am teerible at judging UI issues

because I hack

so much.  It is true that shortcuts help, but there are many, many

overrides

that are shortcut-worthy.  I'm not sure what standard determines which

overrides

should get shortcuts and which shouldn't, so I leave that to a future

(and

important!) conversation.


ok


>


https://codereview.appspot.com/7615043/diff/23001/scm/output-lib.scm#newcode1082

> scm/output-lib.scm:1082: (define-public constante-hairpin
> I'm not happy with constante-hairpin.

[...]


The constante indication means that the dynamic should not change at

all, so the

decision to use a hairpin that grows in a given direction is

admittedly a hack.

The idea of dimMolto (or crescMolto) with constante is a contradiction

(get very

quiet while not changing dynamic).


Yep.
And this contradiction _is_ disturbing.


Insofar as a hairpin represents a change in
dynamics, constante should, in theory, be a different grob.  My

solution is not

ideal, but I think it is an OK middle-ground short of the creation of

a separate

grob.  If people think it is too hackish, I will propose a new patch

with a

Constante grob (or make the hairpin grow-direction = #CENTER default

to

constante, which'd be difficult but doable).


For now I'd tend to let it as it stands.
Nevertheless, it _is_ hackish and I think it should be replaced by one
of your proposals later.


Though, how about:


Is it possible to make the hook-direction depending on the position of

the

Hairpin i.e below or above the staff?

?



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


Re: alignment of unattached lyrics - opinions needed

2013-03-17 Thread David Kastrup
"m...@mikesolomon.org"  writes:

> On 17 mars 2013, at 12:29, Neil Puttock  wrote:
>
> 
> On Mar 17, 2013 11:10 AM, "m...@mikesolomon.org"
>  wrote:
>
> > In the stop_translation_timestep method of the lyric engraver,
> lyrics are given note heads as parents. Could you send a minimal
> where the lyrics are unassociated from note-heads?
>
> \lyrics { do re mi }
>
> If there's no associated voice the lyrics have no parent until the
> Paper_column_engraver steps in.
>
> Cheers,
> Neil
>
> Cool cool - thanks!
> Then, going back to Janek's question, Janek - what would an
> appropriate note-column be? If there are several, how do we know from
> user input which one the lyric should align to?

Isn't that question sort of irrelevant since all notes at the same time
step are aligned in a column anyway?

Now of course some notes may be _shifted_ in a column in order to avoid
collisions.  But I don't think that shifting the lyrics to match would
be desired.

-- 
David Kastrup


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


Re: alignment of unattached lyrics - opinions needed

2013-03-17 Thread m...@mikesolomon.org
On 17 mars 2013, at 12:29, Neil Puttock  wrote:

> 
> On Mar 17, 2013 11:10 AM, "m...@mikesolomon.org"  wrote:
> 
> > In the stop_translation_timestep method of the lyric engraver, lyrics are 
> > given note heads as parents.  Could you send a minimal where the lyrics are 
> > unassociated from note-heads?
> 
> \lyrics { do re mi }
> 
> If there's no associated voice the lyrics have no parent until the 
> Paper_column_engraver steps in.
> 
> Cheers,
> Neil
> 
Cool cool - thanks!
Then, going back to Janek's question, Janek - what would an appropriate 
note-column be?  If there are several, how do we know from user input which one 
the lyric should align to?

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


Re: alignment of unattached lyrics - opinions needed

2013-03-17 Thread Neil Puttock
On Mar 17, 2013 11:10 AM, "m...@mikesolomon.org" 
wrote:

> In the stop_translation_timestep method of the lyric engraver, lyrics are
given note heads as parents.  Could you send a minimal where the lyrics are
unassociated from note-heads?

\lyrics { do re mi }

If there's no associated voice the lyrics have no parent until the
Paper_column_engraver steps in.

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


Re: Issue 2924: Doc: \startMeasureCount and \stopMeasureCount needs documenting (issue 7678047)

2013-03-17 Thread david . nalesnik

On 2013/03/17 10:35:40, PhilEHolmes wrote:

I've not tested the snippets, but otherwise the patch LGTM.  I'm

assuming the

only files you actually created were the ones in snippets/new/ - the

rest came

from makelsr and make doc?


Yes, exactly.



https://codereview.appspot.com/7678047/

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


Re: alignment of unattached lyrics - opinions needed

2013-03-17 Thread m...@mikesolomon.org
On 17 mars 2013, at 11:05, Janek Warchoł  wrote:

> Hi,
> 
> On Sat, Mar 16, 2013 at 12:20 PM, David Kastrup  wrote:
>> Do we
>> really need a particular associated voice instead of being able to do
>> this with general music column alignment?
> 
> I'll write a full answer later today, but for now i can say that i
> don't know a way to do this.
> Let's say i have an unassociated LyricText grob.  It's parent is a
> PaperColumn.  Do you know how to grab an appropriate NoteColumn (if it
> exists)?
> (see self-alignment-interface.cc, line 134.  How to get a NoteColumn
> when all we have is 'him'?)
> 

Hey Janek,

Sorry for the lack of review - today is my first day off in a long time!

I saw in one of your patch sets that you use the word "parent" to name a 
function that takes grobs me and him.  If there is no longer a parental 
relationship built into the function, it's worth changing the name of the 
function.

In the stop_translation_timestep method of the lyric engraver, lyrics are given 
note heads as parents.  Could you send a minimal where the lyrics are 
unassociated from note-heads?

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


Re: Issue 2924: Doc: \startMeasureCount and \stopMeasureCount needs documenting (issue 7678047)

2013-03-17 Thread PhilEHolmes

I've not tested the snippets, but otherwise the patch LGTM.  I'm
assuming the only files you actually created were the ones in
snippets/new/ - the rest came from makelsr and make doc?

https://codereview.appspot.com/7678047/

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


Re: make doc fails

2013-03-17 Thread Phil Holmes
FWIW, this was down to me removing the very out-of-date Czech news file from 
the build.  The simple cure for problems like this is to make doc clean and try 
again.  Failing that, delete the build directory and run make, make doc again.

--
Phil Holmes


  - Original Message - 
  From: David Nalesnik 
  To: Julien Rioux 
  Cc: LilyPond Devel 
  Sent: Sunday, March 17, 2013 2:17 AM
  Subject: Re: make doc fails


  Julien,


  On Sat, Mar 16, 2013 at 7:31 PM, Julien Rioux  wrote:

On 16/03/2013 6:27 PM, David Nalesnik wrote:

  /usr/bin/python -tt
  /home/david/lilypond-git/scripts/build/create-weblinks-itexi.py >
  out-www/weblinks.itexi
  make[3]: *** No rule to make target
  `/home/david/lilypond-git/Documentation/cs/web/news-front.itexi', needed 
by
  `out-www/web.texi'.  Stop.



Try removing Documentation/cs/out-www/web.dep and running `make doc' again. 
If it succeeds but fails at the next language, repeat for each language. 
Alternatively, if all that fails, try `make doc-clean' and running `make doc' 
again.



  I ended up deleting the file in cs/ and zh/ and that did the trick.  Thanks 
very much!


  -David 


--


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


Re: alignment of unattached lyrics - opinions needed

2013-03-17 Thread Janek Warchoł
Hi,

On Sat, Mar 16, 2013 at 12:20 PM, David Kastrup  wrote:
> Do we
> really need a particular associated voice instead of being able to do
> this with general music column alignment?

I'll write a full answer later today, but for now i can say that i
don't know a way to do this.
Let's say i have an unassociated LyricText grob.  It's parent is a
PaperColumn.  Do you know how to grab an appropriate NoteColumn (if it
exists)?
(see self-alignment-interface.cc, line 134.  How to get a NoteColumn
when all we have is 'him'?)

thanks,
Janek

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


Re: Allows minimum-length to work for end-of-line spanners. (issue 7453046)

2013-03-17 Thread m...@mikesolomon.org

On 17 mars 2013, at 10:19, d...@gnu.org wrote:

> You don't fix your own work after it has been committed,

This is patently false.  Please do not write e-mails like this to a public list 
that can be read by future employers of mine that want to evaluate my integrity.

> so why would
> you fix inconsistencies afterwards that you felt ok to ignore in the
> first place?  Who is going to fix them?  "the community".  Please try
> acting as a part of "the community" instead of piling work on for "the
> community" that "somebody else (TM)" will at some time solve.
> 

"Please try acting as a part of the community" is insulting.  I fix bugs that 
I've cause and I have fixed numerous bugs that other people (including you) 
have introduced.

The more caustic your e-mails are, the more difficult it is to extract the 
useful parts from them.  Please tone down your language or, if that is too 
difficult, please send me e-mails privately.  Public e-mails of this nature 
will result eventually in my leaving the project.

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


Re: Allows minimum-length to work for end-of-line spanners. (issue 7453046)

2013-03-17 Thread dak

On 2013/03/17 07:10:23, MikeSol wrote:

On 2013/03/11 10:18:59, dak wrote:
>
> There is no point in hiding the symptoms of a problem away.  That

only

> makes things even harder in future.



I don't think this is a problem blocking the current patch.


It is a problem making the current patch ill-fitting and ill-advised.


You are right that the current multiple functions of minimum-length
are problematic.  I'm not arguing that this is someone else's
problem - I am arguing that this (like all bugs) is the community's
problem.


Since you don't care for fixing this yourself, you _are_ arguing that
this is someone else's problem.


It may take months or years to sort out the multiple naming of
properties.


It will if people just heap on new "features" that can't be made to
work consistently and blame "the community" for the lack of solid
groundwork.


This shouldn't block this patch from being pushed.


I disagree.  There is no mythical beast called "community" that
magically fixes things.  Code gets fixed by people working on that
area who are leaving the code base in a better state than they found
them.  But that's not your attitude.  Your attitude is that if the
code base is bad, that is the perfect excuse to make it worse.

You want to achieve a certain thing in an area that can't be done
cleanly due to design errors.  And you draw the "community" card for
who should be doing it.  But who should do the groundwork for your
features if not you?  Who is most intimate with the area you are
working on?  If you feel fine heaping inconsistent and incomplete
features on for the sake of getting your own work done, you are free
to do so in a branch.

I have pointed out completely undocumented code from you in the past,
like with partial elliptic stencils.  You have not bothered adding a
single line of documentation yet, and as one consequence people are
unable to use it for improving the woodwind diagrams.

You don't fix your own work after it has been committed, so why would
you fix inconsistencies afterwards that you felt ok to ignore in the
first place?  Who is going to fix them?  "the community".  Please try
acting as a part of "the community" instead of piling work on for "the
community" that "somebody else (TM)" will at some time solve.


https://codereview.appspot.com/7453046/

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


Re: big-picture question regarding Lilypond's capabilities (current and potential)

2013-03-17 Thread David Kastrup
Kieren MacMillan  writes:

> Hi David,
>
>> Why would you need absolute note entry?
>> Usually \relative has done its deed before you excise tags.
>
> That's great to know — I much prefer relative note entry.

Well, \relative is a music function that leaves behind absolute music.
So if you have

melody = \relative { ... \tag ... \tag ... }

then \melody contains only absolute music and

  \removeWithTag #'xxx \melody

will work fine.  If you do

\relative \removeWithTag ...

then things will go haywire as \relative will now be run on already
reduced music.  So as long as you apply \relative before removing
tagged/untagged music, you should get consistent results.

-- 
David Kastrup

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


Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)

2013-03-17 Thread mtsolo

On 2013/03/13 21:38:59, thomasmorley65 wrote:

Hi Mike,



sorry to be such an inch pincher.



https://codereview.appspot.com/7615043/diff/23001/scm/output-lib.scm
File scm/output-lib.scm (right):



https://codereview.appspot.com/7615043/diff/23001/scm/output-lib.scm#newcode1061

scm/output-lib.scm:1061: (thick (* thick (layout-line-thickness

grob)))

At first sight I was surprised about `layout-line-thickness´. Than I

remembered,

it is defined in bar-line.scm
How about making it public, moving it to lily-library.scm?
It could be used then in local custom-definitions.
Same with `layout-blot-diameter´.
I know, it's another topic, though, what do you think about it?


Great idea!


https://codereview.appspot.com/7615043/diff/23001/scm/output-lib.scm#newcode1078

scm/output-lib.scm:1078:
What do you think about predefining sth like
ferneyhoughHairpinOn/Off
constanteHairpinOn/Off
in /lyproperty-init.ly?
i.e.
ferneyhoughHairpinOn =
\override Hairpin #'stencil = #ferneyhough-hairpin


I'm not against this idea at all - I'd like to see it proposed in a
different patch set, if possible.  I am teerible at judging UI
issues because I hack so much.  It is true that shortcuts help, but
there are many, many overrides that are shortcut-worthy.  I'm not sure
what standard determines which overrides should get shortcuts and which
shouldn't, so I leave that to a future (and important!) conversation.


https://codereview.appspot.com/7615043/diff/23001/scm/output-lib.scm#newcode1082

scm/output-lib.scm:1082: (define-public constante-hairpin
I'm not happy with constante-hairpin.



Look at the output from:



dimMolto =
#(make-dynamic-script (markup #:normal-text #:italic "dim. molto"))



\relative c'' {
   \dynamicUp
   \override Hairpin #'stencil = #constante-hairpin
   a1 a4\dimMolto\> a a a\!
}



The "hook" is placed at the left pointing up.



Wouldn't it be better to have the hook _always_ at the right?
Perhaps by adding a boolean variable to `my-c-p-s´. Doing scaling only

while

(and scalable? decresc?).



Is it possible to make the hook-direction depending on the position of

the

Hairpin i.e below or above the staff?


The constante indication means that the dynamic should not change at
all, so the decision to use a hairpin that grows in a given direction is
admittedly a hack. The idea of dimMolto (or crescMolto) with constante
is a contradiction (get very quiet while not changing dynamic).  Insofar
as a hairpin represents a change in dynamics, constante should, in
theory, be a different grob.  My solution is not ideal, but I think it
is an OK middle-ground short of the creation of a separate grob.  If
people think it is too hackish, I will propose a new patch with a
Constante grob (or make the hairpin grow-direction = #CENTER default to
constante, which'd be difficult but doable).

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


Re: Allows minimum-length to work for end-of-line spanners. (issue 7453046)

2013-03-17 Thread mtsolo

Reviewers: lemzwerg, dak, mike7,

Message:
On 2013/03/11 10:18:59, dak wrote:

On 2013/03/10 00:32:43, mike7 wrote:



> >> > Why is this override needed for the regtest?  The other

overrides

> > are
> >> > obvious user-accessible overrides for triggering the tested
> >> > functionality.
> >> >
> >> > But should _this_ override not be the default?
> >> >
> >> > https://codereview.appspot.com/7453046/
> >
> >> Perhaps open a tracker issue for this?
> >> The question is not only valid for text spanners but also

hairpins,

> > glissandos,
> >> etc.
> >
> > Last time I looked, this issue purportedly "Allows minimum-length

to

> > work for end-of-line spanners."  And according to the regtest, it

does

> > not do the job.  Without additional messing with springs-and-rods

it

> > does not allow minimum-length to work for end-of-line-spanners.
> >
>
[...]



> Additional messing with springs and rods is because minimum-length
> is currently implemented by four different interfaces (lyric-hyphen,
> multi-measure-rest, ottava-bracket and spanner) and is also looked
> up in lyric-extender in a way that does not correspond to its
> docstring.  So, certain uses of minimum length require the
> additional override whereas others don't.  I do not think this is
> ideal, which is why I proposed a few weeks ago standardizing
> property names across interfaces.  It seems like the issues you are
> raising above and below have less to do with this patch and more to
> do with the multiple implementation of minimum-length and the use of
> the springs-and-rods property.



This is a typical case of "Somebody Else's Problem".  If there is a
party and you place a chair in the worst possible place, like
somewhere in a doorway, people will walk around it, squeeze themselves
through, get annoyed again and again.



That's our current state.  Now someone wants to do a polonaise and
since the chair is in the way, he proposes putting a plank across it.



Now we are moving from ridiculous to absurd, and it becomes harder to
do the right thing.



Yes, I am fully aware that you are not responsible for the chair in
the way of your polonaise.



Bit it is time to move it aside rather than taking it into account in
our planning and make it even harder to get into a proper state.  In
particular since your coding style requires a lot of reverse
engineering in order to figure out the hidden assumptions and
dependencies.  So that makes it doubly desirable to not add further
dependencies on broken behavior but first clean up the foundations.



Yes, that's not a problem caused by your patch, but the consequences
are acerbated by it.



> > The only thing more frustrating than missing functionality is
> > purportedly available functionality that needs
> > non-user-comprehensible trickery to actually work.
>
> I do not have a problem with the current need to set the
> springs-and-rods separately.



Of course you don't, and nobody keeps you from applying this sort of
patch to your own private code base without doing the necessary
cleanup before.



But you are not the metric for what goes into LilyPond's own
repository and what not.  The functionality that goes into LilyPond
has to work for the average user encountering that problem space.  The
solutions have to have a meaningful correspondence in complexity to
the problem and not require "don't think about it" steps.



> I'm positive it would because of the way that minimum-length is
> multiply defined.  That is why this patch is intended for the "some
> layout objects" discussed above like the TextSpanner.  I agree that
> the multiple use of the minimum-length property should be changed,
> but this seems like the business of another patch.



Sure.  But that patch will be harder to do once this patch _relies_ on
the broken behavior, and people write code _relying_ on this patch.



> If the regtest is bothering you that much, I can just eliminate it
> from this patch.



There is no point in hiding the symptoms of a problem away.  That only
makes things even harder in future.


I don't think this is a problem blocking the current patch.  You are
right that the current multiple functions of minimum-length are
problematic.  I'm not arguing that this is someone else's problem - I am
arguing that this (like all bugs) is the community's problem.  Yes, the
regtest that I've proposed uses an override that corresponds to that
used in the Documentation which is, as you have pointed out, a
suboptimal way of doing things.  It may take months or years to sort out
the multiple naming of properties.  This shouldn't block this patch from
being pushed.

So when you say "But this patch will be harder to do once this _relies_
on the broken behavior.", all this patch will rely on is an override
that you are arguing should be the default.

This patch fixes behavior that would exist even if the springs-and-rods
override became the default.

Imagine it this way.  Patients are taking a suboptimal drug for a
dise