Re: "unofficial GOP proposal" organization of GLISS discussions

[David Kastrup]

Graham Percival  writes:

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

Do you think more people read the GOP proposals off-list?  I have the
suspicion that the cure is doing more for addressing the perception of
the problem than the problem itself, a lack of people both qualified and
interested in discussing long-term planning.  It might just put the
discussion somewhere where nobody will stumble over it accidentally.

No, I have nothing better to propose.

>> >> 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 should really try to refrain from mincing words in a manner where
nobody but myself gets what I mean with them.  "I don't see the point in
discussing discussing" was not a typo, and it is different from "I don't
see the point in discussing".  Like with code changes, I don't see that
we can really prestructure discussions extensively since we have no
abundance of resources to streamline into channels.  It's like trying to
figure out the best way to build a drainage system in the desert.

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

But will prohibiting to talk about LilyPond increase the motivation to
work on LilyPond?

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

I don't see overwhelming consensus about your analysis of what is
supposed to be the problem, its degree, and its proposed cure.

-- 
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

[Phil Holmes]

- Original Message - 
From: "Joseph Rushton Wakeling" 

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




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.?



It's more that there are a variety of outputs generated from the doc 
source - pdf, split html, large html, info, etc. - to be sure that the 
source is OK you need to be certain all have been generated and therefore 
checked, and the simplest way of ensuring that is from a clean build.


--
Phil Holmes 



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

Re: "unofficial GOP proposal" organization of GLISS discussions

[Janek Warchoł]

Hi,

some clarification:
Most importantly, i'm not saying that we should *force* separating
discussions about problems from discussions about solutions.  What i
mean is to have a different approach than we had till now.

An example of what i consider an ineffective way of discussing:
personA: let's have syntax X
personB: this seems like a bad idea for me, because of Y
personA: in my opinion Y is not that important, and we could do Z to
avoid it.  Anyway, i don't want to use current syntax V because it's
inconvenient!
personB: but Z won't work (...)
[30 emails discussing technical reasons why syntax X might or might
not be feasible to implement]
[no conclusion on what we should do]

Here's how i suggest to discuss things:
personA: i have trouble with syntax V (or notation N) because of this
and that.  I would imagine that syntax X might be a convenient and
intuitive solution from a user's POV.
personB: i think there might be problems with unambiguous
implementation of syntax X.  Let's wait until we have more
context/information; for now we'll add an issue to the tracker about
problems with syntax V (notation N).
[persons C, D, ... speak about their problems with syntax and have
them added to the tracker]
[2 months later]
personJ: hey, i've looked at the tracker issues about problems of
persons A, D and F and i realized that problematic syntax V is just a
subset of problematic syntax W.  Solution X proposed by personA won't
be enough to solve W.  How would you solve W?
[brainstorm]
[parser expert H announces an official proposal U that would solve W
(and thus V as well, without introducing problems present in X).
Since that's an official proposal, everyone looks at it.  In the end,
people either accept U or something better]
[everyone is happy :D]

On Sat, Oct 6, 2012 at 2:43 PM, David Kastrup  wrote:
> I would want to venture the opinion that there is no substitute for
> reading a conversation before putting forward an opinion.

agreed.  I'm not suggesting that we shouldn't read long conversations.
 I'm suggesting that we should try making long conversations shorter,
for example by dividing them according to the subject (i.e. discussing
what is wrong is one subject, discussing how to solve it is another
subject).

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

Absolutely!  I haven't meant that we should dump "fuzzy feelings" into
the tracker.  Tracker issues should be concrete descriptions of what
is wrong and why.
Because of that we shouldn't add issues directly to the tracker, but
first post them to the list (bug-lilypond??) and make sure to explain
what is wrong, why, give examples etc.

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

Sure, you have a point.  But i'm *not suggesting* that we do it this
way: "hey, people, on November 5 we'll be discussing X and you better
have some code to discuss!".
I'm suggesting something more like this:
discussionLeader: let's discuss no more than one solution each week.
What shall we discuss this week?
developer J: i have an idea on how to solve Q.
developer D: i was recently thinking about solving K and i have a working draft.
Leader: let's talk about K this week, since there is a working draft
available.  We'll get back to Q next week.

>>> 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".

I understand.  "omg wtf?! this won't work" was just a thought abbreviation.

cheers,
Janek

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

Re: LilyPond 2.17.4 released

[David Kastrup]

"Phil Holmes"  writes:

> We are happy to announce the release of LilyPond 2.17.4. This
> release contains the usual number of bugfixes. It is strongly
> recommended that normal users do not use this release, and instead
> use the stable 2.16 version.

I got a bikeshed to pluck here, namely "normal users".  Can we find a
different wording for that?  I have no good idea right now, but I find
that my dislike for this wording does not improve.

-- 
David Kastrup

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

Re: LilyPond 2.17.4 released

[Janek Warchoł]

On Sun, Oct 7, 2012 at 12:13 PM, David Kastrup  wrote:
> "Phil Holmes"  writes:
>
>> We are happy to announce the release of LilyPond 2.17.4. This
>> release contains the usual number of bugfixes. It is strongly
>> recommended that normal users do not use this release, and instead
>> use the stable 2.16 version.
>
> I got a bikeshed to pluck here, namely "normal users".  Can we find a
> different wording for that?

