Re: convert-ly (issue 2670) (issue 6610058)

[Julien Rioux]

On Sat, Oct 6, 2012 at 1:06 AM,  wrote:

> Are you going to report the number of errors using the `errors'
> variable?  In case this is true, I would consider this a bad idea, since
> you abuse the functionality of the exit status.
>
> How large can `errors' become?  The value returned by `exit' must be in
> the range 0-255 (with 0 meaning `no error').
>
> http://codereview.appspot.com/**6610058/
>

I thought it would be interesting to track the number of errors, yes, but
you are absolutely right. I`ll change it to return 0 (success) or 1
(failure).

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

Re: Provide an \un function for turning overrides and sets into reverts and unsets (issue 6588067)

[dak]

Reviewers: janek,

Message:
On 2012/10/05 14:46:09, janek wrote:

please provide usage example(s).  I suppose i like this idea, but

without

examples i don't know what exactly will be possible, and what won't be

possible.

Is it enough to say that after

unHideNotes = \un\hideNotes
oneVoice = \un\voiceOne

you would not notice a difference? \un\omit StringNumber will revert the
effect of \omit StringNumber.

Description:
Provide an \un function for turning overrides and sets into reverts and
unsets

Please review this at http://codereview.appspot.com/6588067/

Affected files:
  M ly/music-functions-init.ly


Index: ly/music-functions-init.ly
diff --git a/ly/music-functions-init.ly b/ly/music-functions-init.ly
index  
26db17c5ede8ce07e9b72f78fa7d05c0f82a7cbf..d946ab54919b7236948a1a4a3ac7227c6958616b  
100644

--- a/ly/music-functions-init.ly
+++ b/ly/music-functions-init.ly
@@ -1290,6 +1290,50 @@ are affected.")
   (ly:music-property music 'tweaks)))
music)

+un =
+#(define-music-function (parser location music)
+   (ly:music?)
+   (_i "Convert @code{\\override} and @code{\\set} in @var{music} to
+@code{\\revert} and @code{\\unset}, respectively.  Any reverts and
+unsets already in @var{music} are ignored and not converted.")
+   (let loop
+   ((music music))
+ (let
+ ((lst
+   (fold-some-music
+(lambda (m) (or (music-is-of-type? m 'layout-instruction-event)
+(music-is-of-type? m 'context-specification)))
+(lambda (m overrides)
+  (case (ly:music-property m 'name)
+((OverrideProperty)
+ (cons
+  (make-music 'RevertProperty
+  'symbol (ly:music-property m 'symbol)
+  'grob-property-path
+  (cond
+   ((ly:music-property m 'grob-property #f) =>  
list)

+   (else
+(ly:music-property  
m 'grob-property-path

+  overrides))
+((PropertySet)
+ (cons
+  (make-music 'PropertyUnset
+  'symbol (ly:music-property m 'symbol))
+  overrides))
+((ContextSpeccedMusic)
+ (cons
+  (make-music 'ContextSpeccedMusic
+  'element (loop (ly:music-property  
m 'element))
+  'context-type (ly:music-property  
m 'context-type))

+  overrides))
+(else overrides)))
+'()
+music)))
+   (cond
+((null? lst) (make-music 'Music))
+((null? (cdr lst)) (car lst))
+(else (make-sequential-music lst))
+
 unfoldRepeats =
 #(define-music-function (parser location music) (ly:music?)
(_i "Force any @code{\\repeat volta}, @code{\\repeat tremolo} or



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

Re: Provide an \un function for turning overrides and sets into reverts and unsets (issue 6588067)

[tdanielsmusic]

I think I would prefer to name this function \undo.
This more accurately expresses what it does:
\undo\voiceOne reverses everything that \voiceOne
does, or did.  The action of \un\voiceOne is not
so intuitively obvious, nor does it make an English
work or phrase.

\reverse would be an alternative, but its length
reduces its attraction.

Trevor



http://codereview.appspot.com/6588067/

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

Re: Provide an \un function for turning overrides and sets into reverts and unsets (issue 6588067)

[Nicolas Sceaux]

Le 6 oct. 2012 à 09:10, d...@gnu.org a écrit :

> Reviewers: janek,
> 
> Message:
> On 2012/10/05 14:46:09, janek wrote:
>> please provide usage example(s).  I suppose i like this idea, but
> without
>> examples i don't know what exactly will be possible, and what won't be
> possible.
> 
> Is it enough to say that after
> 
> unHideNotes = \un\hideNotes
> oneVoice = \un\voiceOne
> 
> you would not notice a difference? \un\omit StringNumber will revert the
> effect of \omit StringNumber.

Very nice, thanks.


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

Re: Provide an \un function for turning overrides and sets into reverts and unsets (issue 6588067)

[dak]

On 2012/10/06 07:44:51, Trevor Daniels wrote:

I think I would prefer to name this function \undo.
This more accurately expresses what it does:
\undo\voiceOne reverses everything that \voiceOne
does, or did.  The action of \un\voiceOne is not
so intuitively obvious, nor does it make an English
work or phrase.



\reverse would be an alternative, but its length
reduces its attraction.


"reverse" is already taken as a Scheme operator.  Digging through the
thesaurus, other viable options would be "cancel" or "revoke".

One main design target of \un is to block bikeshedding by providing a
way of undoing a simple or complex override in a manner that is
sufficiently concise and straightforward to make it not worth the effort
to think up an individual name for the reversal operation.

\un\omit is similar to "I see you omitted to mention my participation in
this draft.  Let me un-omit this.", namely the use of a dashed
artificial un-word for the sake of expressing a literal reversal.

It also matches \hideNotes/\unHideNotes in character, but looking
through ly/property-init.ly, it would appear that most pairings are of
the xxxOn/xxxOff form anyway, or even completely different like
\voiceNeutralStyle, \tupletNeutral, \tieSolid, \defaultTimeSignature,
\arpeggioNormal.

Good grief.

The principal aim is to make the use of \un/\undo\whatever a no-brainer,
not have people start thinking about shorter alternatives.  \undo might
work well enough, I don't know.  Maybe one should survey people.

If you take a look at
http://code.google.com/p/lilypond/issues/detail?id=2002> and the
following discussions, you'll see that I made \once work for a lot of
things it did not work before just to be able to avoid the want or need
for additional commands like \hideNote that would make it harder for
users to guess the behavior of a LilyPond-provided command.  And you'll
see that Adam was less than convinced that \once\hideNotes was tolerably
short.

\undo certainly seems nicer for things like \undo\xxxOn in contrast to
\un\xxxOn.  Are there other opinions/votes/leanings?

http://codereview.appspot.com/6588067/

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

Re: Provide an \un function for turning overrides and sets into reverts and unsets (issue 6588067)

[Janek Warchoł]

On Sat, Oct 6, 2012 at 9:10 AM,   wrote:
> Is it enough to say that after
>
> unHideNotes = \un\hideNotes
> oneVoice = \un\voiceOne
>
> you would not notice a difference? \un\omit StringNumber will revert the
> effect of \omit StringNumber.

That's what i expected.  Are there any limitations?  For example,
would \un\clef and \un\key result in
- reverting to previous clef/key
- something strange
- syntax error
?


On Sat, Oct 6, 2012 at 9:44 AM,   wrote:
> I think I would prefer to name this function \undo.

+1, feels more natural to me also.

thanks,
Janek

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

Re: Provide an \un function for turning overrides and sets into reverts and unsets (issue 6588067)

[David Kastrup]

Janek Warchoł  writes:

> On Sat, Oct 6, 2012 at 9:10 AM,   wrote:
>> Is it enough to say that after
>>
>> unHideNotes = \un\hideNotes
>> oneVoice = \un\voiceOne
>>
>> you would not notice a difference? \un\omit StringNumber will revert the
>> effect of \omit StringNumber.
>
> That's what i expected.  Are there any limitations?  For example,
> would \un\clef and \un\key result in
> - reverting to previous clef/key
> - something strange
> - syntax error

Something strange is most likely.  \set does not really maintain a
stack, so \unset just kills the context-dependent value.

\un\clef would likely return to the violin clef, \un\key to c\major,
regardless of what has happened before.  This is just a wild guess.
\un\key would not actually trigger a key display (since \key is not pure
override), but likely accidentals would afterwards behave like c\major.

That's all just guessing, I haven't tried any of that out actually.

-- 
David Kastrup

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

[talk] why it'd be great to have web interface for submitting simple doc patches

[Janek Warchoł]

Just a musing
I think the case shown below would perfectly qualify for "could you
write a documentation patch for this? it can be done with a web
interface, instructions are here" - if we had the web interface.

On Sat, Oct 6, 2012 at 10:44 AM, Janek Warchoł  wrote:
> On Sat, Oct 6, 2012 at 2:38 AM, Brad Smith  wrote:
>> When should you
>> use ly:pitch and when should you use ly:music? (Is there a place in
>> the documentation that is good for learning these things?)
>
> I'm no expert on music functions, but i'd say that ly:music? is used
> when the argument would be a music expression, e.g. { c8 d-. e-. c-.
> }, while ly:pitch? is used when the argument is a note name.
> This /should/ be in the documentation.  Could you make a bug report about it?
>
> hope this helps,
> Janek

I know that everyone can make a simple email with doc suggestion and
send it to the mailing list, but then someone has to maintain it.
Also, several times when i asked users for such suggestions they were
very vague and i couldn't just copy-and-paste them (and i didn't have
time to do more).  If we presented them with a web interface where
they could write the actual change, it should work way better.  Just
look at Wikipedia.

cheers,
Janke

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

Re: Provide an \un function for turning overrides and sets into reverts and unsets (issue 6588067)

[Janek Warchoł]

On Sat, Oct 6, 2012 at 10:50 AM, David Kastrup  wrote:
>
>> Are there any limitations?  For example,
>> would \un\clef and \un\key result in
>> - reverting to previous clef/key
>> - something strange
>> - syntax error
>
> Something strange is most likely.  \set does not really maintain a
> stack, so \unset just kills the context-dependent value.

Something strange happened, indeed. This:
{
  \key a \major \clef F
  cis dis c e
  \un\key a\major \un\clef F
  cis fis c e
}
produced a treble clef glyph (but it didn't affect notnotese
positions) and accidentals that were still in a major.
Also, i couldn't just write \un\key nor \un\clef.
I think it would be good to polish this, so that this either works or
always produces syntax error.

cheers,
Janek

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

Re: Provide an \un function for turning overrides and sets into reverts and unsets (issue 6588067)

[David Kastrup]

Janek Warchoł  writes:

> On Sat, Oct 6, 2012 at 10:50 AM, David Kastrup  wrote:
>>
>>> Are there any limitations?  For example,
>>> would \un\clef and \un\key result in
>>> - reverting to previous clef/key
>>> - something strange
>>> - syntax error
>>
>> Something strange is most likely.  \set does not really maintain a
>> stack, so \unset just kills the context-dependent value.
>
> Something strange happened, indeed. This:
> {
>   \key a \major \clef F
>   cis dis c e
>   \un\key a\major \un\clef F
>   cis fis c e
> }
> produced a treble clef glyph (but it didn't affect notnotese
> positions) and accidentals that were still in a major.
> Also, i couldn't just write \un\key nor \un\clef.

Huh?  \key is not a music expression on its own, neither is \clef.

> I think it would be good to polish this, so that this either works or
> always produces syntax error.

If we produce an error for music harvested for overrides that have more
effects than just the override, something like
\midi { \tempo 4 = 60 }
would have to be prohibited as well since it silently drops markup.

You'll have similar problems using \once on commands like that.
Figuring out heuristics when or when one should not issue a warning is
not all that easy to decide with a reasonable amount of consistency, and
this is not a problem particular to \undo.

-- 
David Kastrup

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

Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)

[Janek Warchoł]

On Fri, Oct 5, 2012 at 9:42 PM, Thomas Morley
 wrote:
> 2012/10/5  :
>> It just occured to me: is there any way to specify different span bar
>> lines (at the end of the line and at the beginning of the line)?
>
> Marc and me, we discussed this some time ago and decided not to
> provide that functionality.
> It would make things more complicated for the user and I think it is a
> rarely needed feature.

Sorry for missing that part of the discussion.
If it's not too late to speak my mind, i think that it would be a
shame to have such an awesome and powerful barline interface without
giving users simple way to choose span barline behaviour.

I would imagine the user interface ("syntax") to be like this:
(define-bar-line (a b c) (x y z))
or
(define-bar-line ((a b c) . (x y z)))

where (a b c) are the barlines (mid-system, end-of-system,
beginning-of-system respectively) and (x y z) are the span barlines,
in the same order as barlines.
And it would be nice if
(define-bar-line (a b c) (x))
was equivalent to
(define-bar-line (a b c) (x x x))

cheers,
Janek

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

Re: Provide an \un function for turning overrides and sets into reverts and unsets (issue 6588067)

[Janek Warchoł]

On Sat, Oct 6, 2012 at 11:15 AM, David Kastrup  wrote:
> Janek Warchoł  writes:
>> I think it would be good to polish this, so that this either works or
>> always produces syntax error.
>
> Figuring out heuristics when or when one should not issue a warning is
> not all that easy to decide with a reasonable amount of consistency, and
> this is not a problem particular to \undo.

ok.

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

Re: Provide an \undo function for turning overrides and sets into reverts and unsets (issue 6588067)

[tdanielsmusic]

On 2012/10/06 07:44:51, Trevor Daniels wrote:

I think I would prefer to name this function \undo.
This more accurately expresses what it does:
\undo\voiceOne reverses everything that \voiceOne
does, or did.  The action of \un\voiceOne is not
so intuitively obvious, nor does it make an English
work or phrase.


Should be "word", not "work", of course.  My fingers seem
to get more dyslexic every day :(

Trevor



http://codereview.appspot.com/6588067/

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

Re: [talk] why it'd be great to have web interface for submitting simple doc patches

[James]

Hello,

On 6 October 2012 09:51, Janek Warchoł  wrote:
> Just a musing
> I think the case shown below would perfectly qualify for "could you
> write a documentation patch for this? it can be done with a web
> interface, instructions are here" - if we had the web interface.
>
> On Sat, Oct 6, 2012 at 10:44 AM, Janek Warchoł  
> wrote:
>> On Sat, Oct 6, 2012 at 2:38 AM, Brad Smith  wrote:
>>> When should you
>>> use ly:pitch and when should you use ly:music? (Is there a place in
>>> the documentation that is good for learning these things?)
>>
>> I'm no expert on music functions, but i'd say that ly:music? is used
>> when the argument would be a music expression, e.g. { c8 d-. e-. c-.
>> }, while ly:pitch? is used when the argument is a note name.
>> This /should/ be in the documentation.  Could you make a bug report about it?
>>
>> hope this helps,
>> Janek
>
> I know that everyone can make a simple email with doc suggestion and
> send it to the mailing list, but then someone has to maintain it.
> Also, several times when i asked users for such suggestions they were
> very vague and i couldn't just copy-and-paste them (and i didn't have
> time to do more).  If we presented them with a web interface where
> they could write the actual change, it should work way better.  Just
> look at Wikipedia.

How is a web interface easier than email to enter information?

Also Wikipedia is still maintained (and checked) by someone - who
would that be in this case, oh I know lets get a group of people to
monitor this website and if they find any comprehensible requests then
they can create a tracker so that users don't request the same thing
over and over. This group of people should have a name too.. how about
Bugsquad... oh wait... ;)

The email lists are also archived, while it isn't a perfect system,
Bug squad are great at catching most things, and also clarifying with
the contact if they don't understand it.

I think you have proven your own point when you say

> Also, several times when i asked users for such suggestions they were
> very vague

And being vague in an email vs vague on a website is different how?

> and i couldn't just copy-and-paste them (and i didn't have
> time to do more).

Right, so you fwd to bug list and bugsquad take care of it if they can.

James

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

Re: Provide an \un function for turning overrides and sets into reverts and unsets (issue 6588067)

[David Kastrup]

Janek Warchoł  writes:

> On Sat, Oct 6, 2012 at 11:15 AM, David Kastrup  wrote:
>> Janek Warchoł  writes:
>>> I think it would be good to polish this, so that this either works or
>>> always produces syntax error.
>>
>> Figuring out heuristics when or when one should not issue a warning is
>> not all that easy to decide with a reasonable amount of consistency, and
>> this is not a problem particular to \undo.
>
> ok.

Not that this would not be useful.  It's just that it's a lot of detail
work and finetuning without providing any new functionality.  To get a
warning, you need to actually _run_ the source file, and in most cases
that means that proofreading would equally well tell you what you want
to know.  So the return for the one-time investment in programming is
rather small.  I won't object if anybody wants to work on this, but at
the current point of time I myself have stuff I consider more important.

-- 
David Kastrup

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

Re: Patchy email from PhilH

[Phil Holmes]

- Original Message - 
From: "John Mandereau" 

To: 
Cc: 
Sent: Saturday, October 06, 2012 3:13 AM
Subject: Re: Patchy email from PhilH



This email looks like you're using an old revision of Patchy; in case it
doesn't include convenience/safety checks before pushing to master
(introduced in commit 054d8101e7bcd54bc8db40092b617bb8b2220b84), please
update.



I am.  Willdo.

--
Phil Holmes

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

Re: [talk] why it'd be great to have web interface for submitting simple doc patches

[Janek Warchoł]

Hi,

On Sat, Oct 6, 2012 at 11:34 AM, James  wrote:
> How is a web interface easier than email to enter information?

I should've been more specific.  I meant a web interface that would
not only allow entering information, but also handle the patch - a
formal patch, not just a suggestion.
Take github for example: anyone, even if they see a project and git
for the first time, can click "make a fork", navigate to specific
file, write changes using web interface, make a commit (a formal
commit, not just a verbal description of changes - to do this
currently you need git or LilyDev), send a pull request.  Project
maintainer looks at the request (this is the review part), accepts it,
and voila! Done.
Of course our workflow is slightly different, but i could imagine a
tool that would show users actual doc files, allow them to make
changes to them, create a commit and put it for review.

> And being vague in an email vs vague on a website is different how?

If you're writing an email with a /suggestion/, you can write "i think
that there should be information about x, y z, blah blah because of
something, but i'm not sure what the wording should be".  That's
vague.  If you open a .texi file with appropriate doc section, and
have to write *actual changes to the real file*, you cannot be vague.
Noone in their right mind would put for a review a patch that adds
vague sentences to the actual doc files, like "there should be
information about x here, y is confusing".

I hope this is more clear now.

Janek

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

Next release

[Phil Holmes]

I'm currently building 2.17.4 and plan to upload it tonight and have it 
available tomorrow.  Please use 2.17.5 for claiming fixes on the issues list 
from now.


--
Phil Holmes



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

Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)

[Marc Hohl]

Am 06.10.2012 11:23, schrieb Janek Warchoł:

On Fri, Oct 5, 2012 at 9:42 PM, Thomas Morley
 wrote:

2012/10/5  :

It just occured to me: is there any way to specify different span bar
lines (at the end of the line and at the beginning of the line)?

Marc and me, we discussed this some time ago and decided not to
provide that functionality.
It would make things more complicated for the user and I think it is a
rarely needed feature.

Sorry for missing that part of the discussion.
If it's not too late to speak my mind, i think that it would be a
shame to have such an awesome and powerful barline interface without
giving users simple way to choose span barline behaviour.

I would imagine the user interface ("syntax") to be like this:
(define-bar-line (a b c) (x y z))
or
(define-bar-line ((a b c) . (x y z)))

where (a b c) are the barlines (mid-system, end-of-system,
beginning-of-system respectively) and (x y z) are the span barlines,
in the same order as barlines.
And it would be nice if
(define-bar-line (a b c) (x))
was equivalent to
(define-bar-line (a b c) (x x x))

Any other opinions about this feature?
It may make sense to extend the interface to allow for different
span bars as well, but since I am quite busy for the next few
days, it will take some time...

Regards,

Marc


cheers,
Janek




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

Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)

[Marc Hohl]

Am 30.09.2012 22:03, schrieb d...@gnu.org:

On 2012/09/30 19:44:49, marc wrote:

Am 30.09.2012 11:02, schrieb d...@gnu.org:
> [...]
> First, the define-public is asking for trouble. You are exposing an
> internal Scheme data structure to users and make it overwritable by

the

> user. If the user follows this invitation, the effects will bleed

over

> from session to session. Never do that.
Ok.


No, it's not ok.  Hold your horses, this is another case too stupid for
documenting and walking people through.  Give me two days, and then you
replace your define-public for the alists with define-session, and
that's it.  The rest of the code stays as it is.

Hi David,

I just saw that define-session is available now.

I replaced the definition of the empty alists in my patch with 
define-session-public,
but when I compile input/regression/bar-line-define-bar-glyph.ly, I 
still get the

Parsed object should be dead error messages.

Do I use the define-session-public commands in the right way?

As I understand, define-session-public works as define-public, but for 
the current session

only, define-session is the per-session equivalent to define.

Regards,

Marc



I'll make define-session do everything that is needed.

Just that it is possible to learn all the internals of LilyPond session
does not mean that it makes sense that you are required to do so just in
order to accomplish a simple task.

http://codereview.appspot.com/6498052/




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

Re: "unofficial GOP proposal" organization of GLISS discussions

[Marc Hohl]

Am 05.10.2012 18:34, schrieb Janek Warchoł:

Hi all,

i find it hard to keep up with our GLISS discussions.  I've also heard
that the amount of technical details, digressions and
"multithreadedness" stops some people from participating, as they
don't have enough time to read long conversations carefully.

Therefore i suggest to visibly separate discussing problems from
discussing solutions.
Currently we are mostly discussing ideas for syntax, i.e. "let's have
syntax X doing Y".  I suggest that for several weeks we shall focus on
"i find syntax W confusing" and "i find notation Z
difficult/inconvenient to express in current syntax" instead.  We
would add syntax problems that we identify as issues to the tracker.
After we've finished gathering them, we'll sort the issues and *then*
we would discuss how to solve them.


I second this in principle, but I fear that it would not be that easy
to separate discussions about "defects" from those about syntax
ideas in every case.


Why do it this way?
- we'll see the big picture better
- we'll be able to schedule the discussions about solutions, so it'll
be easier to participate in them

+1


And perhaps most importantly: when someone posts a syntax *idea*,
there's a chance that syntax experts will reply "omg wtf?! this won't
work".  This leads to frustration.  On the other hand, if we discuss
our *problems*, syntax experts can just answer "it would be reasonable
to solve it this or that way" - and voila! less frustration.

+1

Regards,

Marc


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

Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)

[David Kastrup]

Marc Hohl  writes:

> Am 30.09.2012 22:03, schrieb d...@gnu.org:
>> On 2012/09/30 19:44:49, marc wrote:
>>> Am 30.09.2012 11:02, schrieb d...@gnu.org:
>>> > [...]
>>> > First, the define-public is asking for trouble. You are exposing an
>>> > internal Scheme data structure to users and make it overwritable by
>> the
>>> > user. If the user follows this invitation, the effects will bleed
>> over
>>> > from session to session. Never do that.
>>> Ok.
>>
>> No, it's not ok.  Hold your horses, this is another case too stupid for
>> documenting and walking people through.  Give me two days, and then you
>> replace your define-public for the alists with define-session, and
>> that's it.  The rest of the code stays as it is.
> Hi David,
>
> I just saw that define-session is available now.
>
> I replaced the definition of the empty alists in my patch with
> define-session-public,
> but when I compile input/regression/bar-line-define-bar-glyph.ly, I
> still get the
> Parsed object should be dead error messages.
>
> Do I use the define-session-public commands in the right way?
>
> As I understand, define-session-public works as define-public, but for
> the current session
> only, define-session is the per-session equivalent to define.

Correct.

I did not really do a review of the barline code, just pointed out
things that struck me as wrong while glancing over it.

The "parsed objects should be dead" message implies that objects with
data _types_ that should not exist at the start of a session have
survived beyond the end of a session.

So the absence of such messages does not imply that your sessions are
clean, just that there are no blunders that can be detected from the
_types_ of the surviving objects alone.

-- 
David Kastrup

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

Re: lilypond-book: treat iffalse sections in latex as block comments (issue 6584073)

[Reinhold Kainhofer]

On 2012-10-06 06:33, lemzw...@googlemail.com wrote:


http://codereview.appspot.com/6584073/diff/1/python/book_latex.py
File python/book_latex.py (right):

http://codereview.appspot.com/6584073/diff/1/python/book_latex.py#newcode88
python/book_latex.py:88: \\iffalse.*\\fi))''',
On 2012/10/06 02:12:41, Julien Rioux wrote:

.* should be replaced by the non-greedy .*?


Yes :-)


Absolutely, was my mistake.


http://codereview.appspot.com/6584073/diff/1/python/book_latex.py#newcode88
python/book_latex.py:88: \\iffalse.*\\fi))''',
As David has commented on the list, I would prefer if you replaced the
\iffalse ... \fi with a higher-level command, namely \begin{comment} ...
\end{comment} (from the `comment' package).


So, your opinion is that lilypond-book SHOULD process the \lilypond{...} 
code inside the \iffalse  section and spectacularly fail. If users are 
using \iffalse -- I am for example one of those who use \iffalse to 
quickly comment out some parts temporarily -- then lilypond-book would 
still require everything between \iffalse and \fi to be in correct 
lilypond syntax and will create snippet images for all those snippets:


\documentclass[a4paper, 12pt]{article}
\begin{document}
TODO

\iffalse
This is a template for my future snippets:
\lilypond{Code comes here}
\fi

\end{document}



Shall lilypond-book really fail for (and process) snippets that will NOT 
be included by latex???




First of all, this syntax
suits LaTeX better since it resembles normal environments.  Second, it
is a bad idea in general to expose \ifXXX to the top level; in other
words, users should never do that.


But fact is, people ARE using \iffalse to temporarily comment out larger 
parts of latex files. With my colleagues, I have never seen 
\begin{comment} for comments, all the researchers I have worked with so 
far were using \iffalse.


Also, this is not about advocating what latex users should use, but 
handling whare users are using currently. So, I will add \begin{comment} 
to the pattern, too, but I still think that lilypond-book SHOULD ignore 
everything inside \iffalse.



Reason is that \ifXXX is handled
very special in TeX since you can define, say, \ifFoo which also pairs
with the next \fi, making correct balancing of nested \ifXXX commands
quite delicate and very hard to debug.


Sure, it's not the perfect way, but it's the quick-and-dirty way.
I'm also aware that lilypond-book will not be able to handle nested 
\ifXXX correctly. However, in the worst case, it will process some code 
after the first \fi and before the final \fi of the \iffalse. But that's 
still better than the current situation, where it processes everything 
between \iffalse and \fi.


Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com

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

Re: "unofficial GOP proposal" organization of GLISS discussions

[David Kastrup]

Marc Hohl  writes:

> Am 05.10.2012 18:34, schrieb Janek Warchoł:
>
>> i find it hard to keep up with our GLISS discussions.  I've also
>> heard that the amount of technical details, digressions and
>> "multithreadedness" stops some people from participating, as they
>> don't have enough time to read long conversations carefully.

I would want to venture the opinion that there is no substitute for
reading a conversation before putting forward an opinion.

A discussion is not a shouting match.  If a point has been carefully
made and reasoned, there should be no necessity to keep remaking and
rereasoning it in order not have it drowned out in the clutter from
people who can't be bothered getting acquainted with the context before
chipping in.

Yes, this makes it harder to contribute, but it increases the likelihood
of making a _useful_ contribution.  Also it does not help the motivation
of those people who have taken the effort of making a well-reasoned
point if they find that this effort has been quite futile.

>> Therefore i suggest to visibly separate discussing problems from
>> discussing solutions.
>> Currently we are mostly discussing ideas for syntax, i.e. "let's have
>> syntax X doing Y".  I suggest that for several weeks we shall focus on
>> "i find syntax W confusing" and "i find notation Z
>> difficult/inconvenient to express in current syntax" instead.  We
>> would add syntax problems that we identify as issues to the tracker.

I don't think that the tracker is necessarily a good place for "fuzzy"
feelings like that.  It would make sense to let them mature in
discussion into more concrete problem descriptions before putting them
in the tracker.

If you take a look at the tracker contents, you'll see that an issue
that has not seen an activity for a few weeks is quite likely not to see
activity for a few years.  Having a concrete, identifiable problem
description makes it more likely that it will get picked up at some
point in future again.

>> After we've finished gathering them, we'll sort the issues and *then*
>> we would discuss how to solve them.
>
> I second this in principle, but I fear that it would not be that easy
> to separate discussions about "defects" from those about syntax
> ideas in every case.

Well, my own problem with that is that our resources, and that includes
our attention span, are not unlimited.  There has been a lot of detailed
and partly rather exhausting (and ongoing) discussion on a recent set of
additions that can currently be labeled as \hide/\omit\single\undo.

The discussion was focused around concrete proposals, concrete code, and
concrete use cases.  The solutions we arrived at were a mixture of
"bikeshedding" in the form of agreeing on the best form of naming some
constructs interspersed with generic mechanisms evolving from the wish
of _avoiding_ finding new names for something that can be constructed
systematically.  Much of the process was shaped in a back-and-forth
between me as the code writer/proponent and potential documentation
writers (James, Trevor) in need of semantics that they were able to both
understand and explain, with occasional user views and questions from
Janek, Marc, Graham and others.  At any point of time, only very few
people were active here, but I like the results achieved in that manner,
while the process was rather cumbersome.

Now separating the problem-finding and solution-finding and coding
processes will render the whole procedure less effective of actually
moving towards a good _set_ of solutions fitting a problem space that
has been incrementally extended in order to offset problems stemming
from the solutions of only the original problems.

>> Why do it this way?
>> - we'll see the big picture better
>> - we'll be able to schedule the discussions about solutions, so it'll
>> be easier to participate in them
> +1

I don't really think we can "schedule" discussions about solutions when
much of the discussion can only be done in the light of actual changes
being written and tested.

>> And perhaps most importantly: when someone posts a syntax *idea*,
>> there's a chance that syntax experts will reply "omg wtf?! this won't
>> work".  This leads to frustration.

The problem is almost never an absolute "this won't work" but rather "I
don't see that this would come at an affordable price".  The price falls
into two categories again: upfront price (somebody has to do the actual
coding) and followup price (everybody has to live with the consequences
and side effects).

A non-coding user has no means to do anything about the upfront price,
and will rarely have the overview over the followup price.

>> On the other hand, if we discuss our *problems*, syntax experts can
>> just answer "it would be reasonable to solve it this or that way" -
>> and voila! less frustration.
> +1

I don't see the point in discussing discussing all too much.  It spends
time and does not really lead anywhere.  Let us just see where the
recent user poll on the 

Re: lilypond-book: treat iffalse sections in latex as block comments (issue 6584073)

[David Kastrup]

Reinhold Kainhofer  writes:

> On 2012-10-06 06:33, lemzw...@googlemail.com wrote:
>
>> http://codereview.appspot.com/6584073/diff/1/python/book_latex.py#newcode88
>> python/book_latex.py:88: \\iffalse.*\\fi))''',
>> As David has commented on the list, I would prefer if you replaced the
>> \iffalse ... \fi with a higher-level command, namely \begin{comment} ...
>> \end{comment} (from the `comment' package).
>
> So, your opinion is that lilypond-book SHOULD process the
> \lilypond{...} code inside the \iffalse  section and spectacularly
> fail.

Reality check: lilypond-book does not "spectacularly fail".  It
processes the included snippets which LaTeX then just skips.
lilypond-book just takes unnecessary effort.

> If users are using \iffalse -- I am for example one of those who use
> \iffalse to quickly comment out some parts temporarily -- then
> lilypond-book would still require everything between \iffalse and \fi
> to be in correct lilypond syntax and will create snippet images for
> all those snippets:

Exactly.

> \documentclass[a4paper, 12pt]{article}
> \begin{document}
> TODO
>
> \iffalse
> This is a template for my future snippets:
> \lilypond{Code comes here}
> \fi
>
> \end{document}
>
> Shall lilypond-book really fail for (and process) snippets that will
> NOT be included by latex???

\iffalse\fi is not a LaTeX sequence.  If it were, there would be little
excuse _not_ to heed its inherent nesting, like TeX does.  If you write
\iffalse
\ifverbose Hey this is nice!. \fi
This is a template for my future snippets:
\lilypond{Code comes here}
\fi

then lilypond-book will spectacularly fail as it, as opposed to
TeX/LaTeX, is not able to properly match \if...\fi.

Using and heeding the comment environment, in contrast, does not suffer
from that problem.

>> First of all, this syntax
>> suits LaTeX better since it resembles normal environments.  Second, it
>> is a bad idea in general to expose \ifXXX to the top level; in other
>> words, users should never do that.
>
> But fact is, people ARE using \iffalse to temporarily comment out
> larger parts of latex files. With my colleagues, I have never seen
> \begin{comment} for comments, all the researchers I have worked with
> so far were using \iffalse.
>
> Also, this is not about advocating what latex users should use, but
> handling whare users are using currently. So, I will add
> \begin{comment} to the pattern, too, but I still think that
> lilypond-book SHOULD ignore everything inside \iffalse.

The problem is that lilypond-book has _no_ way to figure out just _what_
is supposed to be "everything inside \iffalse" if you ever actually
start using TeX conditionals for any other purpose than outcommenting
code.

>> Reason is that \ifXXX is handled
>> very special in TeX since you can define, say, \ifFoo which also pairs
>> with the next \fi, making correct balancing of nested \ifXXX commands
>> quite delicate and very hard to debug.
>
> Sure, it's not the perfect way, but it's the quick-and-dirty way.

> I'm also aware that lilypond-book will not be able to handle nested
> \ifXXX correctly. However, in the worst case, it will process some
> code after the first \fi and before the final \fi of the \iffalse. But
> that's still better than the current situation, where it processes
> everything between \iffalse and \fi.

I disagree.  lilypond-book is not smart enough to know about the LaTeX
structure of the document.  If you want smart processing of typeset
material, the lilypond environment would have to be processed by LaTeX
rather than replaced by lilypond-book acting as a preprocessor.

That would be nice to have and obliterate the need for a separate .lytex
file, but it would also make it unfeasible to use lilypond environments
and commands nested in contexts (like in macro arguments) where LaTeX's
\verb and other "verbatim-like" constructs would also experience
problems.

-- 
David Kastrup

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

Re: [talk] why it'd be great to have web interface for submitting simple doc patches

[Joseph Rushton Wakeling]

On 10/06/2012 11:34 AM, James wrote:

How is a web interface easier than email to enter information?


Well, the problem with simple doc patches is that to submit them to Lilypond you 
have to go through the same procedure as if you were submitting a code patch, 
which means uploading to Riedveld etc., which in turn means installing some 
custom code on your machine -- see:

http://www.lilypond.org/doc/v2.17/Documentation/contributor/commits-and-patches#uploading-a-patch-for-review

 ... and as it's a doc patch, there's not really any reason to do this, because 
it's not going to break any unittests.


Yes, you can wait for some other dev team member to pick up your small patch and 
submit it, but that puts the onus on them to do the work.  So, a simplified 
method to reliably submit doc patches would be quite nice to have.


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

Re: [proposal] easy triplets and tuplets - was [talk] easy tuplets

[Joseph Rushton Wakeling]

On 10/05/2012 09:31 AM, Keith OHara wrote:

It is easier to keep the order straight if you write a 5:4 tuplet
as \tuplet 5/4 {}


Is there any reason why you couldn't write \tuplet 5:4 {} ... ?  Keeps exact 
match between musical and Lilypond syntax and avoids the potential mental block 
of having an identical but inverted notation for \tuplet and \times.



We have to invert the tuplet indication when we use \scaleDurations 4/5 {}
(such as to print tuplets without brackets) but the word 'Duration' helps
us remember we are specifying the duration of notes, not number of notes.


Isn't this a case where you might want \tuplet* and \times* functions to put in 
place the same effect but with no number/ratio/bracket printed?  (The function 
name might need to be different -- I'm just using it here by analogy to LaTeX' 
\section and \section* commands to create titles with and without a number.)


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

Re: [proposal] easy triplets and tuplets - was [talk] easy tuplets

[David Kastrup]

Joseph Rushton Wakeling  writes:

> On 10/05/2012 09:31 AM, Keith OHara wrote:
>> It is easier to keep the order straight if you write a 5:4 tuplet
>> as \tuplet 5/4 {}
>
> Is there any reason why you couldn't write \tuplet 5:4 {} ... ?

Yes.  5/4 is an item that the parser is readily able to recognize as a
function argument.  5:4 isn't.

> Keeps exact match between musical and Lilypond syntax

LilyPond syntax is not an "exact match" in any sense of the word, so
there is nothing particularly important to "keep" here.

> and avoids the potential mental block of having an identical but
> inverted notation for \tuplet and \times.

Just stop using \times and you're all set.

>> We have to invert the tuplet indication when we use \scaleDurations
>> 4/5 {} (such as to print tuplets without brackets) but the word
>> 'Duration' helps us remember we are specifying the duration of notes,
>> not number of notes.
>
> Isn't this a case where you might want \tuplet* and \times* functions
> to put in place the same effect but with no number/ratio/bracket
> printed?  (The function name might need to be different -- I'm just
> using it here by analogy to LaTeX' \section and \section* commands to
> create titles with and without a number.)

Basically, it is \omit TupletNumber, and I don't really know whether
that warrants a separate command.

-- 
David Kastrup


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

Re: [talk] why it'd be great to have web interface for submitting simple doc patches

[James]

Hello,

On 6 October 2012 15:23, Joseph Rushton Wakeling
 wrote:
> On 10/06/2012 11:34 AM, James wrote:
>>
>> How is a web interface easier than email to enter information?
>
>
> Well, the problem with simple doc patches is that to submit them to Lilypond
> you have to go through the same procedure as if you were submitting a code
> patch, which means uploading to Riedveld etc., which in turn means
> installing some custom code on your machine -- see:
> http://www.lilypond.org/doc/v2.17/Documentation/contributor/commits-and-patches#uploading-a-patch-for-review

That;s not technically true. Git-cl is supposedly to ease updating the
tracker and posting to reitveld at the same time.

You can upload your patch manually if you so wish, we just ask that we
have Rietveld for code review and the tracker to keep.. err track of
what is what and where etc.

>
>  ... and as it's a doc patch, there's not really any reason to do this,
> because it's not going to break any unittests.

Pardon?

Says someone who evidently has never built, submitted or tested 'doc'
patches for LP.

I think you perception of what we do and why is skewed.

>
> Yes, you can wait for some other dev team member to pick up your small patch
> and submit it, but that puts the onus on them to do the work.

So does poorly submitted documentation suggestions, but hey.. *anyone*
can write documentation right? With clear understanding, good syntax,
spelling, sentence structure and oh and good lilypond examples.
Easy-peasy.

James

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

Re: [talk] why it'd be great to have web interface for submitting simple doc patches

[Joseph Rushton Wakeling]

On 10/06/2012 04:46 PM, James wrote:

Says someone who evidently has never built, submitted or tested 'doc'
patches for LP.


Er ... yes, I have.  Actually my objections to having to use git-cl were based 
on my experience of trying to submit a simple, small doc patch that I'd built 
and tested.  It felt a rather hefty and complicated amount of stuff to do 
compared to simply emailing someone a set of patches, or submitting a merge 
request on GitHub.



I think you perception of what we do and why is skewed.


Well, I can see that it's important to test that doc patches _build_ OK, but I 
don't see how the code test suite is relevant to documentation.  But I'm sorry 
if I've overlooked something here.



So does poorly submitted documentation suggestions, but hey.. *anyone*
can write documentation right? With clear understanding, good syntax,
spelling, sentence structure and oh and good lilypond examples.
Easy-peasy.


... but as you and I both know, writing correct TeXinfo that builds without 
error is not quite so simple.  I do know what that entails, and I do ensure that 
any patches I submit build correctly.


If I've missed some important aspect of testing which _is_ relevant to docs, 
then I apologize.  But I don't think Janek's idea that it should be possible to 
simplify doc submissions is wrong.


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

Re: [talk] why it'd be great to have web interface for submittingsimple doc patches

[Phil Holmes]

- Original Message - 
From: "Joseph Rushton Wakeling" 

To: "James" 
Cc: 
Sent: Saturday, October 06, 2012 4:10 PM
Subject: Re: [talk] why it'd be great to have web interface for 
submittingsimple doc patches




On 10/06/2012 04:46 PM, James wrote:

Says someone who evidently has never built, submitted or tested 'doc'
patches for LP.


Er ... yes, I have.  Actually my objections to having to use git-cl were 
based on my experience of trying to submit a simple, small doc patch that 
I'd built and tested.  It felt a rather hefty and complicated amount of 
stuff to do compared to simply emailing someone a set of patches, or 
submitting a merge request on GitHub.



I think you perception of what we do and why is skewed.


Well, I can see that it's important to test that doc patches _build_ OK, 
but I don't see how the code test suite is relevant to documentation.  But 
I'm sorry if I've overlooked something here.


Unfortunately, testing that docs compile cleanly takes about 15 times as 
long as code, so it's not for the underpowered or faint hearted.  Used to be 
2 3/4 hours on my virtual machine.


--
Phil Holmes


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

Re: [talk] why it'd be great to have web interface for submittingsimple doc patches

[Joseph Rushton Wakeling]

On 10/06/2012 05:21 PM, Phil Holmes wrote:

Unfortunately, testing that docs compile cleanly takes about 15 times as long as
code, so it's not for the underpowered or faint hearted.  Used to be 2 3/4 hours
on my virtual machine.


Yes, true.  The from-scratch build time for docs is pretty hefty, though from my 
memory once you've got it built _once_, building an edited version takes much 
less time.  The build system improvements that came in a while ago (am I right 
this was your work?) made it much better than it was a few years back.


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

Re: [proposal] easy triplets and tuplets - was [talk] easy tuplets

[Ian Hulin]

On 05/10/12 08:10, James wrote:
> Hello,
> 
> On 5 October 2012 00:19, Ian Hulin  wrote:
>> This is a proposal to move the triplet/tuplet discussion forward.
>>
>> There will be new commands to supplement (or eventually replace) the
>> current \times command.
>>
>> 1. \tuplet n/m {}
>> %  does what \times does, but not so easily confused with \time
>> %  command.
>> 2. \triplet {} % shorthand for current
>> %  \times 2/3 command
>> 3. \duplet {> %  \times 3/2 command
>> 4. \quadruplet {> %  \times 6/4 command
>> 5. \sextuplet {> %  \times 4/6 command
> 
> Do we need all these commands?
> 
> Can't we just have \tupelet and then a qualifier (or whatever it is
> called) that then determines if it is 3/2. 2/3, 6/4 etc.
> 
It would be \tuplet, I assume that was a typo on your part.
We already have a qualifier, or rather an argument on \times - it's the
fraction.
The name needs to change even if we don't add the shorthands for
triplets etc. because the command looks too closely related to the time
signature command \times when a source score is read by a human being.
> I may be the only one but no one that I play with makes any
> distinction from a musical point of view between a 'tupelet' that is
> 2/3 and one that is, say, 5/3 or 6/4. They are all 'tupelets.
> 
> http://en.wikipedia.org/wiki/Tuplet
> 
> Am I missing something Ian (if so, sorry)?
> 
Yes.

'triplet', 'duplet', 'quadruplet' 'quintuplet' and 'sextuplet' are used
in muso-speech to distinguish the commoner forms of tuplet.

See Reinhold's reply as German has a parallel set of similar terms
'Triole', 'Duole' etc.

I fact I think tuplet derives from the end portion of terms like
'sextuplet'.

Also, if my poor addled old dinosaur brain remembers right, at least
some of these are, or have been, taught as part of ABRSM[1] theory in
the UK.

The aim of providing these is to make LilyPond source slightly more
readable to humans.

These are available *in parallel* with \tuplet and \times (though there
migh be a decision later on to deprecate \times)

Cheers,

Ian
[1] Associated Board of the Royals Schools of Music.

> James
> 



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

Re: [talk] why it'd be great to have web interface for submittingsimple doc patches

[Phil Holmes]

- Original Message - 
From: "Joseph Rushton Wakeling" 

To: "Phil Holmes" 
Cc: "James" ; 
Sent: Saturday, October 06, 2012 4:32 PM
Subject: Re: [talk] why it'd be great to have web interface for 
submittingsimple doc patches




On 10/06/2012 05:21 PM, Phil Holmes wrote:
Unfortunately, testing that docs compile cleanly takes about 15 times as 
long as
code, so it's not for the underpowered or faint hearted.  Used to be 2 
3/4 hours

on my virtual machine.


Yes, true.  The from-scratch build time for docs is pretty hefty, though 
from my memory once you've got it built _once_, building an edited version 
takes much less time.  The build system improvements that came in a while 
ago (am I right this was your work?) made it much better than it was a few 
years back.



Most of the tidying up was me.  There were a number of other improvements in 
the way dependencies were calculated that Julien was responsible for.  John 
M has also made some improvements.


As you say, compile-edit-compile cycles are shorter than the full build, but 
can occasionally not reveal errors, so for a proper test it's always better 
to nuke the build directory and rebuild from scratch.


And given the amount of effort involved in all this, using git-cl seems a 
small additional step.


--
Phil Holmes 



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

Re: [talk] why it'd be great to have web interface for submitting simple doc patches

[David Kastrup]

James  writes:

> Says someone who evidently has never built, submitted or tested 'doc'
> patches for LP.

Joseph Wakeling (12):
  Extended documentation on Turkish classical music and Makam.
  Turkish classical music corrections.
  Turkish classical music documentation tweaks.
  Contemporary music: overview of new specialist notation section.
  Contemporary music: pitch and harmony.
  Doc: Sketch of topics for contemporary approaches to rhythm
  Doc: Further Reading for contemporary music.
  Doc: fix duplicate node name.
  COPYING rewrite to clarify licensing.
  COPYING.DOCUMENTATION tweak to mention (lack of) front/back cover texts.
  Doc: CG: Sending and receiving patches via email.
  CG tweak: some extra info on make doc and doc build times

> I think you perception of what we do and why is skewed.
>
>>
>> Yes, you can wait for some other dev team member to pick up your
>> small patch and submit it, but that puts the onus on them to do the
>> work.
>
> So does poorly submitted documentation suggestions, but hey.. *anyone*
> can write documentation right? With clear understanding, good syntax,
> spelling, sentence structure and oh and good lilypond examples.
> Easy-peasy.

Existing documentation beats non-existing documentation.  Our focus
should not be on how to fend off contributions of dubious quality, but
rather on how we can engage contributors in processes that help them
produce good and consistent quality.  Can we find ways to power our
processes more with positive feedback rather than negative feedback?  If
we start with a contributor offering deficient contributions, how do we
arrive at this contributor offering good contributions rather than this
contributor ceasing work on LilyPond?

I am not proposing "accept bad contributions".  How can we make it easy
for someone to improve his work?  I am not sure that the answers for
documentation are necessarily identical to the answers for code.

-- 
David Kastrup


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

Re: [talk] why it'd be great to have web interface for submittingsimple doc patches

[Joseph Rushton Wakeling]

On 10/06/2012 05:46 PM, Phil Holmes wrote:

As you say, compile-edit-compile cycles are shorter than the full build, but can
occasionally not reveal errors, so for a proper test it's always better to nuke
the build directory and rebuild from scratch.


Out of curiosity, what kind of errors?  I imagine stuff involving 
cross-references, the index, etc.?



And given the amount of effort involved in all this, using git-cl seems a small
additional step.


It's not too much if you've already got the hang of Git, if you're relatively 
experienced with development tools etc.  But all of that feels a bit much if all 
you want to do is submit a small doc update and you're not a regular contributor.


I'm not demanding a solution here, but I don't think Janek's suggestion should 
be dismissed.  I think that David has it right when he says the best way to 
handle code and the best way to handle documentation are not necessarily the 
same, and personally I think the git-cl/Rietveld approach is too slanted towards 
code requirements.


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

Re: [proposal] easy triplets and tuplets - was [talk] easy tuplets

[Ian Hulin]

On 05/10/12 08:47, David Kastrup wrote:
> Ian Hulin  writes:
> 
>> 1. Should the new \tuplet retain the \times meaning of the fraction,
>> i.e. \tuplet 2/3 {c8 c c} uses 2/3 because that's what you'd use if you
>> were just using durations: c8*2/3 c c , or
>> invert it as \tuplet 3/2 {c8 c c} because that reflects better the
>> "three notes in the time of two" definition of a triplet.
> 
> Well, I definitely remember enough of my learning curve with LilyPond to
> recommend taking the opportunity of renaming for reversing the fraction,
> making it correspond with the output from
> 
> \override TupletNumber #'text = #tuplet-number::calc-fraction-text

I'll take that as a 1+ for \tuplet 3/2 { blah...} representing a
triplet/Triole.

> 
> I don't think we need a wealth of shorthands, though: we can instead
> just take the tuplet number as a shorthand as 3 is perfectly
> distinguishable from 3/1 as LilyPond input.
> 
> So \tuplet 3 can be the same as \tuplet 3/2, and \tuplet 2 the same as
> \tuplet 2/3, and \tuplet 5 as tuplet 5/4 and \tuplet 6 as \tuplet 6/4.
> 
> I am not sure whether other tuplet numbers are unambiguous enough to
> warrant a shorthand.
> 
Hmmm... interesting, but I'd still like like \tuplet to be able to
handle anything \times does.
We could handle your suggestion and achieve this with some fiddling
around at Scheme level, but I feel that it wouldn't support one of the
aims of the proposals of making the source code more readable for
musicians.  I think \triplet or \sextuplet would be simpler to
understand at first reading.

>> 2. Should the \tuplet command attempt to validate the length of the
>> incoming music expression?  I.e. add up the lengths of the constituent
>> notes in the music expression, and see if it would be a valid
>> note-length once multiplied (or divided depending on decision for 1.
>> above) the fraction.
> 
> Probably not.
> 
Thanks.  I'll take this as as -2 from you and Keith combined.

Many thanks for the feedback here and in other bits of the thread, it's
been really useful.

Cheers,

Ian



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

Re: [proposal] easy triplets and tuplets - was [talk] easy tuplets

[David Kastrup]

Ian Hulin  writes:

> On 05/10/12 08:47, David Kastrup wrote:
>> Ian Hulin  writes:
>> 
>>> 1. Should the new \tuplet retain the \times meaning of the fraction,
>>> i.e. \tuplet 2/3 {c8 c c} uses 2/3 because that's what you'd use if you
>>> were just using durations: c8*2/3 c c , or
>>> invert it as \tuplet 3/2 {c8 c c} because that reflects better the
>>> "three notes in the time of two" definition of a triplet.
>> 
>> Well, I definitely remember enough of my learning curve with LilyPond to
>> recommend taking the opportunity of renaming for reversing the fraction,
>> making it correspond with the output from
>> 
>> \override TupletNumber #'text = #tuplet-number::calc-fraction-text
>
> I'll take that as a 1+ for \tuplet 3/2 { blah...} representing a
> triplet/Triole.
>
>> 
>> I don't think we need a wealth of shorthands, though: we can instead
>> just take the tuplet number as a shorthand as 3 is perfectly
>> distinguishable from 3/1 as LilyPond input.
>> 
>> So \tuplet 3 can be the same as \tuplet 3/2, and \tuplet 2 the same as
>> \tuplet 2/3, and \tuplet 5 as tuplet 5/4 and \tuplet 6 as \tuplet 6/4.
>> 
>> I am not sure whether other tuplet numbers are unambiguous enough to
>> warrant a shorthand.
>> 
> Hmmm... interesting, but I'd still like like \tuplet to be able to
> handle anything \times does.

Why wouldn't it be able to handle anything \times does?  Feed it the
fraction for \times-like behavior, feed it an integer as a shorthand for
common tuplet types.

-- 
David Kastrup


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

[proposal] easy triplets and tuplets - Draft 2

[Ian Hulin]

Thanks to everyone for their feedback so far.
Here is Version 2 of the proposal.

There will be new commands to supplement (or eventually replace) the
current \times command.

1. \tuplet n/m {}
%  does what \times does, but not so easily confused with \time
%  command.
2. \triplet {} % shorthand for current
%  \times 2/3 command
3. \duplet {} % shorthand for current
%  \times 3/2 command
4. \quadruplet {} % shorthand for current
%  \times 6/4 command
5. \sextuplet {} % shorthand for current
%  \times 4/6 command
Discussions seemed to imply that we also might need
6. \quintuplet {} % shorthand for current
%  \times 4/5 command.

The design was deliberately restricted to providing
shorthands for the \times commands with 2:3 and 3:2 ratios expressed in
the n/m rational parameter, however there seemed to be a feeling that
the 5:4 ratio was just as common.  (See 6. above).

This should be relatively easy to implement by adding declarations to
music-functions-init.ly.

The following questions were put forward in Version 1:
1. Should the new \tuplet retain the \times meaning of the fraction,
i.e. \tuplet 2/3 {c8 c c} uses 2/3 because that's what you'd use if you
were just using durations: c8*2/3 c c , or
invert it as \tuplet 3/2 {c8 c c} because that reflects better the
"three notes in the time of two" definition of a triplet.

Feeling generally has been that \tuplet 3/2 {c8 c c} for a triplet was
better than the current \times 2/3 style.
One vote was for representing this as a ratio
e.g. \tuplet 3:2 {c8 c c}. The downside of this is that it would require
a parser extension, and provision of a home-brew ratio? predicate to
allow validation in the music function.
Another suggestion was that the commoner tuplets should be represented
as by an integer argument i.e. \tuplet 3 as an equivalent to the current
\times 2/3 and equivalent to \tuplet 3/2.  These would stand instead of
the proposed \triplet etc. commands.

Decisions:
Use the inverted fraction rather than the ratio format.
Use the above \triplet etc. commands in tandem with the new \tuplet:
they are more readable although less syntactically elegant.

2. Should the \tuplet command attempt to validate the length of the
incoming music expression?  I.e. add up the lengths of the constituent
notes in the music expression, and see if it would be a valid
note-length once multiplied (or divided depending on decision for 1.
above) the fraction.
Those who commented felt this was not possible.

Decision:
The \tuplet command will not attempt to validate the length of the
incoming music expression.




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

Re: [proposal] easy triplets and tuplets - Draft 2

[David Kastrup]

Ian Hulin  writes:

> Thanks to everyone for their feedback so far.
> Here is Version 2 of the proposal.
>
> There will be new commands to supplement (or eventually replace) the
> current \times command.
>
> 1. \tuplet n/m {}
> %  does what \times does, but not so easily confused with \time
> %  command.
> 2. \triplet {} % shorthand for current
> %  \times 2/3 command
> 3. \duplet {} % shorthand for current
> %  \times 3/2 command
> 4. \quadruplet {} % shorthand for current
> %  \times 6/4 command

I haven't seen quadruplets in the wild, so that seems like a stretch.
When they occur, it seems audacious to assume they are 6/4.  More likely
than not, I would expect them to be 3/4, like if you have 4 notes on a
halfmeasure in a 6/8 setting.  But they are infrequent enough that I
don't think we should even provide a best guess.

What about tupletSpannerDuration?  Wouldn't it make sense to have an
optional duration argument before the music argument for specifying it?

-- 
David Kastrup


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

Re: lilypond-book: treat iffalse sections in latex as block comments (issue 6584073)

[Werner LEMBERG]

> So, your opinion is that lilypond-book SHOULD process the
> \lilypond{...} code inside the \iffalse section and spectacularly
> fail.

It is debatable how much plain TeX code should be used at all in a
LaTeX document.  Just think of a latex->html translation.

> With my colleagues, I have never seen \begin{comment} for comments,
> all the researchers I have worked with so far were using \iffalse.

OK.

> So, I will add \begin{comment} to the pattern, too,

Thanks.

> but I still think that lilypond-book SHOULD ignore everything inside
> \iffalse.

OK.


Werner

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

Re: convert-ly (issue 2670) (issue 6610058)

[lemzwerg]

LGTM now.

http://codereview.appspot.com/6610058/

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

Re: [proposal] easy triplets and tuplets - Draft 2

[Werner LEMBERG]

> I haven't seen quadruplets in the wild, so that seems like a
> stretch.

They are quite common in late-romantic piano music.

> When they occur, it seems audacious to assume they are 6/4.  More
> likely than not, I would expect them to be 3/4, like if you have 4
> notes on a halfmeasure in a 6/8 setting.

The normal setting is to have four notes in a full 3/4 bar.


Werner

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

Re: [proposal] easy triplets and tuplets - Draft 2

[David Kastrup]

Werner LEMBERG  writes:

>> I haven't seen quadruplets in the wild, so that seems like a
>> stretch.
>
> They are quite common in late-romantic piano music.
>
>> When they occur, it seems audacious to assume they are 6/4.  More
>> likely than not, I would expect them to be 3/4, like if you have 4
>> notes on a halfmeasure in a 6/8 setting.
>
> The normal setting is to have four notes in a full 3/4 bar.

That would be \times 3/4 rather than \times 6/4, right?

-- 
David Kastrup


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

Re: [proposal] easy triplets and tuplets - Draft 2

[Werner LEMBERG]

>> The normal setting is to have four notes in a full 3/4 bar.
> 
> That would be \times 3/4 rather than \times 6/4, right?

Exactly.


Werner

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

Re: [proposal] easy triplets and tuplets - Draft 2

[Benkő Pál]

>>> The normal setting is to have four notes in a full 3/4 bar.
>>
>> That would be \times 3/4 rather than \times 6/4, right?
>
> Exactly.

four quarters, yes; four eigths are 6/4, and that's what I've seen.

regarding the \tuplet  shorthand: I would hate "\tuplet n"
meaning not "\tuplet n/1" but "\tuplet n/2" or something else
(but that probably means only that I wouldn't use that shorthand).

p

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

Re: [proposal] easy triplets and tuplets - Draft 2

[David Kastrup]

Benkő Pál  writes:

 The normal setting is to have four notes in a full 3/4 bar.
>>>
>>> That would be \times 3/4 rather than \times 6/4, right?
>>
>> Exactly.
>
> four quarters, yes; four eigths are 6/4, and that's what I've seen.
>
> regarding the \tuplet  shorthand: I would hate "\tuplet n"
> meaning not "\tuplet n/1" but "\tuplet n/2" or something else
> (but that probably means only that I wouldn't use that shorthand).

Well, since it really is a "symbolic integer" rather than numeric, it
would feel appropriate to write this as

\tuplet3 { ... }
\tuplet2 { ... }

Of course, the absence of the space is purely a matter of writing style
here; it makes no semantic difference.  But for _this_ usage pattern, it
feels like a somewhat natural choice.

-- 
David Kastrup

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

Re: Doc: improve documentation of Bézier curves (2858) (issue 6561064)

[tdanielsmusic]

Reviewers: Keith, david.nalesnik,

Message:
I've added an example showing two curves that start
at the same musical moment being shaped, as well as
the changes suggested by Keith and David.


http://codereview.appspot.com/6561064/diff/1/Documentation/notation/changing-defaults.itely
File Documentation/notation/changing-defaults.itely (right):

http://codereview.appspot.com/6561064/diff/1/Documentation/notation/changing-defaults.itely#newcode3953
Documentation/notation/changing-defaults.itely:3953: values are then
found by trial and error.
On 2012/09/28 06:45:50, Keith wrote:

.. and trial and error again if you change anything, or if the

line-breaking

changes, or if you need to switch between A4 and US letter paper ...


I take the point.  I've down-played this section by moving
it to the end and illustrated it with an example that
better shows its utility (allbeit a rather hackish one).

http://codereview.appspot.com/6561064/diff/1/Documentation/notation/changing-defaults.itely#newcode3977
Documentation/notation/changing-defaults.itely:3977: If cubic-shaped
curve is required the control points must be set
On 2012/09/28 06:45:50, Keith wrote:

A curve shaped like a cube ?
You mean S-shaped, or sigmoidal, or 'curve with inflection' or 'curve

that

changes the direction of its bend'?

Yes, but third-order Bézier curves are also called cubic.
Changed to "S-shaped".

http://codereview.appspot.com/6561064/diff/1/Documentation/notation/changing-defaults.itely#newcode3988
Documentation/notation/changing-defaults.itely:3988: { c4 e, f' d }
On 2012/09/28 06:45:50, Keith wrote:

A tiny bit ugly.



\relative c'' {
 c8( e b-> f d' a e-> g)
 \shape Slur #'((0 . 0) (5.5 . 0) (-5.5 . -10) (0 . -6))
 c8( e b-> f d' a e-> g)
   }



Accents make the point that the newly-shaped Slur is integrated into

the usual

collision-avoidance (distinct from other hand-tweaks like rotation and
extra-offset).


Excellent - thanks!

http://codereview.appspot.com/6561064/diff/1/Documentation/notation/changing-defaults.itely#newcode3996
Documentation/notation/changing-defaults.itely:3996: the ones calculated
automatically, remembering that a translation of
On 2012/09/28 06:45:50, Keith wrote:

You can probably skip the "remembering that.."
Discussions of Bezier curves always mention this, but it seems

implicit in

having the curves parametrized by "control points".


Done.

http://codereview.appspot.com/6561064/diff/1/Documentation/notation/changing-defaults.itely#newcode4027
Documentation/notation/changing-defaults.itely:4027:
On 2012/09/28 21:43:10, david.nalesnik wrote:

Perhaps at this point it would be helpful to include an example of

\shape

applied to a curve across a line break.  Something like this:



"The \shape function can also displace the control points of curves

which

stretch across line breaks.  Each piece of the broken curve can

receive its own

list of offsets.  In case changes to a particular segment are not

needed, the

empty list can serve as a placeholder."



\relative c'' {
   % () may be used as a shorthand for ((0 . 0) (0 . 0) (0 . 0) (0 .

0))

   \shape Slur #'(() ((0.5 . -1.5) (1 . 0.5) (0 . 0.5) (0 . -1.5)))
   c4( f g c
   \break
   d,4 c' f, c)
}



\layout {
   ragged-right = ##t
}


Done.

Description:
Doc: improve documentation of Bézier curves (2858)

 - add \shape function
 - show example of cubic-shaped slur

Please review this at http://codereview.appspot.com/6561064/

Affected files:
  M Documentation/notation/changing-defaults.itely


Index: Documentation/notation/changing-defaults.itely
diff --git a/Documentation/notation/changing-defaults.itely  
b/Documentation/notation/changing-defaults.itely
index  
26672bd791094b7e26d86e9c99124ae8716b473b..7b35497e99ce7569307ef73d271bf76cf36bd38a  
100644

--- a/Documentation/notation/changing-defaults.itely
+++ b/Documentation/notation/changing-defaults.itely
@@ -3892,11 +3892,27 @@ Notation Reference:
 @cindex Bézier curves, control points
 @cindex control points, Bézier curves

-Ties, slurs and phrasing slurs are drawn as third-order Bézier
+@code{Tie}s, @code{Slur}s, @code{PhrasingSlur}s, @code{LaissezVibrerTie}s  
and @code{RepeatTie}s are all drawn as third-order Bézier

 curves.  If the shape of the tie or slur which is calculated
 automatically is not optimum, the shape may be modified manually by
-explicitly specifying the four control points required to define
-a third-order Bézier curve.
+either
+
+@itemize
+@item
+a) explicitly specifying the four control points required to define
+a third-order Bézier curve, or
+
+@item
+b) specifying the displacements to be made to the control points of
+the automatically calculated Bézier curve.
+@end itemize
+
+Both methods are explained below.  The second method is more suitable
+if only slight adjustments to the curve are required; the first is
+better for creating curves which are quite different from the one
+which would be calculated automatically.
+
+@subsubsubheading Cubic Bézier

Re: [proposal] easy triplets and tuplets - Draft 2

[Keith OHara]

Ian Hulin  hulin.org.uk> writes:


There will be new commands to supplement (or eventually replace) the
current \times command.
1. \tuplet n/m {}



This should be relatively easy to implement by adding declarations to
music-functions-init.ly.


It is quite easy, so we can try it out with the attached file.

I did implement the fraction as an optional argument, so that \tuplet {} is a 
triplet (although I don't like the optional argument).

I didn't implement an optional argument for tupletSpannerDuration because I 
found it awkward to save and reset the old value (if any) after the tuplet 
group is over.

I find \tuplet4 easier to understand than \quadruplet

tuplet.ly
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Patchy report

[grenouille]

21:58:02 (UTC) Begin LilyPond compile, previous commit at   
c3656fce28382903c7d2c18500f74e624e4a
21:58:12 From git.savannah.gnu.org:/srv/git/lilypond
 * [new tag] release/2.17.4-1 -> release/2.17.4-1
21:58:12 Another instance (PID 29551) is already running.
22:29:01 Merged staging, now at:c3656fce28382903c7d2c18500f74e624e4a
22:29:04Success:sudo -u lilybuild ./autogen.sh 
--noconfigure
22:29:43Success:sudo -u lilybuild 
/home/lilybuild/staging/configure --disable-optimising
22:29:53Success:sudo -u lilybuild nice make clean
22:45:17Success:sudo -u lilybuild nice make -j2 
CPU_COUNT=2 ANTI_ALIAS_FACTOR=1
23:07:22Success:sudo -u lilybuild nice make test -j2 
CPU_COUNT=2 ANTI_ALIAS_FACTOR=1
01:42:12 *** FAILED BUILD ***
sudo -u lilybuild nice make doc -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1
Previous good commit:   6addf21b5bc485d30e63bf2f04d371c10b902cdb
Current broken commit:  c3656fce28382903c7d2c18500f74e624e4a
01:42:12 *** FAILED STEP ***
merge from staging
Failed runner: sudo -u lilybuild nice make doc -j2 CPU_COUNT=2 
ANTI_ALIAS_FACTOR=1
See the log file 
log-staging-nice-make-doc--j2-CPU_COUNT=2-ANTI_ALIAS_FACTOR=1.txt
01:42:12 Traceback (most recent call last):
  File 
"/home/jmandereau/lilypond-extra/patches/compile_lilypond_test/__init__.py", 
line 523, in handle_staging
self.build (issue_id=issue_id)
  File 
"/home/jmandereau/lilypond-extra/patches/compile_lilypond_test/__init__.py", 
line 328, in build
issue_id)
  File 
"/home/jmandereau/lilypond-extra/patches/compile_lilypond_test/__init__.py", 
line 266, in runner
raise FailedCommand ("Failed runner: %s\nSee the log file %s" % (command, 
this_logfilename))
FailedCommand: Failed runner: sudo -u lilybuild nice make doc -j2 CPU_COUNT=2 
ANTI_ALIAS_FACTOR=1
See the log file 
log-staging-nice-make-doc--j2-CPU_COUNT=2-ANTI_ALIAS_FACTOR=1.txt
--
grenouille at the Maison des Sciences de l'Homme Paris Nord

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

Re: Doc: improve documentation of Bézier curves (2858) (issue 6561064)

[david . nalesnik]

Trevor--

This looks great to me.  I like the reordering, and I think the
explanations are very clear.

I've tweaked the curves a little in the examples (do what you like with
my suggestions!), but otherwise:

LGTM.


https://codereview.appspot.com/6561064/diff/6001/Documentation/notation/changing-defaults.itely
File Documentation/notation/changing-defaults.itely (right):

https://codereview.appspot.com/6561064/diff/6001/Documentation/notation/changing-defaults.itely#newcode4014
Documentation/notation/changing-defaults.itely:4014: @end lilypond
The PhrasingSlur looks a little distorted to me here.  What about
changing the example to something like this:

\relative c'' {
  c8(\( a) a'4 e c\)
  \shape #'((0.8 . -0.5) (0.5 . -0.4) (0.3 . -0.3) (0 . -0.2)) Slur
  \shape #'((0 . 0) (0 . 0.5) (0 . 0.5) (0 . 0)) PhrasingSlur
  c8(\( a) a'4 e c\)
}

https://codereview.appspot.com/6561064/diff/6001/Documentation/notation/changing-defaults.itely#newcode4052
Documentation/notation/changing-defaults.itely:4052: @end lilypond
I think the shaped PhrasingSlur should hug the contour of the line a
little more closely here.  I think this still shows collision avoidance
working with the accent marks:

\relative c'' {
  c8( e b-> f d' a e-> g)
  \shape #'((0 . -1) (5.5 . -0.5) (-5.5 . -10.5) (0 . -5.5))
PhrasingSlur
  c8\( e b-> f d' a e-> g\)
}

https://codereview.appspot.com/6561064/diff/6001/Documentation/notation/changing-defaults.itely#newcode4091
Documentation/notation/changing-defaults.itely:4091: @end lilypond
I think that the slurs shouldn't touch the notes in the alternatives.
Maybe the values here are too fine (whole numbers and 0.5 look nice as
input), but see what you think:

\relative c'' {
  c1
  \repeat volta 3 { c4 d( e f }
  \alternative {
{ g2) d }
{
g2
% create a slur and move it to a new position
-\tweak #'control-points #'((-2 . 3.7) (-1 . 4) (0 . 4) (1 . 3.4)) (
<> )
f,
}
{
e'2
% create a slur and move it to a new position
-\tweak #'control-points #'((-2 . 2.8) (-1 . 3.2) (0 . 3.2) (1 .
2.4)) ( <> )
f,
}
  }
}

https://codereview.appspot.com/6561064/

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

Re: [talk] why it'd be great to have web interface for submitting simple doc patches

[Graham Percival]

On Sat, Oct 06, 2012 at 12:03:40PM +0200, Janek Warchoł wrote:
> On Sat, Oct 6, 2012 at 11:34 AM, James  wrote:
> > How is a web interface easier than email to enter information?
> 
> I should've been more specific.  I meant a web interface that would
> not only allow entering information, but also handle the patch - a
> formal patch, not just a suggestion.

That would involve a lot of backend work.  I repeat what I said 5
or so years ago: LSR is our experiment with "easy contributing"
and "crowd-sourcing".  It has not been a great success; a huge
amount of the work in LSR is done by people with git push ability,
for which it would be easier just to edit the docs directly.

Before undertaking any "make it easier to write the manuals", I
suggest that you work on LSR.  That will give you a great deal of
experience in setting up backend systems and dealing with user
interest (or its lack).  Once that's done, you will be in a much
better position to discuss expanding such efforts.

> > And being vague in an email vs vague on a website is different how?
> 
> If you're writing an email with a /suggestion/, you can write "i think
> that there should be information about x, y z, blah blah because of
> something, but i'm not sure what the wording should be".  That's
> vague.

Sure.  Then the bug squad replies back to say "thanks for thinking
about this, but we're not going to keep track of your idea until
there's a firm proposal.  Please see these webpages:
http://lilypond.org/help-us.html
http://lilypond.org/doc/v2.17/Documentation/contributor/documentation-suggestions.html
"

If somebody can't follow instruction 2: "please write exact
changes to the text", then I don't see it as a huge loss for
lilypond.

- Graham

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

Re: "unofficial GOP proposal" organization of GLISS discussions

[Graham Percival]

On Sat, Oct 06, 2012 at 02:43:48PM +0200, David Kastrup wrote:
> Marc Hohl  writes:
> 
> > Am 05.10.2012 18:34, schrieb Janek Warchoł:
> >
> >> i find it hard to keep up with our GLISS discussions.  I've also
> >> heard that the amount of technical details, digressions and
> >> "multithreadedness" stops some people from participating, as they
> >> don't have enough time to read long conversations carefully.
> 
> I would want to venture the opinion that there is no substitute for
> reading a conversation before putting forward an opinion.

That's why I organized GOP the way I did.  Important proposals are
specially marked; the matter is summarized and relevant history is
given.  I do not assume that the reader has read anything other
than the proposal (they occasionally may include links to
particularly relevant emails).  This is vital for a team of people
as "sparse" (in terms of available time) as lilypond.

A general development mailing list will not have everybody reading
everything.

> >> On the other hand, if we discuss our *problems*, syntax experts can
> >> just answer "it would be reasonable to solve it this or that way" -
> >> and voila! less frustration.
> 
> I don't see the point in discussing discussing all too much.  It spends
> time and does not really lead anywhere.

I agree that unstructured discussions are a disaster for
productive work.  I think the development list should only contain
structured discussions on concrete proposals; it's too easy for
people fall into a trap of thinking that talking about lilypond is
the same thing as working on lilypond.

Unfortunately some people wanted to keep [talk] messages on -devel
instead of sending them elsewhere, so we're in this predictable
state.

- Graham

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

Re: Doc: improve documentation of Bézier curves (2858) (issue 6561064)

[tdanielsmusic]

On 2012/10/07 03:14:31, david.nalesnik wrote:


This looks great to me.  I like the reordering, and
I think the explanations are very clear.



I've tweaked the curves a little in the examples (do
what you like with my suggestions!),


Thanks.  I've adopted them, but with just a little further
tweaking.  Showing the use of fine tuning is good, I think.


but otherwise:
LGTM.


:)


http://codereview.appspot.com/6561064/

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