Re: "unofficial GOP proposal" organization of GLISS discussions

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

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

- 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

Re: "unofficial GOP proposal" organization of GLISS discussions

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

Re: LilyPond 2.17.4 released

"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

Re: LilyPond 2.17.4 released

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

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

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 addin

Re: LilyPond 2.17.4 released

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

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

Re: LilyPond 2.17.4 released

- 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

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

Re: LilyPond 2.17.4 released

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.

Re: LilyPond 2.17.4 released

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 opt

Re: LilyPond 2.17.4 released

- 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

Re: LilyPond 2.17.4 released

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 t

Re: LilyPond 2.17.4 released

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

[proposal] easy triplets and tuplets - Draft 3

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 fo

[Parser] Lookahead in music function arguments

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

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

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 coul

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

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 sp

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

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

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

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

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

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 documentati

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

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 i

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

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

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

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 snippe

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

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,

Re: [Parser] Lookahead in music function arguments

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

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

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

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

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,

Re: [Parser] Lookahead in music function arguments

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

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

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

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

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 whe

Re: [Parser] Lookahead in music function arguments

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 h

PATCH: Countdown to 20121009

For 20:00 MDT Tuesday October 9th Documentation Issue 2858 : Document \shape music function - R6561064 Enhancement: Issue 2670 :

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

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

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

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

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

i have to reduce LilyPond activity :(

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

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

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

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

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)

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\'... ") %

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

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 mail

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

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