"inexperienced users"?
(i guess most experienced ones use dev releases anyway)
or maybe non-developers?
"it is strongly recommended that only developers use this release.
Everyone else should use stable 2.16 version".

Janek

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

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

[Ian Hulin]

Hi Keith,
Thanks for doing some prototyping.
On 07/10/12 00:24, Keith OHara wrote:
> 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).
> 
+1.
Although this sort of default is something we now can do now with music
functions, we shouldn't here.
My intention in proposing this is to add the short-cut \triplet etc. as
a convenience and keep \tuplet for the more complex rhythmic ratios,
although it is perfectly possible to use \tuplet for triplets etc.  (We
go for \tuplet rather than \times because it is more readably distinct
from \time.)


> 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.
> 
Thanks for investigating this. In that case let's leave
tupletSpannerDuration as being the default - length of the \tuplet
expression.  If someone feels the need to do this at a later date that's
fine.

> I find \tuplet4 easier to understand than \quadruplet
> 
Duplets and quadruplet can be confusing.  The Oxford Dictionary of Music
definitions (Table 11, page xx) are:
"Duplet or Couplet: Two in the time of three"
"Quadruplet : Four in the time of three"

-1
Allowing the argument to be an integer which is assumed to be a
particular fraction, 3 for 3/2 4 for 4/3 etc.

Again, many thanks for working on this proposal,

Cheers,
Ian


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

Re: LilyPond 2.17.4 released

[Valentin Villenave]

On Sun, Oct 7, 2012 at 10:19 AM, Janek Warchoł  wrote:
> "it is strongly recommended that only developers use this release.
> Everyone else should use stable 2.16 version".

The wording I've used for the upcoming LilyPond Report is: "this
version is intended for testing purposes and not production use." (I
must have stolen that from Graham though.)

Cheers,
Valentin.

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

Re: LilyPond 2.17.4 released

[David Kastrup]

Janek Warchoł  writes:

> On Sun, Oct 7, 2012 at 12:13 PM, David Kastrup  wrote:
>> "Phil Holmes"  writes:
>>
>>> We are happy to announce the release of LilyPond 2.17.4. This
>>> release contains the usual number of bugfixes. It is strongly
>>> recommended that normal users do not use this release, and instead
>>> use the stable 2.16 version.
>>
>> I got a bikeshed to pluck here, namely "normal users".  Can we find a
>> different wording for that?
>
> "inexperienced users"?
> (i guess most experienced ones use dev releases anyway)

Negative connotation.  But reversed (see below) it is not actually that
bad.

> or maybe non-developers?
> "it is strongly recommended that only developers use this release.
> Everyone else should use stable 2.16 version".

"it is strongly recommended that only experienced users try working with
this release.  Everyone else is encouraged to use the stable 2.16
version instead."

Something like that.

-- 
David Kastrup


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

Re: LilyPond 2.17.4 released

[Phil Holmes]

- Original Message - 
From: "David Kastrup" 

To: 
Sent: Sunday, October 07, 2012 12:02 PM
Subject: Re: LilyPond 2.17.4 released



Janek Warchoł  writes:


On Sun, Oct 7, 2012 at 12:13 PM, David Kastrup  wrote:

"Phil Holmes"  writes:


We are happy to announce the release of LilyPond 2.17.4. This
release contains the usual number of bugfixes. It is strongly
recommended that normal users do not use this release, and instead
use the stable 2.16 version.


I got a bikeshed to pluck here, namely "normal users".  Can we find a
different wording for that?


"inexperienced users"?
(i guess most experienced ones use dev releases anyway)


Negative connotation.  But reversed (see below) it is not actually that
bad.


or maybe non-developers?
"it is strongly recommended that only developers use this release.
Everyone else should use stable 2.16 version".


"it is strongly recommended that only experienced users try working with
this release.  Everyone else is encouraged to use the stable 2.16
version instead."

Something like that.

--
David Kastrup



"This version has not had extensive testing, and so only users who are 
willing to risk crashes or unexpected behaviour should download and install 
it.  Those who require a stable version should continue to use the 2.16 
version."


?

--
Phil Holmes 



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

Re: LilyPond 2.17.4 released

[David Kastrup]

"Phil Holmes"  writes:

>> "it is strongly recommended that only experienced users try working with
>> this release.  Everyone else is encouraged to use the stable 2.16
>> version instead."
>>
>> Something like that.
>
>
> "This version has not had extensive testing, and so only users who are
> willing to risk crashes or unexpected behaviour should download and
> install it.  Those who require a stable version should continue to use
> the 2.16 version."
>
> ?

Well, our stable versions don't necessarily have been heavily tested,
either.  I'd rephrase the first two sentences as

This version contains work in progress.  Only users who are prepared to
deal with crashes or unexpected ...

-- 
David Kastrup

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

Re: LilyPond 2.17.4 released

[Stefaan Himpe]

Hi there,


