Re: Doc: avoid implicit \relative; issue 4371 (issue 237340043 by k-ohara5...@oco.net)

[k-ohara5a5a]

Reviewers: Trevor Daniels,

Message:
On 2015/05/17 21:54:07, Trevor Daniels wrote:

But I think if are to
make this change it would also be good to say what leaving out

\relative means.

It was difficult to do this before as all the examples left it out

(apparently).

  Now we can do it.  Placing a brief explanation at the beginning of

1.2.1 would

explain the mysterious 's in those first examples of code.



The tutorial almost never leaves out \relative,
but I did add at the start of 'Pitches' an explanation of the system
within which c' denotes middle C

Description:
Doc: avoid implicit \relative; issue 4371

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

Affected files (+562, -487 lines):
  M Documentation/contributor/doc-work.itexi
  M Documentation/learning/common-notation.itely
  M Documentation/learning/fundamental.itely
  M Documentation/learning/tutorial.itely
  M Documentation/learning/tweaks.itely
  M Documentation/usage/running.itely



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

Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)

[k-ohara5a5a]

On 2015/05/17 22:06:10, Trevor Daniels wrote:


I strongly prefer just two input modes, \relative and \absolute,


Okay.  I won't split the job to complement \relative between two
functions.  That leaves the question of what to name the one function.


The proper name for this would be \absoluteWithFixedOctaveOffset


Remember the point Carl and Paul pointed out, that if we write 'Baa Baa
Black Sheep' as
  \absoluteWithFixedOctaveOffset c'' {g,4 g, d d e e d2}
then the input is not what they consider 'absolute mode' because the
octaves are not absolute, but relative to a fixed octave ''.

I see now that David considers the input accepted by \fixed as in this
patch as a variant of 'absolute mode', just "absolute mode with a
different octave".   The choice of reference octave makes the input mode
seem not very 'absolute' -- until you compare it to LilyPond's
\relative.

Carls's and Paul's objections were not vehement, but they seem relevant
to newcomers to LilyPond.  (Also, I can type 'fixed' faster.)  So, I'm
taking the position of "put up or shut up": confirm that the concept of
"absolute mode" in the docsis consistent with merging \fixed into
\absolute, or poll the -user mailing list, or be content.


https://codereview.appspot.com/235010043/diff/140001/Documentation/learning/common-notation.itely
File Documentation/learning/common-notation.itely (right):

https://codereview.appspot.com/235010043/diff/140001/Documentation/learning/common-notation.itely#newcode1431
Documentation/learning/common-notation.itely:1431: the note on the
bottom staff of the bass clef.
^

https://codereview.appspot.com/235010043/diff/140001/Documentation/notation/pitches.itely
File Documentation/notation/pitches.itely (right):

https://codereview.appspot.com/235010043/diff/140001/Documentation/notation/pitches.itely#newcode172
Documentation/notation/pitches.itely:172: absolute octave mode.  Which
choices are meaningful?
^

https://codereview.appspot.com/235010043/diff/140001/Documentation/notation/pitches.itely#newcode882
Documentation/notation/pitches.itely:882: @code{\relative} block.}
^

https://codereview.appspot.com/235010043/

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

Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)

[tdanielsmusic]

On 2015/05/17 21:09:13, dak wrote:


  At any rate, if we were to retain both \fixed and \absolute,


I strongly prefer just two input modes, \relative and \absolute, but
as I said right at the beginning:


... I'd prefer
the syntax and options [of \absolute] to parallel those of
\relative.  That is, an optional prefix pitch to indicate
the starting octave, and taking the starting octave from
the first contained note if the prefix is omitted.


That is then consistent, easy to explain and understand, and provides
all the functionally we need (retaining the option to add the
transposing
cuteness at some point in the future if we wish.)

Trevor


https://codereview.appspot.com/235010043/

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

Doc: avoid implicit \relative; issue 4371 (issue 237340043 by k-ohara5...@oco.net)

[tdanielsmusic]

