Re: This is actually a whole bunch of commits: (issue 7303067)

[dak]

Reviewers: Keith,

Message:
On 2013/02/10 20:42:35, Keith wrote:

https://codereview.appspot.com/7303067/diff/1/Documentation/notation/editorial.itely

File Documentation/notation/editorial.itely (right):



https://codereview.appspot.com/7303067/diff/1/Documentation/notation/editorial.itely#newcode157

Documentation/notation/editorial.itely:157: Markup texts or strings

may be used

for finger changes.
Not strings in general, because the font is the music font by default.

 General

strings would have a in some default font, but p in the font for the

dynamic

'piano'


I did not write "arbitrary strings".  "string" just implies a data type,
not what characters it may contain.  We are also talking about
fingerings here and nothing else.  If you think that the text needs
changes, please propose what you consider appropriate instead.

Description:
This is actually a whole bunch of commits:


Remove obsolete @knownissue about fingerings like -23


Issue 3034: Use \finger in a few documentation places


Simplify definition of \thumb


Remove definition of \finger from double fingering regtest


Add explicit \finger command for normal fingering events


Let \rightHandFinger accept arbitrary markup as text


Add number-or-markup? predicate


Let calc-{fingering,string-number,stroke-finger}::calc-text look at
event 'text

This slightly increases the number of property lookups, and the same
function can be achieved using a tweak.  However, it seems more
natural to attach any overriding text (in the case of non-standard
elements like thumbs or other) directly to the event in question.

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

Affected files:
  M Documentation/notation/editorial.itely
  M Documentation/notation/text.itely
  M Documentation/snippets/creating-double-digit-fingerings.ly
  M ly/music-functions-init.ly
  M ly/script-init.ly
  M scm/c++.scm
  M scm/lily.scm
  M scm/output-lib.scm


Index: Documentation/notation/editorial.itely
diff --git a/Documentation/notation/editorial.itely  
b/Documentation/notation/editorial.itely
index  
002dafbe668d8aaa58bba81a609166a8eeae50e3..715aa620a74e9f9776c1de10d9621fa59c1ad682  
100644

--- a/Documentation/notation/editorial.itely
+++ b/Documentation/notation/editorial.itely
@@ -154,10 +154,10 @@ Fingering instructions can be entered using
 c4-1 d-2 f-4 e-3
 @end lilypond

-Markup texts may be used for finger changes.
+Markup texts or strings may be used for finger changes.

 @lilypond[verbatim,quote,relative=2]
-c4-1 d-2 f-4 c^\markup { \finger "2 - 3" }
+c4-1 d-2 f\finger \markup \tied-lyric #"4~3" c\finger "2 - 3"
 @end lilypond

 @cindex thumb-script
@@ -211,10 +211,6 @@ Internals Reference:
 @rinternals{New_fingering_engraver},
 @rinternals{Fingering}.

-@knownissues
-By default, numbers greater than 9 are not supported using
-@samp{@var{note}-@var{digit}}.
-

 @node Hidden notes
 @unnumberedsubsubsec Hidden notes
Index: Documentation/notation/text.itely
diff --git a/Documentation/notation/text.itely  
b/Documentation/notation/text.itely
index  
dd7126585081b4911fd0b9c60f47ba5f907186a6..e6a085fc56e0b6488be5580168fdd8fafb5e6104  
100644

--- a/Documentation/notation/text.itely
+++ b/Documentation/notation/text.itely
@@ -1166,11 +1166,7 @@ in markup mode:

 @lilypond[quote,verbatim,relative=1]
 g1 bes