I got a bikeshed to pluck here, namely "normal users".  Can we find a
different wording for that?  I have no good idea right now, but I find
that my dislike for this wording does not improve.


Just use the word "users". Devs know they have other options.

Best regards,
Stefaan.


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

Re: LilyPond 2.17.4 released

[David Kastrup]

Stefaan Himpe  writes:

> Hi there,
>
>> I got a bikeshed to pluck here, namely "normal users".  Can we find a
>> different wording for that?  I have no good idea right now, but I find
>> that my dislike for this wording does not improve.
>
> Just use the word "users". Devs know they have other options.

"Users should not be using this release"?  No, I don't want to employ a
simple descriptive term like "user" as a caste label.  That seems even
worse than "normal users".

-- 
David Kastrup


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

Re: LilyPond 2.17.4 released

[Phil Holmes]

- Original Message - 
From: "David Kastrup" 

To: "Phil Holmes" 
Cc: 
Sent: Sunday, October 07, 2012 12:22 PM
Subject: Re: LilyPond 2.17.4 released



"Phil Holmes"  writes:


"it is strongly recommended that only experienced users try working with
this release.  Everyone else is encouraged to use the stable 2.16
version instead."

Something like that.



"This version has not had extensive testing, and so only users who are
willing to risk crashes or unexpected behaviour should download and
install it.  Those who require a stable version should continue to use
the 2.16 version."

?


Well, our stable versions don't necessarily have been heavily tested,
either.  I'd rephrase the first two sentences as


I'd argue that they have.  We have a number of release candidates that we 
specifically request people to download and test.  We then have a period of 
grace before we release stable.  It's probably better tested than much 
commercial software.  We just can't _prove_ it.



This version contains work in progress.  Only users who are prepared to
deal with crashes or unexpected ...

--
David Kastrup



--
Phil Holmes 



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

Re: LilyPond 2.17.4 released

[Janek Warchoł]

On Sun, Oct 7, 2012 at 1:21 PM, Stefaan Himpe  wrote:
>
>> I got a bikeshed to pluck here, namely "normal users".  Can we find a
>> different wording for that?  I have no good idea right now, but I find
>> that my dislike for this wording does not improve.
>
> Just use the word "users". Devs know they have other options.

Seems good.
David's first proposal and Valentin's one are fine with me too.
Janek

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

Re: LilyPond 2.17.4 released

[Stefaan Himpe]

"Users should not be using this release"?  No, I don't want to employ a
simple descriptive term like "user" as a caste label.  That seems even
worse than "normal users".


In this context I agree it doesn't sound good. I'd reformulate the 
sentence to mention that this specific release is suitable only for 
experienced users.


Best regards,
Stefaan.




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

[proposal] easy triplets and tuplets - Draft 3

[Ian Hulin]

Thanks to everyone for their feedback so far.
Here is Version 3 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 3/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.

3. Another suggestion was that \tuplet command could be flexible
enough to cater for the the commoner forms of tuplets by using
defaults to arguments which the user could omit, e.g.:
\tuplet {} % implies \tuplet 3/2 {} % \times 2/3 {} in current syntax.
\tuplet with an integer rather than a fraction implies other common
tuplets
\tuplet 2 implies \duplet
\tuplet 3 implies \triplet
\tuplet 4 implies \quadruplet
\tuplet 6 implies \sextuplet etc.

Decision:
After looking at some prototype code the \tuplet command will act as
simple replacement for \times.  Although the idea behind the
defaulting/implied values for the fraction parameter are quite elegant
as an idea, the disadvantage is that they actually make source code
potentially less readable, particularly when we using the command with
an integer "fraction" parameter, as we are using number in this case
as a keyword.  If users want not to code the complete fraction
parameter as, they can use \triplet and friends.

Cheers,

Ian



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

[Parser] Lookahead in music function arguments

[David Kastrup]

Hi,

I am trying to get into somewhat consistent music function behavior.
Some argument types for music functions inherently require lookahead:
simple music expressions like c4 (since you can still add -\accent at
will), symbol chains (like Bottom as it may be followed by
. Accidental), durations like 4. since further dots may follow.

If something like

\language "italiano"
sol

is supposed to work, strings may not require lookahead, or sol will not
be recognized in Italian mode.

In general, not requiring lookahead makes things more versatile.

Now there are things like 3\cm which I currently allow as function
arguments.  But that means that an unadorned 3 is not complete without
checking the lookahead for a number identifier.  I don't think there is
any function yet that actually uses numerical arguments like that, and
one can always get by with writing #(* 3 cm) or ##{ 3\cm #}.

Even if we have functions taking numeric arguments, it would likely be
surprising that something like

add = #(define-scheme-function (parser location a b) (number? number?)
 (+ a b))
y = 7
z = \add 4 \y

will complain since 4\y evaluates to 28 and no second numeric argument
follows.  Huh.

I lean towards letting numbers in function arguments just evaluate to
themselves, never mind units.  In particular integers are used quite
often in manners where a "unit" behavior of identifiers would be rather
more than less surprising.

-- 
David Kastrup


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

Re: User-poll about lily-syntax: results - [Was: [GLISS] basics]