I'm not opposed to the change to explicit \relative; it avoids having to
explain why it was omitted in the examples, and makes the example code
more exactly correspond to the code obtained by clicking on the image.
But I think if are to make this change it would also be good to say what
leaving out \relative means.  It was difficult to do this before as all
the examples left it out (apparently).  Now we can do it.  Placing a
brief explanation at the beginning of 1.2.1 would explain the mysterious
's in those first examples of code.


https://codereview.appspot.com/237340043/diff/10006/Documentation/learning/tweaks.itely
File Documentation/learning/tweaks.itely (right):

https://codereview.appspot.com/237340043/diff/10006/Documentation/learning/tweaks.itely#newcode2124
Documentation/learning/tweaks.itely:2124: \relative c' {
no leading spaces

https://codereview.appspot.com/237340043/

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

Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)

[dak]

https://codereview.appspot.com/235010043/diff/140001/Documentation/notation/pitches.itely
File Documentation/notation/pitches.itely (right):

https://codereview.appspot.com/235010043/diff/140001/Documentation/notation/pitches.itely#newcode112
Documentation/notation/pitches.itely:112: The reference pitch after
@code{\fixed} is optional.
On 2015/05/17 19:07:05, Keith wrote:

Rather than the optional pitch, we could document the other name
"The function @code{\absolute} is shorthand for @code{\fixed c'}


I really hope you mean @code{\fixed c} here, or things will be really
messed up.  At any rate, if we were to retain both \fixed and \absolute,
I don't think it makes sense to give either \absolute or \fixed an
optional argument: it should always be \absolute without pitch, and
\fixed with pitch then.

https://codereview.appspot.com/235010043/

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

Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)

[David Kastrup]

"Keith OHara"  writes:

> The two functions \fixed and \relative each convert user input into
> absolute pitches.

So does \absolute.  Which was its primary raison d'être.

> \relative applies octave marks relative to the previous pitch; \fixed
> adds octave marks to those of a fixed pitch.
>
> The primary function of the music-function \absolute is to write a
> stretch of absolute pitches within \relative, but the primary function
> of \fixed will be to choose the fixed octave from which entered octave
> marks count.

There is no difference.

> I switched the name in the patch from \absolute to \fixed when I made
> the function skip over any enclosed \relative section.  The docs say
> the starting pitch in \relative is an absolute pitch, and I didn't
> want to start making the distinction of "absolute octaves" versus "the
> octave established by the enclosing absolute"

\absolute x'' would be absolute input mode with a different octave, not
transposed absolute mode.

> so I made the change
> \absolute c'' {c e g \relative c, {c e g} } => c''4 e'' g'' c' e' g'
> \fixed c'' {c e g \relative c, {c e g} } => c''4 e'' g'' c, e, g,

That does not make sense at all.  Just because your first implementation
of \absolute did something different (and I suggested to change that)
does not mean that fixing its behavior requires changing its name.
There is no precedent of \absolute c'' being associated with anything
else merely because it showed different behavior in the first review.

> For some reason I find the word 'fixed' easier to type than 'absolute'

At least _this_ reason is not absurd.  It's not compelling to me,
however, so I'd prefer to see a vote on it.

-- 
David Kastrup

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

Part combiner: Ignore skips coinciding with rests within a part (issue 240790043 by nine.fierce.ball...@gmail.com)

[nine . fierce . ballads]

Reviewers: ,

Description:
Part combiner: Ignore skips coinciding with rests within a part

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

Affected files (+19, -14 lines):
  M input/regression/part-combine-silence-mixed.ly
  M scm/part-combiner.scm


Index: input/regression/part-combine-silence-mixed.ly
diff --git a/input/regression/part-combine-silence-mixed.ly  
b/input/regression/part-combine-silence-mixed.ly
index  
7d5975819bf3a148caa7b1ce68d6a2375436..a399431a006a70269b31db8a2a85d22729a35cc8  
100644