-ees-\markup {
-  \finger 4
-  \tied-lyric #"~"
-  \finger 1
-}
+ees\finger \markup \tied-lyric #"4~1"
 fis_\markup { \dynamic rf }
 bes^\markup {
   \beam #8 #0.1 #0.5
Index: Documentation/snippets/creating-double-digit-fingerings.ly
diff --git a/Documentation/snippets/creating-double-digit-fingerings.ly  
b/Documentation/snippets/creating-double-digit-fingerings.ly
index  
4991989e6a7c5bbdde6cbe0f7bb2dbc8a839a634..85f596d7edf3bc3312868ecd549c718055b17917  
100644

--- a/Documentation/snippets/creating-double-digit-fingerings.ly
+++ b/Documentation/snippets/creating-double-digit-fingerings.ly
@@ -4,7 +4,7 @@
 %% and then run scripts/auxiliar/makelsr.py
 %%
 %% This file is in the public domain.
-\version "2.17.11"
+\version "2.17.13"

 \header {
   lsrtags = "editorial-annotations, expressive-marks, scheme-language,  
staff-notation, tweaks-and-overrides"

@@ -28,11 +28,6 @@ fifty =
 #(make-music 'FingeringEvent
  'digit 50)

-finger =
-#(define-music-function (parser location digit) (integer?)
-   (make-music 'FingeringEvent
-   'digit digit))
-
 #(define (calc-finger-without-warning grob)
(let* ((event (event-cause grob))
  (digit (ly:event-property event 'digit)))
Index: ly/music-functions-init.ly
diff --git a/ly/music-functions-init.ly b/ly/music-functions-init.ly
index  
c063b9585da50b8d9325f73aab5ebb4c0c45cd6e..061e696d08f01f967924c674367e095cb245086a  
100644

--- a/ly/music-functions-init.ly
+++ b/ly/music-functions-init.ly
@@ -379,6 +379,15 @@ featherDurations=

  argument))

+finger =
+#(define-event-function (parser location finger) (number-or-markup?)
+   (_i "Apply @var{finger} as a fingering ind

Re: Issue 754: don't transpose generic property-setting music commands (issue 7303057)

[dak]

On 2013/02/11 06:18:57, Keith wrote:

On 2013/02/09 08:54:03, dak wrote:



> It doesn't matter.  LilyPond is still being actively maintained.  If

a

> feature is required, it can be implemented properly, with a proper
> interface, _without_ resorting to exploits.
>



I was hoping to be able to provide a backward-compatibility function,

as in

, just in case someone used
\transposition inside of \transpose the way it used to work.


I did not even look at the proposed patch but it touches several
binaries.  That should not be necessary.  Of course, in this variant of
the patch, it would be feasible just to put untransposable back to #f,
but since the followup work includes reversing the sign of the pitch
again, this is a dead end.  I think that something using ApplyContext
should be workable, though, so that the compatibility function gets
along just using LilyPond/Scheme and can be loaded on-demand.

https://codereview.appspot.com/7303057/

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

Re: Issue 754: don't transpose generic property-setting music commands (issue 7303057)

[dak]

On 2013/02/11 09:25:20, dak wrote:

On 2013/02/11 06:18:57, Keith wrote:
> On 2013/02/09 08:54:03, dak wrote:
>
> > It doesn't matter.  LilyPond is still being actively maintained.

If a

> > feature is required, it can be implemented properly, with a proper
> > interface, _without_ resorting to exploits.
> >
>
> I was hoping to be able to provide a backward-compatibility

function, as in

> , just in case someone used
> \transposition inside of \transpose the way it used to work.



I did not even look at the proposed patch but it touches several

binaries.  That

should not be necessary.  Of course, in this variant of the patch, it

would be

feasible just to put untransposable back to #f, but since the followup

work

includes reversing the sign of the pitch again, this is a dead end.  I

think

that something using ApplyContext should be workable, though, so that

the

compatibility function gets along just using LilyPond/Scheme and can

be loaded

on-demand.


Ok, ApplyContext does not cut it since it does not offer access to the
original music.  But try, for example,
oldTransposition =
#(define-music-function (parser location pitch) (ly:pitch?)
  (make-music 'SequentialMusic
   'pitch (ly:pitch-negate pitch)
   'elements-callback
   (lambda (m)
(list
 #{ \transposition $(ly:pitch-negate
 (ly:music-property m 'pitch))
 #}

and you'll see that \oldTransposition will just make the old behavior
available again.  You can't assign this particular definition to
transposition, for obvious reasons, but saving and using the old value
of \transposition should be doable in an obvious manner.

https://codereview.appspot.com/7303057/

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

Corrects links to manuals in many languages (issue 7311074)

[PhilEHolmes]

Reviewers: ,

Message:
Please review.

Description:
A number of the links on the Development pages for the various languages
point to pages that don't exist (e.g. the Czech page
http://lilypond.org/development.cs.html) or don't point to translated
pages when they do exist (e.g. http://lilypond.org/development.it.html).
 This patch _should_ fix many of these.  It's difficult to test
properly, since it relies on interactions between make doc in GUB and
make website on the server.  However, I believe it's a step forward and
would like to get it into master fairly quickly.

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

Affected files:
  M Documentation/cs/web/community.itexi
  D Documentation/cs/web/news-front.itexi
  D Documentation/hu/web/basic-authors.itexi
  M Documentation/hu/web/community.itexi
  M Documentation/it/web/community.itexi
  M Documentation/zh/web/community.itexi



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

Patch meister position still vacant!!!

[David Kastrup]

Hi, the duties of the Patch meister are outlined in
http://lilypond.org/doc/v2.14/Documentation/contributor/patch-handling>.
Currently, nobody is doing this job since Colin Campbell took a
sabbatical in order to find some time for doing things with LilyPond
rather than for LilyPond and thus recharge his motivation.

I have been pitching in with the respective patch status changes in the
last few weeks, but it is clear that I lack both the diligence as well
as the impartiality required for this job: obviously patches of which I
am reasonably sure get preferred treatment, and obviously my own patches
are more likely to benefit.  What is worse is that I tend to
procrastinate on patches I feel unsure about, and I also procrastinate
on doing the actual reviews necessary to end the unsureness.  I can't
split sufficiently into two persons, one who waves through changes that
the other feels bad about but did not have the time or energy to
thoroughly review.  And I am losing track on what is what and waiting
for how long.

So I am stalling LilyPond's progress in this function.  That's bad.  We
need someone else to take over this job, someone who feels ok with
ticking off a checklist and taking action on the presently available
information.

Please consider whether you can pitch in here.  If we can find no single
person to do this job, we might do rotations on it.  But I'd prefer some
consistency in reaction rather than, say, "oh, because of the standing
and unaddressed objections on Rietveld, I did not get my patch through
on Tuesday, so I just wait for Thursday since the Patch meister on that
day is less careful".

Please consider pitching in here if you can see yourself able to do this
duty.

-- 
David Kastrup


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

Eliminates pure-print-callbacks list (issue 7300082)

[dak]

https://codereview.appspot.com/7300082/diff/1/scm/define-grobs.scm
File scm/define-grobs.scm (right):

https://codereview.appspot.com/7300082/diff/1/scm/define-grobs.scm#newcode2570
scm/define-grobs.scm:2570: (Y-extent . ,pure-safe-stencil-height)
Are there grobs that don't have this definition of Y-extent?  If it is
the same everywhere, do we even need an entry for it?

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

https://codereview.appspot.com/7300082/diff/1/scm/output-lib.scm#newcode61
scm/output-lib.scm:61: (define-public pure-safe-stencil-height
Perhaps add any information about the name?  Its name claims to produce
a pure value, but it actually outputs callbacks both for pure and
unpure.  What makes it "safe"?

https://codereview.appspot.com/7300082/

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

Re: Eliminates pure-print-callbacks list (issue 7300082)

[m...@mikesolomon.org]

On 11 févr. 2013, at 16:29, d...@gnu.org wrote:

> 
> https://codereview.appspot.com/7300082/diff/1/scm/define-grobs.scm
> File scm/define-grobs.scm (right):
> 
> https://codereview.appspot.com/7300082/diff/1/scm/define-grobs.scm#newcode2570
> scm/define-grobs.scm:2570: (Y-extent . ,pure-safe-stencil-height)
> Are there grobs that don't have this definition of Y-extent?

Yes.

> If it is
> the same everywhere, do we even need an entry for it?
> 
> https://codereview.appspot.com/7300082/diff/1/scm/output-lib.scm
> File scm/output-lib.scm (right):
> 
> https://codereview.appspot.com/7300082/diff/1/scm/output-lib.scm#newcode61
> scm/output-lib.scm:61: (define-public pure-safe-stencil-height
> Perhaps add any information about the name?  Its name claims to produce
> a pure value, but it actually outputs callbacks both for pure and
> unpure.  What makes it "safe"?

maybe unpure-pure-stencil-height is better?


> 
> https://codereview.appspot.com/7300082/


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

Re: Eliminates pure-print-callbacks list (issue 7300082)

[dak]

On 2013/02/11 17:01:17, mike7 wrote:

On 11 févr. 2013, at 16:29, mailto:d...@gnu.org wrote:



> scm/output-lib.scm:61: (define-public pure-safe-stencil-height
> Perhaps add any information about the name?  Its name claims to

produce

> a pure value, but it actually outputs callbacks both for pure and
> unpure.  What makes it "safe"?



maybe unpure-pure-stencil-height is better?


Its effect would presumably be a callback that is not replaced by its
value when called.  Correct?  All that pure/unpure whatever is just
waving internals around for a concept that has little to do with it.

I'd use something like
(ly:retriggerable-callback ly:grob::stencil-height)
for that, and since you use it a whole lot of time and presumably don't
want to have one closure per use, you can use something like

(define ly:grob::retriggerable-stencil-height
  (ly:retriggerable-callback ly:grob::stencil-height))

once in a useful location and then use that.  Your coding style only
ever shows mechanisms, not concepts.  That makes the code about as
pleasant and easy to read as disassembled machine code.  I am not sure I
got the concept right here: that's your job.  Not that of the reader or
reviewer.

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

Re: [Lilypond-auto] Issue 3104 in lilypond: note-by-number and note don't support flag styles other than default

[Thomas Morley]

2013/2/10  :
> Updates:
> Labels: -Patch-countdown Patch-push
>
> Comment #15 on issue 3104 by d...@gnu.org: note-by-number and note don't
> support flag styles other than default
> http://code.google.com/p/lilypond/issues/detail?id=3104
>
> Countdown complete (actually already yesterday).  Push at your discretion.
>
>

As I expected this is ways over my head, though, here some results of my trials.

First I added the following to the code of \note-by-number:

  (set! style (cond ((not (null? style))
 style)
((not (null? (ly:output-def-lookup layout 'style)))
 (ly:output-def-lookup layout 'style))
(else 'default)))

  (set! flag-style (cond ((not (null? flag-style))
  flag-style)
 ((not (null? (ly:output-def-lookup layout
'flag-style)))
  (ly:output-def-lookup layout 'flag-style))
 (else 'default)))

  (newline)(display "style ")(write style)
  (newline)(display "flag-style ")(write flag-style)

Second, in define-context-properties.scm I added:

 (flag-style ,symbol? "The style of the flag.")
 (style ,symbol? "The style of the note-head.")

And made some experiments:

(1)
%%%

\layout {
style = #'mensural
flag-style = #'mensural
}

\new MensuralStaff
\relative c' { \tempo "" 8 = 80 c8 }

\markup \note-by-number #3 #0 #1

\new Staff \with { }
\relative c' { \tempo "" 8 = 80 c8 }

%%%

Results: the toplevel-markup uses defaults,
The MetronomeMark in MensuralStaff uses 'mensural for heads and flags, but also
does the default-Staff.
I found no method to limit the \layout-settings to a specific context:

\layout {
  \context {
\MensuralStaff
style = #'mensural
flag-style = #'mensural
  }
}

gives no error/warning, but is without effect.

(2)
Replacing \layout with

\paper {
style = #'mensural
flag-style = #'mensural
}

results in mensural-style for the MetronomeMark of all Staffs
_and_ for the top-level-markup.

(3)
Using both \paper and \layout with different settings results in a _different_
appearance of the toplevel-markup and the Staffs.

But again, _both_ Staffs act equal regarding their MetronomeMark.

===

What to do now?

Seems that style/flag-style-properties, perhaps renamed, should be integrated
somehow, to make it possible to refer to them even in an explicit
context-modification.
Speculating, I'd say it means some work in C++ beyond my expertise.

I tend to push \note-by-number as it stands (or let it push).
Once the work with property-integrating/refering is done a follow-up-patch might
be feasible.

David, what do you think?

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

Re: Issue 754: don't transpose generic property-setting music commands (issue 7303057)

[k-ohara5a5a]

On 2013/02/11 12:39:02, dak wrote:

On 2013/02/11 09:25:20, dak wrote:
> On 2013/02/11 06:18:57, Keith wrote:
> >
> > I was hoping to be able to provide a backward-compatibility

function, as in


> I did not even look at the proposed patch but it touches several

binaries.

That
> should not be necessary.  Of course, in this variant of the patch,

it would be

> feasible just to put untransposable back to #f, but since the

followup work

> includes reversing the sign of the pitch again, this is a dead end.

I think

> that something using ApplyContext should be workable, though, so

that the

> compatibility function gets along just using LilyPond/Scheme and can

be loaded

> on-demand.


Well, my previous suggestion for backward-compatibility used LilyPond,
but you promptly adjusted your patch to stop my suggestion from working.


oldTransposition =
#(define-music-function (parser location pitch) (ly:pitch?)
   (make-music 'SequentialMusic
'pitch (ly:pitch-negate pitch)
'elements-callback
(lambda (m)
 (list
  #{ \transposition $(ly:pitch-negate
 (ly:music-property m 'pitch))
  #}


Great.  The pitches in structures built by make-music (differently to
those created by property-set) are molested by \transpose, but then a
sneaky callback tampers with the music and creates -- wait for it -- a
nested property-set!  It just goes to show that people will take
advantage of _any_ reproducible behavior, no matter how inconsistent.

Just kidding.  This should be fine for a backward-compatibility
function, in case anyone has a 200-page score that accidentally depended
on the old behavior.

https://codereview.appspot.com/7303057/

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

Re: Patch meister position still vacant!!!

[James]

Hello,

On 11 February 2013 14:42, David Kastrup  wrote:

>
> Hi, the duties of the Patch meister are outlined in
>  http://lilypond.org/doc/v2.14/Documentation/contributor/patch-handling>.
> Currently, nobody is doing this job since Colin Campbell took a
> sabbatical in order to find some time for doing things with LilyPond
> rather than for LilyPond and thus recharge his motivation.
>
> I have been pitching in with the respective patch status changes in the
> last few weeks, but it is clear that I lack both the diligence as well
> as the impartiality required for this job: obviously patches of which I
> am reasonably sure get preferred treatment, and obviously my own patches
> are more likely to benefit.  What is worse is that I tend to
> procrastinate on patches I feel unsure about, and I also procrastinate
> on doing the actual reviews necessary to end the unsureness.  I can't
> split sufficiently into two persons, one who waves through changes that
> the other feels bad about but did not have the time or energy to
> thoroughly review.  And I am losing track on what is what and waiting
> for how long.
>
> So I am stalling LilyPond's progress in this function.  That's bad.  We
> need someone else to take over this job, someone who feels ok with
> ticking off a checklist and taking action on the presently available
> information.
>
> Please consider whether you can pitch in here.  If we can find no single
> person to do this job, we might do rotations on it.  But I'd prefer some
> consistency in reaction rather than, say, "oh, because of the standing
> and unaddressed objections on Rietveld, I did not get my patch through
> on Tuesday, so I just wait for Thursday since the Patch meister on that
> day is less careful".
>
> Please consider pitching in here if you can see yourself able to do this
> duty.
>


>

I can do this. Although I thought that someone had already voluntered.
Eluze? (I cannot remember)

Anyway, assuming that no one else offers, I'll take a look and make a start
of it on Wednesday.

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

Re: Patch meister position still vacant!!!

[Eluze]

James wrote
> I can do this. Although I thought that someone had already voluntered.
> Eluze? (I cannot remember)
> 
> Anyway, assuming that no one else offers, I'll take a look and make a
> start
> of it on Wednesday.

I not really volunteered, but agreed to have a look at it - but I would
really feel more comfortable if somebody else could take care of it - if
there's need I could try to take over some parts of it. 

thanks for your offer and best wishes for this job!

Eluze



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Patch-meister-position-still-vacant-tp140762p140778.html
Sent from the Dev mailing list archive at Nabble.com.

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

i'm back - hopefully.

[Janek Warchoł]

Hi all,

i hope to get back to lilypond hacking now.  I miss it a lot...
Quite frankly, i have to say that you are awesome people :)

Any particular thing that i should know about?  I don't see any
"developer summaries" to inform myself, unfortunately, so feel free to
post links to tracker issues and thread subjects.

cheers,
Janek

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

Re: i'm back - hopefully.

[Thomas Morley]

2013/2/12 Janek Warchoł :
> Hi all,
>
> i hope to get back to lilypond hacking now.  I miss it a lot...

Great to see you back!!

-Harm

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

Re: i'm back - hopefully.

[David Nalesnik]

2013/2/12 Janek Warchoł :

> > Hi all,
> >
> > i hope to get back to lilypond hacking now.  I miss it a lot...
>

Welcome back, Janek!

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

Re: Issue 754: don't transpose generic property-setting music commands (issue 7303057)

[dak]

On 2013/02/11 20:53:53, Keith wrote:

On 2013/02/11 12:39:02, dak wrote:
> On 2013/02/11 09:25:20, dak wrote:
> > On 2013/02/11 06:18:57, Keith wrote:
> > >
> > > I was hoping to be able to provide a backward-compatibility

function, as

in



> > I did not even look at the proposed patch but it touches several

binaries.

> That
> > should not be necessary.  Of course, in this variant of the patch,

it would

be
> > feasible just to put untransposable back to #f, but since the

followup work

> > includes reversing the sign of the pitch again, this is a dead

end.  I think

> > that something using ApplyContext should be workable, though, so

that the

> > compatibility function gets along just using LilyPond/Scheme and

can be

loaded
> > on-demand.



Well, my previous suggestion for backward-compatibility used LilyPond,

but you

promptly adjusted your patch to stop my suggestion from working.



> oldTransposition =
> #(define-music-function (parser location pitch) (ly:pitch?)
>   (make-music 'SequentialMusic
>'pitch (ly:pitch-negate pitch)
>'elements-callback
>(lambda (m)
> (list
>  #{ \transposition $(ly:pitch-negate
> (ly:music-property m 'pitch))
>  #}



Great.  The pitches in structures built by make-music (differently to

those

created by property-set) are molested by \transpose, but then a sneaky

callback

tampers with the music and creates -- wait for it -- a nested

property-set!

The copy&paste job does not match what happens here.  In this case,
transpose manipulates a pitch field that is by naming and function
_chosen_ to get acted upon.  That's not the abomination.  The
abomination is using a music type intended for something different and
printing as something different for setting a transposition using a
callback not intended for it.

Arguably, one should rather use TransposedMusic or similar for this
abomination.  However, this would involve tampering _both_ with
elements-callback as well as iterator-ctor.  And TransposedMusic does
not really have anything to do with \transposition except by relation
of the names.

I'd have preferred, in order of priority, using something like
a) ApplyContext.  This would not have access to the event, however.
b) a user-defined event.  We don't have those in a reliable manner
yet.

This is a compatibility hack.  The first version (and most likely also
the ultimate version) did not use #{ ... #} but rather copy&paste from
the internals of \transposition.  However, those are going to change
when I change the sign of instrumentTransposition.  So for better
longevity of this comment, I picked #{ ... #}.


It just goes to show that people will take advantage of _any_
reproducible behavior, no matter how inconsistent.


It is a compatibility hack purposefully not affecting _any_ of the
LilyPond code base when not used.  Once user-defined events are more
than a semi-manual hack, I'd use them.  Since they aren't, I chose
this self-contained hack.  I'd not recommend it for user-maintained
code: it relies on SequentialMusic going through elements-callback.
But maintaining this hack through changes of SequentialMusic should be
less work than maintaining explicit code paths in the main code.  We
have still lily_1_8_relative mottled through our code base, and
ripping out this compatibility cruft from versions of 1.8 or earlier
(seriously?!?)  was vetoed because people might have been using it as
a user choice option.

Since it seems almost impossible to stamp such compatibility cruft
out, I prefer not letting it in in the first place.


Just kidding.


Sure, but the amount of hypocrisy of mine that you are basing the
kidding on might be different from what you thing and/or suggest, so I
prefer to have this in the open.


This should be fine for a backward-compatibility function, in case
anyone has a 200-page score that accidentally depended on the old
behavior.


The situation is worse than that.  The mailing list carries examples
where people have purposefully rather than accidentally based their
code on the old behavior.  And in light of the available
documentation, I can't blame them for doing experimentation and taking
bad choices, choices that it takes someone with a clue about
maintainability, predictability and system design to do right.

So we are not talking about "accidentally" but rather "imprudently"
or, as that level of prudence is nothing to require of a user,
"unwisely" here.

Curing the fallout with documentation, convert-ly rules and backward
compatibility include file will be much more of a wart and disgrace
than the above code.


https://codereview.appspot.com/7303057/

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

Re: i'm back - hopefully.

[David Kastrup]

Janek Warchoł  writes:

> Hi all,
>
> i hope to get back to lilypond hacking now.  I miss it a lot...

I know how that feels, looking at my backlog.  Unfortunately I have a
day job which is, uh, LilyPond hacking, and it is leaving me with not
enough time to do LilyPond hacking.

> Quite frankly, i have to say that you are awesome people :)

It is actually sobering how many of those doing serious work on LilyPond
(or are financing my work) state that they don't find much time actually
_using_ LilyPond.  There is an Open Source slogan "scratching one's
itch", but a lot of people here are rather scratching other people's
itches.  So yes, these lists carry a veritable collection of
awesomeness.

> Any particular thing that i should know about?  I don't see any
> "developer summaries" to inform myself, unfortunately, so feel free to
> post links to tracker issues and thread subjects.

Well, you get the "Investors' reports" from my work (I'd have pointed to
the LilyPond Report for them, but there has been a dearth of them in the
last half year).  The banter in there covers some highlights though
obviously with too much of a focus on my own work.

We still have a stream of skyline-related issue reports that spell
somewhat dubious prospects for either the release date of 2.18 or its
expected stability.  In the case of user space upheavals, \tuplet has
appeared finally in a way similar to that of the September (?)
discussions, Guile-2 work is progressing at snail's pace (but not
entirely stopped), \transposition is just getting a semantics change
heatedly discussed and possibly affecting your Midi output, depending on
how you chose with \transposition's previously strange semantics when
further transposed.  Issue reports are streaming in at an insane pace;
one has to admire the bug squad for keeping up with it.  As a developer,
you can cherry-pick among oodles of issues and never get bored.  Or
finished.

-- 
David Kastrup


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

Re: bounty hack for some (non-Mike) Schemer out there

[Kieren MacMillan]

Hi Mike,

> Should get you started OK:

Thanks for this!

First, I'm going to turn this into a music function so I don't have to keep 
typing it all.
Then I'm going to see if I can turn it into a callback function for 
MetronomeMark — that's where I mostly need it.

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

Re: bounty hack for some (non-Mike) Schemer out there

[m...@mikesolomon.org]

On 12 févr. 2013, at 02:58, Kieren MacMillan  
wrote:

> Hi Mike,
> 
>> Should get you started OK:
> 
> Thanks for this!
> 
> First, I'm going to turn this into a music function so I don't have to keep 
> typing it all.
> Then I'm going to see if I can turn it into a callback function for 
> MetronomeMark — that's where I mostly need it.
> 
> Many thanks,
> Kieren.

Hey Kieren,

You won't be able to do this with a metronome mark because that Grob is an item 
whereas the text spanner is a spanner, meaning it can take up multiple columns 
witthout stretching the music too much. So I'd use a customized text spanner in 
a separate context (like Dynamics...or you could create your own).

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

Re: i'm back - hopefully.

[Werner LEMBERG]

> i hope to get back to lilypond hacking now.

Aah!  Great!

> Any particular thing that i should know about?

Please comment

  http://code.google.com/p/lilypond/issues/detail?id=3155


 Werner

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

collision beam with staff-crossing beam

[Werner LEMBERG]

Folks,


consider this real-life example (omitting the unimportant voices).

  <<
\new Staff = "R" \relative c' {
  \voiceTwo
   d16[ b
\change Staff = "L" \stemUp
g
\change Staff = "R" \stemDown
b d b]
}

\new Staff = "L" \relative c' {
  \clef "bass"
  \voiceOne
  g8[ s g]
}
  >>

There is an ugly clash between the two beams.  Due to the cross-staff
beam, this is sort-of expected.  However, I wonder whether this can be
improved: Isn't it possible to make the beaming algorithm simply
ignore cross-staff stems so that the beam gets a proper skyline?

In case this is not possible, what can I do to improve the formatting?
Note that globally increasing the distance between the staves is not a
possible solution since this would ruin the layout of the whole piece.


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

Re: collision beam with staff-crossing beam

[m...@mikesolomon.org]

On 12 févr. 2013, at 07:21, Werner LEMBERG  wrote:

> 
> Folks,
> 
> 
> consider this real-life example (omitting the unimportant voices).
> 
>  <<
>\new Staff = "R" \relative c' {
>  \voiceTwo
>   d16[ b
>\change Staff = "L" \stemUp
>g
>\change Staff = "R" \stemDown
>b d b]
>}
> 
>\new Staff = "L" \relative c' {
>  \clef "bass"
>  \voiceOne
>  g8[ s g]
>}
>>> 
> 
> There is an ugly clash between the two beams.  Due to the cross-staff
> beam, this is sort-of expected.  However, I wonder whether this can be
> improved: Isn't it possible to make the beaming algorithm simply
> ignore cross-staff stems so that the beam gets a proper skyline?
> 
> In case this is not possible, what can I do to improve the formatting?
> Note that globally increasing the distance between the staves is not a
> possible solution since this would ruin the layout of the whole piece.
> 
> 
> Werner

All of my C++ work on LilyPond (the elimination of translate_axis, for example) 
is going towards improving cases like this.  That said, this case is 
particularly thorny.  To fix it, you could add an invisible text spanner above 
the beam with the gs, for example.

I'd send this sort of question to -user, as people have all sorts of hacks for 
this kinda thing.

Cheers,
MS


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