[Marc Hohl]

Am 06.10.2012 22:27, schrieb Thomas Morley:

Hi,

attached are the alphabetic sorted complains/suggestions about
LilyPond-syntax from german users.

Hi Harm,

thanks for your work – looks like you spent quite a lot of time 
collecting *and*

presenting these issues!

It looks like some issues could be tackled/solved quite easily,
IMHO (I may be proven wrong):

(1) Support for \clef "bass^(8)" would be great!

(2) \once \override NoteHead #'custom-head = \markup { \musicglyph 
#"scripts.coda" }
still looks complicated. I'd prefer something similar to \xNotesOn ... 
\xNotesOff for

a couple of NoteHeads, and \xNote ... for *one* NoteHead only.
Perhaps something like
\markupNotesOn \musicglyph #"scripts.coda" c d e f \markupNotesOff?

(3) \new Staff \with{
fontSize = #-3
\override StaffSymbol #'staff-space = #(magstep -3)
\override StaffSymbol #'thickness = #(magstep -3)
}
is really not very nice.

\new Staff \with { \StaffScale #-3 } would be better.

(4) The pure-unpure stuff is not very easy to understand, and the 
explanation
is indeed buried in the depths of CG. The idea of renaming was discussed 
before,

but I am not sure whether a general solution has been found.

Other issues like properties/beaming/tie/slur seem to involve more
work on engraver level, so I cannot judge the possible complications here.

Regards,

Marc







All comments are my own thoughts.
I didn't judge about any of the complains/suggestions, simply collected them.
Sometimes I added an own suggestion.

-Harm

@ Francisco: I noticed you posted Janek's questions, too.
:)


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



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

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

[Marc Hohl]

Am 05.10.2012 21:42, schrieb Thomas Morley:

2012/10/5  :

Marc wrote:

(define-bar-line ...) or \defineBarLine allows for new
definitions. These functions have four arguments,
namely the bar line itself, the bar line used at the end
of line, the bar line used at the begin of a new line
and the span bar line.


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)?

Janek

Marc and me, we discussed this some time ago and decided not to
provide that functionality.

IIRC, I was the one which *proposed* the idea of having different
span bars but decided to continue with one span bar per bar line
only, because I treid to adopt the old c++ way in which the span bars
werde defined and handled.

So this was more or less *my* fault.

Thinking a bit more in detail, I think the input format
\define BarLine #'(bar end-of-line begin-of-line) #'(span-bar 
end-of-line begin-of-line)

or alternatively
\define BarLine #'(bar end-of-line begin-of-line) #'(span-bar)
which expands internally to
\define BarLine #'(bar end-of-line begin-of-line) #'(span-bar span-bar 
span-bar)

is indeed the cleanest solution.

With my current approach, Lilypond raises a warning if the corresponding
span bar to [begin|end]-of-line-bar is not defined.
So your proposal is definitively better.


It would make things more complicated for the user and I think it is a
rarely needed feature.



This was my first opinion, too, but on the other hand, a cryptic warning and
the need to define one or two additional bar lines to get rid of it is not
user-friedly either.

Regards,

Marc


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

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

[Jonathan Wilkes]

> Date: Sat, 06 Oct 2012 20:33:18 +0200
> From: David Kastrup 
> To: lilypond-devel@gnu.org
> Subject: Re: [proposal] easy triplets and tuplets - Draft 2
> Message-ID: <87obkfsb69@fencepost.gnu.org>
> Content-Type: text/plain
> 
> 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

I understand the reasons for \tuplet and its syntax, but I don't really get
the point of \triplet and friends.

I thought this thread started with the complaint about having to a) explicitly
write whatever syntax means "this next stuff between the brackets is a
triplet", b) writing the bracket, c) writing the "stuff", d) writing the 
closing bracket,
and finally e) having to reload the syntax shotgun for the next triplet.  This 
gets
extremely tedious for long strings of triplets, and reloading the
shotgun with 11 characters (\triplet {}) instead of 14 (\tuplet 3/2 {}) doesn't 
really
address that problem.
I want to tell Lilypond it's time for a bunch of triplets, write the triplet 
pitch names,
then tell Lilypond I'm done.  I'm not typically counting how many durations of
a kind there are coming up in the stuff I'm about to enter into a score (and I 
_shouldn't_
have to use my error-prone brain to calculate the sum total durations for the
make-moment thingy when the durations that add up to the total are going to be
cordoned off for Lilypond to inspect when I compile).  In the cases where
"\tuplet x/y {}" would be tedious to keep writing I want syntax that will allow 
me to
put bookends around my entire block of triplets and have Lilypond do the work 
for me--
typing 3 fewer characters _each_ tuplet group doesn't help much, especially when
everyone's just going tocopy/paste that syntax anyway.

-Jonathan

___
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

[Julien Rioux]

On 07/10/2012 5:33 AM, Phil Holmes wrote:

- Original Message - From: "Joseph Rushton Wakeling"

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



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.?



It's more that there are a variety of outputs generated from the doc
source - pdf, split html, large html, info, etc. - to be sure that the
source is OK you need to be certain all have been generated and
therefore checked, and the simplest way of ensuring that is from a clean
build.