--- a/input/regression/part-combine-silence-mixed.ly
+++ b/input/regression/part-combine-silence-mixed.ly
@@ -1,18 +1,18 @@
 \version "2.19.16"

 \header {
-  texidoc = "Different kinds of silence are not merged into the shared  
voice even if they begin and end simultaneously."
+  texidoc = "Different kinds of silence are not merged into the shared  
voice even if they begin and end simultaneously; however, when rests and  
skips are present in the same part, the skips are ignored."

 }

 \score { <<
   \new Staff {
 \partcombine
-  \relative f' { R1^"R" | s1^"s" | r1^"r" }
-  \relative f' { r1_"r" | R1_"R" | s1_"s" }
+  \relative f' { R1^"R" | s1^"s" | r1^"r" | << R1 s1 s4 >> | << r1 s2  
s4 >> }
+  \relative f' { r1_"r" | R1_"R" | s1_"s" | << s4 s1 R1 >> | << s4 s2  
r1 >> }

   }
   \new Staff {
 \partcombine
-  \relative f' { r1^"r" | R1^"R" | s1^"s" }
-  \relative f' { R1_"R" | s1_"s" | r1_"r" }
+  \relative f' { r1^"r" | R1^"R" | s1^"s" | << s4 s1 R1 >> | << s4 s2  
r1 >> }
+  \relative f' { R1_"R" | s1_"s" | r1_"r" | << R1 s1 s4 >> | << r1 s2  
s4 >> }

   }
 >> }
Index: scm/part-combiner.scm
diff --git a/scm/part-combiner.scm b/scm/part-combiner.scm
index  
a2ebda492cff8c30ce8e6360f1df56d16020e84d..20b7b05cc56d329ce9208db2419504a32a7302ee  
100644

--- a/scm/part-combiner.scm
+++ b/scm/part-combiner.scm
@@ -63,11 +63,16 @@
  (note-events vs))
 note))