--
Phil Holmes


It should be possible to avoid make clean. There will be a need for make 
doc-clean when moving or removing an included file. Other cases should 
be considered as bugs. If you witness that something doesn't get 
regenerated after you modified a file, please file it as a bug.


--
Julien


___
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

[David Kastrup]

Julien Rioux  writes:

> It should be possible to avoid make clean. There will be a need for
> make doc-clean when moving or removing an included file. Other cases
> should be considered as bugs.

_Every_ change in the scm or lily or ly directory can potentially affect
every part of the documentation.  Only with doc-only changes is there a
chance to get dependable results from partial documentation
regeneration.

-- 
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 3

[Joseph Rushton Wakeling]

On 10/07/2012 05:04 PM, Ian Hulin wrote:

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).


Yes, it is, and you can probably also include \septuplet as being equivalent to 
\tuplet 7 as being equivalent to \times 4/7.


That's the established modern standard septuplet, although there are others in 
the literature past and present (in modern pieces, alternate septuplets are 
usually given with the explicit ratio, e.g. 7:6, 7:8 etc.).



3. Another suggestion was that \tuplet command could be flexible
enough to cater for the the commoner forms of tuplets by using
defaults to arguments which the user could omit


Apologies for coming late with these next remarks, but it's perhaps worth 
thinking about quite how flexible a \tuplet command could be, in respect of some 
of the various modern notations out there.


Just to give a flavour, besides the standard

|-- n --|

(i.e. bracket with number), and the almost-as-standard

|- n : m -|

(i.e. ratio), you also might encounter something like,

|- 3 : 2 {2} -|
or
|- 3 {2} : 2 -|

where {2}, {4}, {8} etc. represents a written half, quarter, eighth note, etc.

or perhaps,
|- 7 {16} : {4} -|

and sometimes things like,

|- 5 {16} : 4 {16} -|

(which feels a bit redundant but is certainly unambiguous).

Of course, conceptually you could also write any arbitrary combination, like

|- 5 {16} : 2 {4} -|

... though it's not a notation you're likely to find (never say never...).

What you can also get is something where the total duration of the tuplet is 
indicated above the number or ratio, something like e.g.


   {4}
|-- 3 -- |

(3 triplet eighths = 1 quarter note in total)

or
 {8}
|-- 5 : 4 --|

(5 quintuplet 32nds = 1 eighth-note)

or
   { 8 ~ 16. }
|-- 11 : 7 --|

(11 32nd-notes in the time of 7)

This indicator of total duration is used very widely by Ferneyhough to indicate 
the total length of the outermost of his extensively nested tuplets (*), and 
it's quite a useful device in being able to see how long a given complex 
rhythmic section lasts relative to the conductor's beat.  You can see examples here:

http://soundandmusic.org/thecollection/files/scores/6634w.pdf

(* Ferneyhough's more recent scores, engraved with Finale, seem to omit this 
notation, which is a shame, and probably entirely down to Finale not being able 
to provide it automatically.)


So, for a _really_ effective \tuplet command, it would be great if the syntax 
could allow for specifying these different options -- single number, ratio, 
ratio with note values before, after or both sides, total duration above -- in a 
concise and simple way, _without_ needing to engage in copious \overrides and 
manually writing the contents of the tuplet bracket.


I realize that's a somewhat broader scope of notation than is really the focus 
of this proposal, but my feeling is it should be possible to implement as a 
natural extension of the \tuplet functionality already proposed so far.  I just 
thought I'd bring it up so the design of \tuplet doesn't cut off these 
possibilities before they've even been considered.


I do have some tentative syntax ideas here here, but before putting them forward 
I'd rather hear what others have to think.


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

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

[Reinhold Kainhofer]

On 2012-10-07 23:14, Joseph Rushton Wakeling wrote:

Apologies for coming late with these next remarks, but it's perhaps
worth thinking about quite how flexible a \tuplet command could be, in
respect of some of the various modern notations out there.

Just to give a flavour, besides the standard

 |-- n --|

(i.e. bracket with number), and the almost-as-standard

 |- n : m -|

(i.e. ratio), you also might encounter something like,

 |- 3 : 2 {2} -|
or
 |- 3 {2} : 2 -|

where {2}, {4}, {8} etc. represents a written half, quarter, eighth
note, etc.


http://lsr.dsi.unimi.it/LSR/Item?id=482
http://lsr.dsi.unimi.it/LSR/Item?id=817

I implemented those functions for MusicXML import. Note, however, that 
lilypond does not automatically use those, you have to manually set them 
as shown in the snippets.


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: [proposal] easy triplets and tuplets - Draft 3

[Joseph Rushton Wakeling]

On 10/07/2012 11:29 PM, Reinhold Kainhofer wrote:

http://lsr.dsi.unimi.it/LSR/Item?id=482
http://lsr.dsi.unimi.it/LSR/Item?id=817

I implemented those functions for MusicXML import. Note, however, that lilypond
does not automatically use those, you have to manually set them as shown in the
snippets.


Do I understand right that these functions are entirely manual overrides -- that 
they specify what to print (either a note-value, or the entire ratio) without 
reference to the actual tuplet underneath?


This is what I'm getting at, you see -- I'd like to see a \tuplet command that 
takes the information I've given about the tuplet ratio and units and translates 
that _automatically_ into the correct notation.


I'm not trying to dismiss your work, it's just that I'm leery of purely manual 
notational overrides because there's always a risk of screwing things up if you 
later revise the piece and forget to also revise the override (there's a similar 
problem IIRC with the current solution to customized subsidiary beam-breaking).



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

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

[Reinhold Kainhofer]

On 2012-10-07 23:38, Joseph Rushton Wakeling wrote:

On 10/07/2012 11:29 PM, Reinhold Kainhofer wrote:

http://lsr.dsi.unimi.it/LSR/Item?id=482
http://lsr.dsi.unimi.it/LSR/Item?id=817

I implemented those functions for MusicXML import. Note, however, that
lilypond
does not automatically use those, you have to manually set them as
shown in the
snippets.


Do I understand right that these functions are entirely manual overrides
-- that they specify what to print (either a note-value, or the entire
ratio) without reference to the actual tuplet underneath?


No, the formatter functions that I wrote use the tuplet fraction. The 
override does not contain the values of the tuplet fraction, just the 
note types. E.g.


  \once \override TupletNumber #'text =
#(tuplet-number::append-note-wrapper
  tuplet-number::calc-denominator-text "4")
  \times 2/3  { c8 c8 c8 c8 c8 c8 }

This will print 3{4}, where the 3 comes from the tuplet fraction and 
only the base note duration is set in the override.


Or the more general case:

  \once \override TupletNumber #'text =
#(tuplet-number::fraction-with-notes "4." "8")
  \times 2/3  { c4. c4. c4. c4. }

This will print a tuplet number
  3{4.}:2{8}
where the 3 and the 2 comes from the \times command and only the note 
durations are specified in the override. There is, however, no check 
whether the fraction with the durations makes sense and matches the real 
tuplet (in most cases, it will not).


There are, however, also formatter functions that override also the 
tuplet fraction.



This is what I'm getting at, you see -- I'd like to see a \tuplet
command that takes the information I've given about the tuplet ratio and
units and translates that _automatically_ into the correct notation.


I don't think that fully automatic tuplet notation will work in all cases.
However, there is certainly enough to think about a more general tuplet 
command in lilypond. The formatting functions are already there, what's 
missing is the input syntax.



I'm not trying to dismiss your work, it's just that I'm leery of purely
manual notational overrides because there's always a risk of screwing
things up if you later revise the piece and forget to also revise the
override (there's a similar problem IIRC with the current solution to
customized subsidiary beam-breaking).


It's not purely manual overrides... (But still enough rope to hang 
yourself in the way you describe).


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: [Parser] Lookahead in music function arguments

[Janek Warchoł]

Hi,

On Sun, Oct 7, 2012 at 8:11 PM, David Kastrup  wrote:
> [...]
> In general, not requiring lookahead makes things more versatile.
> [...]

thanks - i think i more or less understand why we prefer not to
require lookahead.
However, i'm not sure whether you are asking us for any opinion (if
so, what is the question, and can we see "before/after" example?) or
just letting us know about lookahead - ?
Sorry for being so direct, but i'm very short on time recently :(

cheers,
Janek

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

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

[Joseph Rushton Wakeling]

On 10/07/2012 11:52 PM, Reinhold Kainhofer wrote:

There is, however, no check whether the fraction with the durations makes
sense and matches the real tuplet (in most cases, itwill not).


Yes, that's what I mean.  I'd like to see something where the fractions and 
durations are all derived from the tuplet syntax.



I don't think that fully automatic tuplet notation will work in all cases.
However, there is certainly enough to think about a more general tuplet command
in lilypond. The formatting functions are already there, what's missing is the
input syntax.


Well, just as a very provisional sort of example, I was thinking along these 
sort of lines:


\tuplet 7 {  }  gives you 7 in the time of 4, and prints just
a 7 in the tuplet bracket.

\tuplet 7/4 {  }gives you regular 7:4 ratio, and by default
prints the ratio in the tuplet bracket.

\tuplet { 8*7 }/4 {  }  gives you 7 8th-notes in the time of 4, and
would print in the tuplet bracket: 7 {8} : 4
(replacing {8} by an actual 8th note).

\tuplet 7/{ 8*4 } {  }  ditto, but you get the note-value printed the
other side of the ratio:  7 : 4 {8}

\tuplet {16*7}/{4} { ... }  gives you 7 16th-notes in the space of a
quarter-note, and would print:   7 {16} : {4}

\tuplet {16*7}/{4.} { .. }  gives you 7 16th-notes in the space of a dotted
quarter (really, a 7:6 ratio), and would print:
7 {16} : {4.}

\tuplet {16*7}/{8*3} {...}  gives you 7 16th-notes in the space of 3 8th-
notes (really, the same as the above), and would
print:  7 {16} : 3 {8}

Note that at least some of the above examples, by specifying note durations as 
well as ratios, could in principle be checkable for correctness.