-  (define (f? x)
-(or (ly:in-event-class? x 'rest-event)
-(ly:in-event-class? x 'skip-event)))
-  (filter f? (events vs)))
+(define-method (rest-or-skip-events (vs ))
+  (define (filtered-events event-class)
+(filter (lambda(x) (ly:in-event-class? x event-class))
+(events vs)))
+  (let ((result (filtered-events 'rest-event)))
+;; There may be skips in the same part with rests for various
+;; reasons.  Regard the skips only if there are no rests.
+(if (and (not (pair? result)) (not (any-mmrest-events vs)))
+(set! result (filtered-events 'skip-event)))
+  result))

 (define-method (any-mmrest-events (vs ))
   (define (f? x)
@@ -477,8 +482,8 @@ Only set if not set previously.
  (vs2 (cdr (voice-states now-state

 (define (analyse-synced-silence)
-  (let ((rests1 (if vs1 (rest-and-skip-events vs1) '()))
-(rests2 (if vs2 (rest-and-skip-events vs2) '(
+  (let ((rests1 (if vs1 (rest-or-skip-events vs1) '()))
+(rests2 (if vs2 (rest-or-skip-events vs2) '(
 (cond

  ;; multi-measure rests (probably), which the
@@ -616,8 +621,8 @@ the mark when there are no spanners active.
 (let* ((now-state (vector-ref result result-idx))
(vs1 (current-voice-state now-state 1))
(vs2 (current-voice-state now-state 2))
-   (rests1 (if vs1 (rest-and-skip-events vs1) '()))
-   (rests2 (if vs2 (rest-and-skip-events vs2) '()))
+   (rests1 (if vs1 (rest-or-skip-events vs1) '()))
+   (rests2 (if vs2 (rest-or-skip-events vs2) '()))
(prev-state (if (> result-idx 0)
(vector-ref result (- result-idx 1))
#f))



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

Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)

[k-ohara5a5a]

https://codereview.appspot.com/235010043/diff/140001/Documentation/notation/pitches.itely
File Documentation/notation/pitches.itely (right):

https://codereview.appspot.com/235010043/diff/140001/Documentation/notation/pitches.itely#newcode112
Documentation/notation/pitches.itely:112: The reference pitch after
@code{\fixed} is optional.
Rather than the optional pitch, we could document the other name
"The function @code{\absolute} is shorthand for @code{\fixed c'} used to
ensure that the pitches within @code{\absolute} remain unchanged, even
if the @code{\absolute} is inside @code{\relative}, discussed next."

https://codereview.appspot.com/235010043/

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

Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)

[Keith OHara]

On Sun, 17 May 2015 04:58:22 -0700,  wrote:


The proper name for this would \absoluteWithFixedOctaveOffset, but
that's too long and the acronym is similarly uninspiring.  All three of
the proposed options appear in this name, so the question is, "Which
alludes most memorably to the actual function?".  At the risk of going
round in circles, on reconsidering in this light, I rather favour
retaining \absolute.  The other terms are modifiers to the primary
function; the offset is both apparent and optional, "absolute" is used
in the text and is an established concept.



The word "absolute" is established in the docs and in the user community to mean the method of 
entering pitches where octave marks ' and , count octaves from the "small octave" of Helmholtz 
notation, so the octaves are indicated against an absolute reference.  As Carl pointed out, a function that 
applies an octave offset changes that reference, so is different from "absolute".

The two functions \fixed and \relative each convert user input into absolute 
pitches.
\relative applies octave marks relative to the previous pitch; \fixed adds 
octave marks to those of a fixed pitch.

The primary function of the music-function \absolute is to write a stretch of 
absolute pitches within \relative, but the primary function of \fixed will be 
to choose the fixed octave from which entered octave marks count.

I switched the name in the patch from \absolute to \fixed when I made the function skip over any 
enclosed \relative section.  The docs say the starting pitch in \relative is an absolute pitch, and 
I didn't want to start making the distinction of "absolute octaves"  versus "the 
octave established by the enclosing absolute" so I made the change
  \absolute c'' {c e g \relative c, {c e g} } => c''4 e'' g'' c' e' g'
  \fixed c'' {c e g \relative c, {c e g} }   =>  c''4 e'' g'' c, e, g,

For some reason I find the word 'fixed' easier to type than 'absolute'

I started looking ahead at further documentation, and found \fixed more natural
https://codereview.appspot.com/235010043/diff/120001/Documentation/learning/tutorial.itely
but I backed away from adding anything to the Tutorial because \relative is 
enough to learn there.

BTW, I started replacing @lilypond[relative=2] with complete examples
  https://codereview.appspot.com/237340043/
I replaced with explicit \relative, but the patch set is a quick way to skim 
the examples in the Learing Manual where we chose to hide the '\relative' and 
imaging how \fixed or \absolute might work.


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

Re: Add stencil-flip function (issue 235090043 by paulwmor...@gmail.com)

[pkx166h]

author  Paul Morris
Tue, 5 May 2015 03:18:15 + (23:18 -0400)
committer   James Lowe 
Sun, 17 May 2015 18:34:15 + (19:34 +0100)
commit  51aecfed170349c19e10923c9ce18773ad1786c3

and

author  Paul Morris
Tue, 5 May 2015 03:12:52 + (23:12 -0400)
committer   James Lowe 
Sun, 17 May 2015 18:35:40 + (19:35 +0100)
commit  5910bd4b7113bc614136480740c53866f3c6c69a

https://codereview.appspot.com/235090043/

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

Re: Just some short feedback

[David Kastrup]

Jan Nieuwenhuizen  writes:

> David Kastrup writes:
>
>> I'll probably come up with something GOOPS-related eventually and the
>> closure mechanism for creating Scheme engravers will be deprecated.
>
> You might want to be a bit careful with GOOPS
>
> http://lists.gnu.org/archive/html/guile-devel/2015-05/msg4.html

Well, GOOPS would be involved with setting up engravers (basically with
organizing per-instance data) but not significantly with their running
operations.

-- 
David Kastrup

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

Re: Issue 4365: non-member is_smob<>(), is_derived_smob<>(), etc. (issue 231680043 by nine.fierce.ball...@gmail.com)

[dak]

On 2015/05/16 20:37:28, Dan Eble wrote:

On 2015/05/16 15:09:05, dak wrote:
> I don't really like this one.  "unsmob (self)" should really be

"this".  Using

> the even less specific unsmob seems like a step in

the wrong

> direction.  This might call for unchecked_unsmob (should this be

protected

> rather than private?).



That seems pretty safe.  It would be mighty reckless to call

"unchecked"

anything without understanding it, so I doubt it will be misused.



> It would be nicer to [...]
> but I've not yet come up with a working scheme yet.



And sadly, I must decline to help.  Allergy medicine has cut my

brainpower

today.


Well ok, I managed.  Issue 4400.  I like that better than before anyway.

https://codereview.appspot.com/231680043/

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

Re: Just some short feedback

[Jan Nieuwenhuizen]

David Kastrup writes:

> I'll probably come up with something GOOPS-related eventually and the
> closure mechanism for creating Scheme engravers will be deprecated.

You might want to be a bit careful with GOOPS

http://lists.gnu.org/archive/html/guile-devel/2015-05/msg4.html

Greetings, Jan

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

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

Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)

[tdanielsmusic]

On 2015/05/17 10:44:36, dak wrote:


Well, I remain unenthused about the new name.  Maybe get a vote on the

user

list, with options \absolute x'', \fixed x'', \octave x''?  I think

those were

pretty much the terms mentioned significantly more than once.


The proper name for this would \absoluteWithFixedOctaveOffset, but
that's too long and the acronym is similarly uninspiring.  All three of
the proposed options appear in this name, so the question is, "Which
alludes most memorably to the actual function?".  At the risk of going
round in circles, on reconsidering in this light, I rather favour
retaining \absolute.  The other terms are modifiers to the primary
function; the offset is both apparent and optional, "absolute" is used
in the text and is an established concept.

Trevor


https://codereview.appspot.com/235010043/

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

Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)

[dak]

On 2015/05/17 09:56:01, Trevor Daniels wrote:

On 2015/05/17 07:36:01, Keith wrote:
> On 2015/05/15 06:12:38, lemzwerg wrote:
> > Given that we are currently producing development
> > releases, I suggest that this gets implemented,
> > then we simply wait a few months so that people can
> > test it in real life, and then we do a final decision.
>
> If we don't come back with another patch, the current patch will

become final

by
> default, but I do think it is a useful choice.
>
> The addition to Learning Manual: Common Notation gives us some idea

of the

extra
> complexity of documentation that comes with \fixed.  A similar

change to this

> section was suggested a few years ago at
>

http://lists.gnu.org/archive/html/lilypond-user/2008-08/msg00384.html


I'm content with this conclusion.  I might even try using \fixed ;-)


Well, I remain unenthused about the new name.  Maybe get a vote on the
user list, with options \absolute x'', \fixed x'', \octave x''?  I think
those were pretty much the terms mentioned significantly more than once.

https://codereview.appspot.com/235010043/

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

Re: Add French-specific note names (issue 239930043 by v.villen...@gmail.com)

[dak]

On 2015/05/17 09:44:52, Valentin Villenave wrote:

On 2015/05/17 08:39:00, dak wrote:
> Well, with notenames like "re" it should have been \language
> "francais"...  I think we even had this at one time.  No wait, that

was

> "espanol".



Yes. "español" is aliased to "espanol", and "français" is now aliased

to

"francais" in the same way.


Oh, I was joking.  I don't think we want "francais".  People were
annoyed enough at "espanol".


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

Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)

[tdanielsmusic]

On 2015/05/17 07:36:01, Keith wrote:

On 2015/05/15 06:12:38, lemzwerg wrote:
> Given that we are currently producing development
> releases, I suggest that this gets implemented,
> then we simply wait a few months so that people can
> test it in real life, and then we do a final decision.



If we don't come back with another patch, the current patch will

become final by

default, but I do think it is a useful choice.



The addition to Learning Manual: Common Notation gives us some idea of

the extra

complexity of documentation that comes with \fixed.  A similar change

to this

section was suggested a few years ago at
http://lists.gnu.org/archive/html/lilypond-user/2008-08/msg00384.html


I'm content with this conclusion.  I might even try using \fixed ;-)

Trevor


https://codereview.appspot.com/235010043/

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

Re: Add French-specific note names (issue 239930043 by v.villen...@gmail.com)

[v . villenave]

On 2015/05/17 08:39:00, dak wrote:

Well, with notenames like "re" it should have been \language
"francais"...  I think we even had this at one time.  No wait, that

was

"espanol".


Yes. "español" is aliased to "espanol", and "français" is now aliased to
"francais" in the same way.


It's actually the few files containing UTF-8 characters which

currently

are messing up our GUILE-2 conversion.  But it's not like we could

make

do without them either.


Yes. I don’t think this patch will make matters worse.


Shouldn't Italian have this also then?


I thought about adding it there as well. Will do.

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

Re: Decrease space between vertical beams by length-fraction. (issue 214250043 by hanw...@gmail.com)

[pkx166h]

On 2015/05/17 09:09:59, hanwenn wrote:

should I do this myself?



On Sat, May 16, 2015 at 8:41 AM,   wrote:
> Patch counted down - please push to Staging branch
>
> https://codereview.appspot.com/214250043/





--
Han-Wen Nienhuys - mailto:hanw...@gmail.com -

http://www.xs4all.nl/~hanwen

Sure. I assume you have push permissions ;)

James

https://codereview.appspot.com/214250043/

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

Re: Decrease space between vertical beams by length-fraction. (issue 214250043 by hanw...@gmail.com)

[Han-Wen Nienhuys]

should I do this myself?

On Sat, May 16, 2015 at 8:41 AM,   wrote:
> Patch counted down - please push to Staging branch
>
> https://codereview.appspot.com/214250043/



-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

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

Re: Add French-specific note names (issue 239930043 by v.villen...@gmail.com)

[David Kastrup]

v.villen...@gmail.com writes:

> Reviewers: ,
>
> Message:
> Greetings everybody,
> here’s an itch I’ve been wanting to scratch for the past decade or so:
> as a French user, having to type "re" instead of "ré" feels unnatural
> (and it still does after ten years); it is not uncommon that my scores
> fail to compile because I’ve inadvertently typed "ré" somewhere in the
> source code.
>
> It’s also affecting newcomers to LilyPond, judging from my students; a
> few years ago, I had added \language "français" as an alias to
> "italiano" hoping that it would make things easier to explain, but that
> particular oddity remains to this day.

Well, with notenames like "re" it should have been \language
"francais"...  I think we even had this at one time.  No wait, that was
"espanol".

> I know that accented chars in the source code is not something
> traditional coders want to have, but LilyPond has been utf8-based for
> quite a while now so this shouldn’t be too disruptive a change.

It's actually the few files containing UTF-8 characters which currently
are messing up our GUILE-2 conversion.  But it's not like we could make
do without them either.

> This also brings the -x double-sharp suffix to
> French input language (an unrelated but welcome addition).

Shouldn't Italian have this also then?

> Please review this at https://codereview.appspot.com/239930043/

-- 
David Kastrup

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

Assessment of Allura at SourceForge

[Trevor Daniels]

Hi

I've now completed my assessment of Allura at SourceForge against the list of 
requirements supplied by Phil.  A point-by-point comparison is shown below.  My 
conclusion is that Allura at SourceForge is suitable for hosting our Issues DB.

There are some differences from GoogleCode, but these are relatively minor and 
can be accommodated by small changes in our procedures.  In particular the 
Blocking and Duplicate facilities will be different, and the various posts in 
the discussion are fully threaded and so are not numbered, meaning 
cross-referencing is by link rather than number.  The emails sent out following 
additions and amendments are not formatted as nicely as those from GoogleCode, 
but contain all the information.  Support is by +ve and -ve voting rather than 
starring.  Finally, the Owner field in the transferred tickets is not 
populated.  The owner is identified in the text of the ticket,  so the field 
can be manually amended after the event in the few tickets where this matters.

Other than that the facilities are remarkably similar, and apart from 
congestion the transfer of the DB is fairly trouble-free.

I'm in the process of tailoring a test facility for developers and admin to 
play with, and as a vehicle for re-engineering git-cl and patchy.  I'll post 
again when this is ready.

Here's the point-by-point comparison:

> 1. Allow creation of a new sequentially numbered issue, with 
> text describing the issue's title and details

Available as standard.

> 2. Allow tagging the issue with a range of types 
> (e.g. Type-Critical = Defect which blocks a stable release, 
> Type-Maintainability = Hinders future development)

Available by creating a new custom field Type, with a list of permitted
values.

> 3. Allow tagging the issue with life-cycle stages 
> (e.g. Accepted, started, fixed)

This is the Status field.  Available as standard.

> 4. Allow tagging issues with patch status

Available by creating a new custom field: Patch, with list of permitted
values.  Note that existing values are not capitalised, unlike
values of the Type field, so need to continue with this as searches
are case-sensitive.  Search name is "_patch".  (All field names in
searches are lower-case only, and custom field names start with an 
underscore.)

> 5. Allow display of issues at different lifecycle stages 
> (issues open, issues to be verified, all issues)

Comprehensive searching possible, eg "labels:2_19_19 AND status:Fixed"
also custom buttons can be created for commonly required searches.

> 6. Allow display of issues of different types 
> (e.g. Critical, Documentation, .)

Possible after creating new field called Type.  Search name is "_type".
eg "_type:Documentation AND !status:Fixed"

> 7. Allow image attachment and display

Available as standard.

> 8. Allow non-image attachments

Available as standard.

> 9. Prevent non-registered users from adding issues

Available as standard.  Separate permissions may be set for:
  
  Admin
  Configure
  Create tickets
  Delete tickets
  Moderate comments
  Post comments (subject to moderation)
  Post comments (without moderation)
  View Tickets
  Edit Tickets

Permissions are set per group:

  Admin
  Developer
  Member
  Authenticated
  Anonymous

Additional groups can be created.

so Create tickets (etc) could be restricted to Admin and Developers

It would be possible to have a second set of tickets which could be
available to anyone.  Tickets can be selected and moved between
trackers or even projects.

> 10. Allow registered admins to add users

Available as standard.  Users must have a SourceForge account.

> 11. Allow users to add comments to existing issues

Controlled by permissions.  See 9. above.
Might be best restricted to Authenticated users (any logged-in user).

> 12. Provide an API to allow patchy to find issues with new patches, 
> to detect the URL with the Rietveld link and to update the patch status 
> once the patch is tested.

An API is available which seems to have all the facilities required.

> 13. Provide an API for git-cl to allow automatic creation of issues
> to track patches.

An API is available which seems to have all the facilities required.

> 14. Allow export of the issue database in CSV form

Actually GoogleCode (and Allura) export the text part of the DB as a
JSON file, with urls pointing to the attachments so these can be located
and exported by a script at a later time.  The GoogleCode CSV export just 
exports the index (i.e. no text) which is singularly useless for backup and
transfer.

So this requirement might be better written as:

> 14. Allow export of the issue database as a zipped JSON file containing all
> the index variables and discussion text, together with a means of accessing
> all attachments so these may be re-associated correctly with the relevant
> text.

Available as standard, together with import.  This is a way, albeit
rather extravagant, of modifying any field in the DB, even those not
available f

Add French-specific note names (issue 239930043 by v.villen...@gmail.com)

[v . villenave]

Reviewers: ,

Message:
Greetings everybody,
here’s an itch I’ve been wanting to scratch for the past decade or so:
as a French user, having to type "re" instead of "ré" feels unnatural
(and it still does after ten years); it is not uncommon that my scores
fail to compile because I’ve inadvertently typed "ré" somewhere in the
source code.

It’s also affecting newcomers to LilyPond, judging from my students; a
few years ago, I had added \language "français" as an alias to
"italiano" hoping that it would make things easier to explain, but that
particular oddity remains to this day.

I know that accented chars in the source code is not something
traditional coders want to have, but LilyPond has been utf8-based for
quite a while now so this shouldn’t be too disruptive a change.

Description:
Add French-specific note names

French users may (and do) want to enter the D pitch
as "ré" instead of Italian-like "re".

This also brings the -x double-sharp suffix to
French input language (an unrelated but welcome addition).

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

Affected files (+137, -10 lines):
  M Documentation/changes.tely
  M Documentation/notation/pitches.itely
  M input/regression/note-names.ly
  M python/convertrules.py
  M python/musicexp.py
  M scm/define-note-names.scm


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

Re: Google Code shutting down

[Trevor Daniels]

David Kastrup wrote Sunday, May 17, 2015 8:49 AM
>
> Should I ask at Savannah how they view the prospect of running Allura?
> Are there obvious selling points over Savane?  Like that there is an API
> for manipulating issues?

No harm in asking.  Presumably they would need to undertake its ongoing 
maintenance - we don't want to be stuck as the only users of an unmaintained 
tracker.

The main attractions of Allura from our PoV is its support of images, together 
with facilities that fairly closely match those of GoogleCode, together with a 
ready-made importer.  I'm not familiar with Savane so I can't make a detailed 
comparison, but I believe it does not support images and does not have a 
GoogleCode importer.  Does it also not have an API?

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

Re: Google Code shutting down

[David Kastrup]

"Trevor Daniels"  writes:

> Further to this, I had a very helpful interchange today with one of
> the other users at SourceForge who responded to my ticket.  He
> suggested exporting the text part of the DB as a JSON file, changing
> all the occurrences of "author": "*anonymous" to "author":
> "tdanielsmusic", and re-importing the file.  I tried this.  It works
> and fixes the exposure problem.  I've now created a new account
> "googleimporter" and am in the process of changing the author to that
> in all the imported tickets so my account remains separate.
>
> However, this has exposed another difficulty.  Importing DBs is a
> bottleneck.  I managed to import part of the first file I modified,
> enough to check it fixes the problem, but importing the main DB with
> 4000-odd issues has so far failed due to congestion.  The file uploads
> but is then rejected with "Too many pending imports.  Please try
> later."  This suggests we should aim to start the migration proper
> early rather than later.

Should I ask at Savannah how they view the prospect of running Allura?
Are there obvious selling points over Savane?  Like that there is an API
for manipulating issues?

-- 
David Kastrup

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

Re: Google Code shutting down

[Trevor Daniels]

Trevor Daniels wrote Saturday, May 16, 2015 10:44 AM
>
> I've pretty well completed my assessment of Allura at SourceForge, and find 
> the facilities available pretty well match our needs, in fact they are 
> surprisingly similar to those at GoogleCode.  There are some differences but 
> none which we can't live with.  So far so good.
> 
> However, there is a show-stopper concerning the integrity of the Issues 
> discussions recorded in the tracker.  Each item in the discussion has an 
> owner, and this is set to Anonymous during the import, since the original 
> owner is not recognised as a SourceForge account-holder.  This in itself is 
> not a serious problem, as the correct owner is recorded in the text of the 
> message.  However, owners of discussion messages are always permitted to edit 
> them, irrespective of the permission settings, and I can find no way of 
> preventing this.  That means Anonymous, which is any not-logged-in user, i.e. 
> anyone, will be able to edit, accidently or maliciously, any and all 
> discussion entries in our Issues DB.
> 
> I've reported this to the SourceForge maintainers:
> https://sourceforge.net/p/forge/site-support/10317/

Further to this, I had a very helpful interchange today with one of the other 
users at SourceForge who responded to my ticket.  He suggested exporting the 
text part of the DB as a JSON file, changing all the occurrences of "author": 
"*anonymous" to "author": "tdanielsmusic", and re-importing the file.  I tried 
this.  It works and fixes the exposure problem.  I've now created a new account 
"googleimporter" and am in the process of changing the author to that in all 
the imported tickets so my account remains separate.

However, this has exposed another difficulty.  Importing DBs is a bottleneck.  
I managed to import part of the first file I modified, enough to check it fixes 
the problem, but importing the main DB with 4000-odd issues has so far failed 
due to congestion.  The file uploads but is then rejected with "Too many 
pending imports.  Please try later."  This suggests we should aim to start the 
migration proper early rather than later.

Trevor

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

Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)

[k-ohara5a5a]

On 2015/05/15 06:12:38, lemzwerg wrote:

Given that we are currently producing development
releases, I suggest that this gets implemented,
then we simply wait a few months so that people can
test it in real life, and then we do a final decision.


If we don't come back with another patch, the current patch will become
final by default, but I do think it is a useful choice.

The addition to Learning Manual: Common Notation gives us some idea of
the extra complexity of documentation that comes with \fixed.  A similar
change to this section was suggested a few years ago at
http://lists.gnu.org/archive/html/lilypond-user/2008-08/msg00384.html


https://codereview.appspot.com/235010043/

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