Then you could have something like \tupletWithDuration to indicate printing the 
overall duration above the tuplet value, à la Ferneyhough.


It might also be useful to have something which allows you to specify the 
note-values (so enabling checking) _without_ having them appear in the tuplet 
bracket.  e.g. something like (this is probably stupid, but I hope someone can 
come up with a better idea):  \tuplet {16!*7} / 4 would print the 16th-note, 
\tuplet {16*7} {4} wouldn't; and similarly \tuplet {16!*7}/{4!}  would see the 
tuplet bracket containing 7 {16} : {4}, while \tuplet {16*7}/{4!} would see it 
contain 7 : {4}.


I don't know if any of the above syntax is feasible as-is (I think my idea 
involving ! is probably really stupid, I hope the other bits are vaguely sane), 
but I hope it's at least useful in pointing to the sort of thing that could be done.



It's not purely manual overrides... (But still enough rope to hang yourself in
the way you describe).


For what it's worth, I did appreciate that it wasn't all manual -- it was the 
rope I was worrying about, though :-)



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

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

[David Kastrup]

Joseph Rushton Wakeling  writes:

[...]

> Just to give a flavour, besides the standard
>
> |-- n --|
>
> (i.e. bracket with number), and the almost-as-standard
>
> |- n : m -|
>
> (i.e. ratio), you also might encounter something like,
>
> |- 3 : 2 {2} -|
> or
> |- 3 {2} : 2 -|
>
> where {2}, {4}, {8} etc. represents a written half, quarter, eighth note, etc.
>
> or perhaps,
> |- 7 {16} : {4} -|
>
> and sometimes things like,
>
> |- 5 {16} : 4 {16} -|
>
> (which feels a bit redundant but is certainly unambiguous).
>
> Of course, conceptually you could also write any arbitrary combination, like
>
> |- 5 {16} : 2 {4} -|
>
> ... though it's not a notation you're likely to find (never say never...).
>
> What you can also get is something where the total duration of the
> tuplet is indicated above the number or ratio, something like e.g.
>
>{4}
> |-- 3 -- |
>
> (3 triplet eighths = 1 quarter note in total)
>
> or
>  {8}
> |-- 5 : 4 --|
>
> (5 quintuplet 32nds = 1 eighth-note)
>
> or
>{ 8 ~ 16. }
> |-- 11 : 7 --|
>
> (11 32nd-notes in the time of 7)

[...]

> So, for a _really_ effective \tuplet command, it would be great if the
> syntax could allow for specifying these different options -- single
> number, ratio, ratio with note values before, after or both sides,
> total duration above -- in a concise and simple way, _without_ needing
> to engage in copious \overrides and manually writing the contents of
> the tuplet bracket.

I diasagree.  Whether or not you we provide separate commands actually
doing the overrides, the choice between all those variants does not
appear to convey musical information individually but just constitutes a
different choice of consistent notation throughout a piece.  Having to
specify your style for every tuplet again does not make sense, so this
functionality falls squarely into the domain of graphical representation
and thus grob overrides, and any commands provided for manipulating them
are best kept separate from the commands manipulating the actual timing.

-- 
David Kastrup


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

Re: [Parser] Lookahead in music function arguments

[David Kastrup]

Janek Warchoł  writes:

> Hi,
>
> On Sun, Oct 7, 2012 at 8:11 PM, David Kastrup  wrote:
>> [...]
>> In general, not requiring lookahead makes things more versatile.
>> [...]
>
> thanks - i think i more or less understand why we prefer not to
> require lookahead.
> However, i'm not sure whether you are asking us for any opinion (if
> so, what is the question, and can we see "before/after" example?) or
> just letting us know about lookahead - ?
> Sorry for being so direct, but i'm very short on time recently :(

I am considering removing existing functionality that's not likely to
have seen any use so far, but at least is nailed down in regtests
(input/regression/optional-args-backup.ly).  So I am looking for
objections.

-- 
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 3

[Joseph Rushton Wakeling]

On 10/08/2012 12:40 AM, David Kastrup wrote:

I diasagree.  Whether or not you we provide separate commands actually
doing the overrides, the choice between all those variants does not
appear to convey musical information individually but just constitutes a
different choice of consistent notation throughout a piece.


Well, that's the point -- if you look at various contemporary pieces (e.g. 
Ferneyhough), the tuplet style is _not_ consistent throughout the piece but is 
dependent on musical context.  Some tuplets are just a single number (e.g. 
"standard" triplets or quintuplets), some have ratios, some have a single number 
and an overall duration, some have ratios and overall durations, 


It sounds like a complicated mess but visually it's actually quite sane and 
legible and makes for an easier read than a single "standard" tuplet notation would.


As you say, it would be a PITA to notate such a piece having to use \overrides 
all over the place to change the style, which is why it would be very helpful if 
the \tuplet syntax could allow the choice between these stylistic variants to be 
made concisely.  Cf. my very provisional syntax ideas, which I imagine probably 
aren't workable as-is; but could something functionally equivalent and similarly 
concise be worked out?


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

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

[Reinhold Kainhofer]

On 2012-10-08 00:21, Joseph Rushton Wakeling wrote:

On 10/07/2012 11:52 PM, Reinhold Kainhofer wrote:

There is, however, no check whether the fraction with the durations makes
sense and matches the real tuplet (in most cases, itwill not).


Yes, that's what I mean.  I'd like to see something where the fractions
and durations are all derived from the tuplet syntax.


Actually, thinking of it, it would actually be quite simple to calculate 
the displayed fraction with durations from the given durations and the 
tuplet fraction (except that there is no way to distinguish 3:2 and 4:6).


(m*dur1):(n*dur2) = tuplet fraction

can be easily solved as
m/n = (tuplet fraction)*dur2/dur1

and then reduced to minimal m and n. This could then be displayed as
  m{dur1}:n{dur2}

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: [Parser] Lookahead in music function arguments

[Janek Warchoł]

On Mon, Oct 8, 2012 at 12:46 AM, David Kastrup  wrote:
> I am considering removing existing functionality that's not likely to
> have seen any use so far, but at least is nailed down in regtests
> (input/regression/optional-args-backup.ly).  So I am looking for
> objections.

ok.  I think i don't have any.

thanks,
Janek

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

PATCH: Countdown to 20121009

[Colin Campbell]

For 20:00 MDT Tuesday October 9th

Documentation
Issue 2858 
: Document 
\shape music function - R6561064 


Enhancement:
Issue 2670 
: change 
default behavior of convert-ly - R6610058 

Issue 2874 
: Patch: 
Provide an \undo function for turning overrides and sets into reverts 
and unsets - R6588067 



Cheers,
Colin

--
I've learned that you shouldn't go through life with a catcher's mitt on both 
hands.
You need to be able to throw something back.
-Maya Angelou, poet (1928- )

___
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]

LGTM.

And thanks again for doing this!

-David

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

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

Re: [Parser] Lookahead in music function arguments

[Werner LEMBERG]

> I lean towards letting numbers in function arguments just evaluate
> to themselves, never mind units.  In particular integers are used
> quite often in manners where a "unit" behavior of identifiers would
> be rather more than less surprising.

+1.  However, it should be documented, together with the work-around.


Werner

___
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)

[janek . lilypond]

LGTM


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

http://codereview.appspot.com/6561064/diff/10001/Documentation/notation/changing-defaults.itely#newcode3961
Documentation/notation/changing-defaults.itely:3961: control-point.  If
@var{item} is a string, the result is
mention that the unit is staff-spaces (or did i miss the information?)

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

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

i have to reduce LilyPond activity :(

[Janek Warchoł]

Hi Team,

i have bad news: i'll be much less active for several weeks.  I'm very
sorry to do this, but keeping up with my university work and other
arrangements requires this.
I hope to do some code reviews, and maybe merge some GSOC stuff, but
probably not much else.  In particular, i'll be quite absent from
GLISS discussions :( - i'm very sad about this, as syntax discussions
are really important to me!
I would appreciate if you decided to adopt my "discuss problems before
solutions" suggestion for GLISS (or something similar that would
spread the load of emails over time and threads), as this would enable
me (and possibly other busy people as well) to participate in the
discussions more effectively.

thanks,
Janek

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

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

[janek . lilypond]

http://codereview.appspot.com/6610058/diff/9001/scripts/convert-ly.py
File scripts/convert-ly.py (right):

http://codereview.appspot.com/6610058/diff/9001/scripts/convert-ly.py#newcode231
scripts/convert-ly.py:231: ly.progress (_ (u"Processing `%s\'... ") %
infile_name, True)
is 'u' (here and in some other places) intended?  If so, what does it
do? (a comment maybe?)

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

___
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)

[janek . lilypond]

Please mention in the commit message that \undo will give strange
results when used with \key and \clef.

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

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

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

[dak]

On 2012/10/08 04:58:06, janek wrote:

http://codereview.appspot.com/6610058/diff/9001/scripts/convert-ly.py
File scripts/convert-ly.py (right):



http://codereview.appspot.com/6610058/diff/9001/scripts/convert-ly.py#newcode231

scripts/convert-ly.py:231: ly.progress (_ (u"Processing `%s\'... ") %
infile_name, True)
is 'u' (here and in some other places) intended?  If so, what does it

do? (a

comment maybe?)


I don't think we should be documenting the Python language, others do a
better job at that.  Check out
http://docs.python.org/reference/lexical_analysis.html#strings>

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

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

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

[Janek Warchoł]

On Mon, Oct 8, 2012 at 7:05 AM,   wrote:
> I don't think we should be documenting the Python language, others do a
> better job at that.  Check out
> http://docs.python.org/reference/lexical_analysis.html#strings>

ah, ok. thanks!

___
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]

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

http://codereview.appspot.com/6561064/diff/10001/Documentation/notation/changing-defaults.itely#newcode3961
Documentation/notation/changing-defaults.itely:3961: control-point.  If
@var{item} is a string, the result is
On 2012/10/08 04:37:54, janek wrote:

mention that the unit is staff-spaces (or did i miss the information?)


You missed it - it's in the following paragraph.

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

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