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-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
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#newcode4087 Documentation/notation/changing-defaults.itely:4087: -\tweak #'control-points #'((-2 . 3) (-1 . 3.1) (0 . 3.2) (1 . 2.4)) ( ) g2( ) f is the same as g2( f) so any implication that the does something different might mislead. For a single-note example you might prefer \tweak... \repeatTie g1 http://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 wl at gnu.org writes: I lean towards letting numbers in function arguments just evaluate to themselves, never mind units. Sensible. +1. However, it should be documented, together with the work-around. It was only a couple months ago that David allowed 3\cm to be used as a number within music. Formerly it was allowed only in \paper {indent=3\cm} and other such blocks. Only people reading this mailing list knew about it, none has said they use it, and I cannot imagine anyone else has stumbled upon it and started to use it. So there is nothing to document and no desired behavior for which to provide a work-around. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Parser] Lookahead in music function arguments
Keith OHara k-ohara5...@oco.net writes: Werner LEMBERG wl at gnu.org writes: I lean towards letting numbers in function arguments just evaluate to themselves, never mind units. Sensible. +1. However, it should be documented, together with the work-around. It was only a couple months ago that David allowed 3\cm to be used as a number within music. Formerly it was allowed only in \paper {indent=3\cm} and other such blocks. Only people reading this mailing list knew about it, none has said they use it, and I cannot imagine anyone else has stumbled upon it and started to use it. So there is nothing to document and no desired behavior for which to provide a work-around. Well, there is a whole lot to document as the state before and after change is not really given a whole lot of attention in the manual, but then quite a bit of it is transitory as well. The use of 3\cm in music is actually not even possible right now since cm itself is only defined in paper blocks (possibly layout blocks as well) and besides, real numbers are not recognized in music mode. This was, more or less, preparing for the situation that we want to use define-scheme-function for providing functions doing calculations in layout blocks. That is, after all, quite feasible. In assignments, things like 3\cm are unambigous as \cm has nowhere else to go. And as the last function argument of a toplevel function, the situation would be similar. However, if the function is not toplevel and not in end position itself, the \cm could equally well be a different function argument. I am not fond of the idea of treating last argument specially. In particular, it implies that the last argument will more likely than others cause lookahead to occur, and that's the least desirable situation for having lookahead. -- 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
On 10/08/2012 01:03 AM, Reinhold Kainhofer wrote: 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} Do you need to reduce to minimal m and n? If you have m and n as given, then you can say, OK, what's the total 'interior' duration of this tuplet divided by m, what's the total 'exterior' duration of this tuplet divided by n? In both cases that should come out as a standard note (1, 2, 4, 8, 16, ... or their dotted equivalents). If we take the simple case, it should be identical for both divisions, and you could throw a warning or error if it's not. That probably covers most use-cases, since I don't think there's really a lot of m{dur1}:n{dur2} about in reality; m{dur1}:{dur2}, maybe. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Parser] Lookahead in music function arguments
2012/10/8 David Kastrup d...@gnu.org: Keith OHara k-ohara5...@oco.net writes: Werner LEMBERG wl at gnu.org writes: I lean towards letting numbers in function arguments just evaluate to themselves, never mind units. Sensible. +1. However, it should be documented, together with the work-around. Speaking as a user: I never used 3\cm (don't like it), but I know others did (in \paper ). So no objection from me, and there will be the workaround. Do you suspect other disadvantages/changes than already mentioned? -Harm ___ 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, On 6 October 2012 16:40, Ian Hulin i...@hulin.org.uk wrote: On 05/10/12 08:10, James wrote: Hello, On 5 October 2012 00:19, Ian Hulin i...@hulin.org.uk 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 {music expression} % does what \times does, but not so easily confused with \time % command. 2. \triplet {music expression} % shorthand for current % \times 2/3 command 3. \duplet {music expression} % shorthand for current % \times 3/2 command 4. \quadruplet {music expression} % shorthand for current % \times 6/4 command 5. \sextuplet {music expression} % shorthand for current % \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. Yes, for some reason the spell checker seems to not like Tuplet. Anyway... .. 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 have no problem with having more commands in that while 'musos' might have their terms, I have the good fortune to play with semi-professionals and also teachers who when I queried said [I paraphrase], well sure I guess you could technically call them that, but 'no one really does' and besides when do you stop calling them their numerically accurate names (dodecatuplet)? Tuplet has no numerical association (duplet, triplet, quadraplet?) and is distinct only that it isn't a duplet. I.e. duplet = tuplet (I think you get my drift). I guess what I was worried about was that \tuplet will no no longer work and I remember if it is a duplet, setuplet or septuplet and so on instead of saying \tuplet [some variable] here like I do for \times [some fraction] That was all. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond 2.17.4 released
David Kastrup writes: Negative connotation. But reversed (see below) it is not actually that bad. 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. Why not simply state the case. What are the reasons to recommend only experienced users, why boilerplately encourage 2.16? Probably: * we don't want people inadvertently upgrading * we don't want clueless bug reports: we don't want to answer them and we don't want to ignore them * we don't want users who need a new feature try this for production and in the moment of printing find out something basic broken * we don't want users to ruin their lilypond setup and asking for help how to downgrade However, what would we want? * many downloads and testing by experienced users -- why not? more user involvement, extension of the community? * clueful bug reports: could be especially nice to have a bug reported the very moment/release that it breaks, right? even if we don't [promise to] fix it right away. So, what about something like: LilyPond 2.17.x, aka the my-hickup-or-yours?-release. This is a development release. As such, it has not had [XXX testing or stabilation/wide user testing ] so we cannot give any guarantees and we cannot give any user support. Clueful and accurate bug reports are highly valued, however, this means that you must be actively tracking development and reading the bug-lilypond list. If you are not, you are invited to do so, see COMMUNITY. If you depend on a feature listed in CHANGES [listing the newly added ones would be nice], and you are not discouraged by now, you may want to give this a try. Remember: you're on your own! -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Parser] Lookahead in music function arguments
Thomas Morley thomasmorle...@googlemail.com writes: 2012/10/8 David Kastrup d...@gnu.org: Keith OHara k-ohara5...@oco.net writes: Werner LEMBERG wl at gnu.org writes: I lean towards letting numbers in function arguments just evaluate to themselves, never mind units. Sensible. +1. However, it should be documented, together with the work-around. Speaking as a user: I never used 3\cm (don't like it), but I know others did (in \paper ). So no objection from me, and there will be the workaround. Do you suspect other disadvantages/changes than already mentioned? There are a few other things that are simply unused and which I consider phasing out since they don't really fit all too well with LilyPond. Assignments can do some numeric expressions involving +, -. *. / but without parentheses. Strings can be concatenated using +. The consequences for that kind of thing are again involving lookahead. Its effects are less onerous typically than within function arguments. Forming expressions in Scheme is straightforward enough that a separate (and not really documented or used) LilyPond layer that can't really be used inside of function arguments does not appear to make all that much sense. There has been some talk about delimiting arguments. One change with interesting consequences might be making { ... } equivalent to ##{ ... }, giving { ... } only sequential music grouping meaning when more than one music expression is inside. This would give a rather painless way of grouping arguments of arbitrary type. ##{ ... } is not all that painful either, but it appears more contrived, in contrast. It would, however, be a way to use things like the above mentioned LilyPond expressions in arguments _and_ use { } for grouping expressions, like { 4\cm + \line-width }. With regard to those expressions, I am still rather split between ripping them out and documenting them. Allowing them only delimited within braces as function arguments might be an interesting compromise. It would require actually writing \sequential { ... } if you really, really need sequential music, like as the target of \pushToTag (as a workaround, \tag could take a look at its target and turn it into sequential music if it is unsuitable for \pushToTag, but that is a bit of an invasive change). So there are a few drawbacks. One advantage would be that #{ #} and { } would have a perfectly straightforward equivalence. What I am currently doing is making LilyPond strings (whatever or what_ever-huh) in function arguments equivalent to symbols if the predicate does not accept a string. That's sort of a corollary of turning xxx.yyy into a list of symbols. Of course, the regtests told me that this disagreed with my too-clever argument list declaration of \accidentalStyle which used symbols to distinguish \accidentalStyle #'Voice teaching from \accidentalStyle teaching. The obvious fix to that is changing the syntax to \accidentalStyle Voice . teaching here, or just Voice.teaching. Accidental styles are, due to the current word syntax, fine without quotes even for piano-cautionary or similar. Making strings autoconvert to symbols when required releaves the user from having to learn too many fine distinctions of the Scheme interfaces. Implementing this is comparatively straightforward. What is much harder is to decide _what_ input forms should be considered canonical then and taught to users (and tools). Two related tracks I am working on is removing special classes of XXX_IDENTIFIER in the parser, and special classes of XXX_FUNCTION. If that work is completed, you can do a lot of things using scheme functions that are not possible right now. Much is rather hand-wavy right now and without a clear list of followup consequences and dependencies. powerful, predictable, logical are the directions I try moving in, while retaining as much backward compatibility as can be fit into that model. Some strategies regarding the language design only evolve while I work. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond 2.17.4 released
On 10/07/2012 01:22 PM, David Kastrup wrote: 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 ... +1 I think this is the best way to characterize it. You might want to rephrase it slightly to make it more personal to the reader: - This version contains work in progress. You will have access to the very latest features, but some may be incomplete, and you may encounter bugs and crashes. If you require a stable version of Lilypond, we recommend using the 2.16 version. - ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond 2.17.4 released
On Mon, Oct 8, 2012 at 7:19 AM, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: - This version contains work in progress. You will have access to the very latest features, but some may be incomplete, and you may encounter bugs and crashes. If you require a stable version of Lilypond, we recommend using the 2.16 version. - +1 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond 2.17.4 released
Jan Nieuwenhuizen jann...@gnu.org writes: David Kastrup writes: Negative connotation. But reversed (see below) it is not actually that bad. 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. Why not simply state the case. What are the reasons to recommend only experienced users, why boilerplately encourage 2.16? Probably: * we don't want people inadvertently upgrading * we don't want clueless bug reports: we don't want to answer them and we don't want to ignore them * we don't want users who need a new feature try this for production and in the moment of printing find out something basic broken * we don't want users to ruin their lilypond setup and asking for help how to downgrade We don't want people to install what amounts to a snapshot of development activity in mixed quality and stick with it for years and use it for setting up a school computer pool. LilyPond 2.17.x, aka the my-hickup-or-yours?-release. This is a development release. As such, it has not had [XXX testing or stabilation/wide user testing ] so we cannot give any guarantees and we cannot give any user support. Clueful and accurate bug reports are highly valued, however, this means that you must be actively tracking development and reading the bug-lilypond list. If you are not, you are invited to do so, see COMMUNITY. I don't like the connotations of Clueful here. And it should be sufficient to carefully read the bug reporting instructions. If you depend on a feature listed in CHANGES [listing the newly added ones would be nice], and you are not discouraged by now, you may want to give this a try. Remember: you're on your own! -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond 2.17.4 released
David Nalesnik david.nales...@gmail.com writes: On Mon, Oct 8, 2012 at 7:19 AM, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: - This version contains work in progress. You will have access to the very latest features, but some may be incomplete, and you may encounter bugs and crashes. If you require a stable version of Lilypond, we recommend using the 2.16 version. - +1 I think most can get behind this wording. Now where do we record it for the sake of the next release announcement? -- David Kastrup ___ 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
James pkx1...@gmail.com writes: I have no problem with having more commands in that while 'musos' might have their terms, I have the good fortune to play with semi-professionals and also teachers who when I queried said [I paraphrase], well sure I guess you could technically call them that, but 'no one really does' and besides when do you stop calling them their numerically accurate names (dodecatuplet)? How about dodecapulet in honor of the Bard? -- David Kastrup ___ 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
On 10/08/2012 01:29 PM, James wrote: I have the good fortune to play with semi-professionals and also teachers who when I queried said [I paraphrase], well sure I guess you could technically call them that, but 'no one really does' and besides when do you stop calling them their numerically accurate names (dodecatuplet)? Your problem isn't really what to call them, but just that once you get beyond the examples already cited there is no standard meaning. 2-, 3-, 5-, 6- and 7-tuplets all have a well-defined standard interpretation as respectively 2:3, 3:2, 5:4, 6:4 and 7:4, although the last is a more recent standardization not uniformly found in earlier musical examples. 9 is tricky -- it's as likely to be 9:6 as 9:8. Ironically 11 is probably better standardized as 11:8, at least these days; and I'm not sure I'd be confident in saying that 4-tuplets are almost always 4:6 rather than 4:3. But really, once you get beyond 7 there is no definitive standard ratio, and hence no real grounds for a dedicated named command. The standardization of septuplets as 7:4 has seen some interesting notational variants -- for example, Elliott Carter has tended to write rhythms like \tuplet 7 { c'16. c'16. c'16. c'16. c'16. c'16. c'16. } where someone like Ferneyhough would write, \tuplet 7/6 { c16 c16 c16 c16 c16 c16 c16 } ___ 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
Hello, On 8 October 2012 14:19, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: On 10/08/2012 01:29 PM, James wrote: I have the good fortune to play with semi-professionals and also teachers who when I queried said [I paraphrase], well sure I guess you could technically call them that, but 'no one really does' and besides when do you stop calling them their numerically accurate names (dodecatuplet)? Your problem isn't really what to call them, but just that once you get beyond the examples already cited there is no standard meaning. Exactly. 2-, 3-, 5-, 6- and 7-tuplets all have a well-defined standard interpretation as respectively 2:3, 3:2, 5:4, 6:4 and 7:4, although the last is a more recent standardization not uniformly found in earlier musical examples. 9 is tricky -- it's as likely to be 9:6 as 9:8. Ironically 11 is probably better standardized as 11:8, at least these days; and I'm not sure I'd be confident in saying that 4-tuplets are almost always 4:6 rather than 4:3. But really, once you get beyond 7 there is no definitive standard ratio, and hence no real grounds for a dedicated named command. Well in all honesty my orchestral colleagues at least, would call *any* instance of a tuplet with X as it's definer a 'X tuplet' regardless of beat or fraction. So a slew of notes with a 5 above it is a 'five-tuplet' and while I rarely see these more esoteric/eclectic 9:8, 11:8 - the name becomes irrelevant compared to 'how do you play the damned thing' and apart from composers I probably doubt that 'most' instrumentalists will work it out but simply try to fit those notes in the rhythm without consciously thinking about if it is 9:7 or 9:8 etc. I wondered if we were getting bogged down with adding more functions, if there is a legitimate reason apart from just being linguistically correct, then I am all for it of course (likewise if I can use \tuplet 5:4 instead of having to worry about using \quintuplet or is it \quiplet :) then the rest of you can have at it. WWGS? (what would Gould say?) Unituplets anyone? James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond 2.17.4 released
Joseph Rushton Wakeling wrote Monday, October 08, 2012 1:19 PM I think this is the best way to characterize it. You might want to rephrase it slightly to make it more personal to the reader: - This version contains work in progress. You will have access to the very latest features, but some may be incomplete, and you may encounter bugs and crashes. If you require a stable version of Lilypond, we recommend using the 2.16 version. - LGTM! Trevor ___ 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)
On 2012/10/08 07:46:09, Keith wrote: Documentation/notation/changing-defaults.itely:4087: -\tweak #'control-points #'((-2 . 3) (-1 . 3.1) (0 . 3.2) (1 . 2.4)) ( ) g2( ) f is the same as g2( f) so any implication that the does something different might mislead. They are, of course, equivalent, but the slur has no connection with the second note and I found it more confusing to involve the second note. This is the way I would do it, and the way I would recommend it be done, so I'd rather leave it at it is. I could add a comment, maybe ... I'll think about that. For a single-note example you might prefer \tweak... \repeatTie g1 I don't think this is appropriate in a section on Bézier curves, but it should go into the Known issues section of NR 1.4.1, together with a ref to here. I'll add that to this patch-set in the next upload. Thanks, Trevor http://codereview.appspot.com/6561064/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond 2.17.4 released
- Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Monday, October 08, 2012 1:34 PM Subject: Re: LilyPond 2.17.4 released David Nalesnik david.nales...@gmail.com writes: On Mon, Oct 8, 2012 at 7:19 AM, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: - This version contains work in progress. You will have access to the very latest features, but some may be incomplete, and you may encounter bugs and crashes. If you require a stable version of Lilypond, we recommend using the 2.16 version. - +1 I think most can get behind this wording. Now where do we record it for the sake of the next release announcement? In my brain. Unless I have a fade, I'll use this. -- Phil Holmes ___ 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)
LGTM https://codereview.appspot.com/6561064/diff/10001/Documentation/notation/changing-defaults.itely File Documentation/notation/changing-defaults.itely (right): https://codereview.appspot.com/6561064/diff/10001/Documentation/notation/changing-defaults.itely#newcode3901 Documentation/notation/changing-defaults.itely:3901: @itemize technically this would be better as an @enumerate a, but this isn't a big deal. 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
On Mon, Oct 8, 2012 at 12:48 PM, Thomas Morley thomasmorle...@googlemail.com wrote: Speaking as a user: I never used 3\cm (don't like it), but I know others did (in \paper ). So no objection from me, and there will be the workaround. Wait, does David suggest to change things so that we won't be able to write \paper { indent = 2\cm } ? Or does the suggested change concern something else? Janek PS David, i see that you wrote a long email - i'm sorry but unfortunately i don't have time to read it :( ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: convert-ly (issue 2670) (issue 6610058)
The changelog says Don't update \version when no rule is applied. That's what the existing -d --diff-version-update command does. If this is intended to be the default behaviour now, then the command-line option should be removed. I would rather keep convert-ly as-is (in terms of this behaviour; the other changes in this patch look good) and let users chose whether they want -d or not. However, if there's strong feeling that -d should be the default, then could we replace that command-line option and give it a separate -u --always-update-version or something like that? https://codereview.appspot.com/6610058/ ___ 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)
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 06:46:59, Trevor Daniels wrote: 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. Indeed, sorry. http://codereview.appspot.com/6561064/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: convert-ly (issue 2670) (issue 6610058)
On Mon, Oct 8, 2012 at 4:08 PM, gra...@percival-music.ca wrote: The changelog says Don't update \version when no rule is applied. That's what the existing -d --diff-version-update command does. If this is intended to be the default behaviour now, then the command-line option should be removed. No, -d does not become the default; the behavior of convert-ly is unchanged when rules are being applied, and -d is still used in the same way. The change concerns itself only with the case that no rule applies, because the version of the file is already up-to-date. In this case, it used to be that the version in the file would be set to version of the last rule, which would sometimes mean that the version of the file upon output is lower than the version at input. This is what we avoid in this patch. Please consult http://code.google.com/p/lilypond/issues/detail?id=2670 and references therein. Cheers, Julien ___ 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 20:08:20, Graham Percival wrote: The changelog says Don't update \version when no rule is applied. That's what the existing -d --diff-version-update command does. No, that's what the existing -d --diff-version-update is supposed to do. The problem was that if the last applicable rule was for version 2.16.6 and you asked for an upgrade to version 2.16.9 and the file claimed to be 2.16.9 already, its version was set to 2.16.6 instead of staying at 2.16.9. That's what the issue was about in the first place. I assume that this is what has been fixed. https://codereview.appspot.com/6610058/ ___ 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ł janek.lilyp...@gmail.com writes: On Mon, Oct 8, 2012 at 12:48 PM, Thomas Morley thomasmorle...@googlemail.com wrote: Speaking as a user: I never used 3\cm (don't like it), but I know others did (in \paper ). So no objection from me, and there will be the workaround. Wait, does David suggest to change things so that we won't be able to write \paper { indent = 2\cm } ? No, he doesn't. Or does the suggested change concern something else? Yes, it does. PS David, i see that you wrote a long email - i'm sorry but unfortunately i don't have time to read it :( I hope this one was short enough. -- 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
Hi, i had some spare time when commuting, so i've written down a few thoughts on this topic. First, we shouldn't mix content and presentation. I think it's a very important rule; one of the best things in LilyPond is that she allows to separate music from its layout. I think that what Joseph suggested is mostly a matter of layout. Thus, it shouldn't require any additional user input. For example, displaying the total duration of the tuplet can be done in an automated way - i'm sure LilyPond can calculate it. So, instead of having an additional optional argument that the user would have to provide, we should just create some property of TupletNumber (e.g. display-total-duration) that would print these when set to true. We could then go as far as to create a function that would evaluate a tuplet and set this property to true if the tuplet was complicated enough. Similarly, deciding what should be displayed inside the TupletBracket is another layout decision - it seems doable to define several styles (e.g. denominator only, ratio with slash, ratio with colon, ratio with noteheads etc) and choose between them using 'style properrty of the TupletNumber. Joseph mentioned scores in which tuplet style changes all the time. I think that a proper solution to this problem is to create custom shortcuts for overriding TupletNumber style - this way you still have layout separated from score (i.e. one can easily turn these functions off; the layout decisions aren't hardcoded in the music code itself. Secondly, there is a general design principle which says that different things shouldn't be too similar. Because of that i think that we shouldn't allow \tuplet {} (without ratio argument) to mean a triplet - it would be confusing (to say the least). In my opinion, we need a powerful function that can be used to notate any conceiveable tuplet - that would be \tuplet x/y {}. In addition to this, we may define some shorthands, but it's crucial that they are distinct from \tuplet x/y. It should be obvious for everyone, including all LilyPond beginners right from the start, that \tuplet x/y is THE way to enter tuplets, and everything else is just a shorthand. Finally, another cool thing about LilyPond is that she is logical, precise and the syntax is fairly unambiguous - *unlike* musical notation itself. I remember one user writing something like LilyPond forces me to write the music in logical and structured manner - if some notation is particularly difficult to code, i often end up realizing that it was not a good notation at all. So, while i'm wholeheartedly supporting intuitive syntax, i also firmly believe that we shouldn't aim for the most intuitive syntax possible. Some intuitions may be wrong, some may lead to ambiguities. Please forgive me for saying this, but in my opinion musicians are somewhat prone to this bad intuitions; some established music notations are ambiguous for no good reason. For example, a lot of guitar music is written in treble clef *without* 8 below the clef. From my point of view, this is extremely confusing, and a foolish thing to do. You gain nothing by omitting the 8 - why hide the fact that the music is transposed? In LilyPond, if you use the treble clef without 8, you'll get literally what you wrote - there will be no silent transposition. You have to use the proper (i.e. unambiguous) clef to get what you want (or you have to use override trickery, but then you know that you're cheating). I believe that this quality of LilyPond is very noble. So, i believe that LilyPond shouldn't always follow her users' intuition, even if they are professional musicians. In this case, i think that \tuplet 2/3 is better than \tuplet 3/2 (for 3 notes in time of 2), because it corresponds to mathematical ratio, and is similar to scaling durations. Whoah, that was a long email. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Parser] Lookahead in music function arguments
On Mon, Oct 8, 2012 at 10:40 PM, David Kastrup d...@gnu.org wrote: Janek Warchoł janek.lilyp...@gmail.com writes: Wait, does David suggest to change things so that we won't be able to write \paper { indent = 2\cm } ? No, he doesn't. Or does the suggested change concern something else? Yes, it does. PS David, i see that you wrote a long email - i'm sorry but unfortunately i don't have time to read it :( I hope this one was short enough. It's perfect! Many thanks! Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] why the hell all this fuss
On Sun, Sep 9, 2012 at 1:22 PM, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: On 08/09/12 16:10, Han-Wen Nienhuys wrote: I have in the past talked with people from Henle; also, Schirmer has a style guide that you can order as a book. How far in the past are we talking about? (Just for clarity.) About 6 - 10 years ago. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [proposal] easy triplets and tuplets - Draft 3
2012/10/8 Janek Warchoł janek.lilyp...@gmail.com: [...] Joseph mentioned scores in which tuplet style changes all the time. I think that a proper solution to this problem is to create custom shortcuts for overriding TupletNumber style - this way you still have layout separated from score (i.e. one can easily turn these functions off; the layout decisions aren't hardcoded in the music code itself. +1 In my opinion, we need a powerful function that can be used to notate any conceiveable tuplet - that would be \tuplet x/y {}. In addition to this, we may define some shorthands, but it's crucial that they are distinct from \tuplet x/y. It should be obvious for everyone, including all LilyPond beginners right from the start, that \tuplet x/y is THE way to enter tuplets, and everything else is just a shorthand. +1 For example, a lot of guitar music is written in treble clef *without* 8 below the clef. From my point of view, this is extremely confusing, and a foolish thing to do. You gain nothing by omitting the 8 - why hide the fact that the music is transposed? Offtopic: Being a guitarist myself, I'm irritated every time I see this. Must be laziness of the typesetter. But once I saw a bigband-part for guitar, notated with changing clefs between bass and treble. Well, it was the real treble, no transposition. That it was the real treble was only understandable from the context. Aarrgh! [...] So, i believe that LilyPond shouldn't always follow her users' intuition, even if they are professional musicians. In this case, i think that \tuplet 2/3 is better than \tuplet 3/2 (for 3 notes in time of 2), because it corresponds to mathematical ratio, and is similar to scaling durations. +1 Whoah, that was a long email. :) cheers, Janek -Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [proposal] easy triplets and tuplets - Draft 3
Thomas Morley thomasmorle...@googlemail.com writes: [...] So, i believe that LilyPond shouldn't always follow her users' intuition, even if they are professional musicians. In this case, i think that \tuplet 2/3 is better than \tuplet 3/2 (for 3 notes in time of 2), because it corresponds to mathematical ratio, and is similar to scaling durations. +1 -1 from me for this one. We have \times for that already and I can't count the times it took me to get the fraction right. And with the name \times there is at least the mnemonic of the name itself. When I have a tuplet that is marked 3:2 on the tuplet itself using the respective tuplet style \override TupletNumber #'text = #tuplet-number::calc-fraction-text then it makes no sense at all that I have to enter it as \tuplet 2/3 { ... } for tuplets that are three to two normal notes. That's not merely unintuitive, it is (oh goodie, no [talk] tag) plain absurd. How can anybody write \tuplet 2/3 is better than \tuplet 3/2 (for 3 notes in time of 2), because it corresponds to mathematical ratio, with a straight keyboard? How does 2/3 correspond to 3 notes in time of 2? Let me stomp my feet in defiance and holler. Ah, that's better. -- 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)
On 2012/10/08 20:04:21, Graham Percival wrote: LGTM Thanks! Documentation/notation/changing-defaults.itely:3901: @itemize technically this would be better as an @enumerate a, but this isn't a big deal. Ah yes, I'd forgotten that. I'll change it in the next patch set, since I have to submit one anyway. Trevor https://codereview.appspot.com/6561064/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [proposal] easy triplets and tuplets - Draft 3
2012/10/8 David Kastrup d...@gnu.org: Thomas Morley thomasmorle...@googlemail.com writes: [...] So, i believe that LilyPond shouldn't always follow her users' intuition, even if they are professional musicians. In this case, i think that \tuplet 2/3 is better than \tuplet 3/2 (for 3 notes in time of 2), because it corresponds to mathematical ratio, and is similar to scaling durations. +1 -1 from me for this one. We have \times for that already and I can't count the times it took me to get the fraction right. And with the name \times there is at least the mnemonic of the name itself. When I have a tuplet that is marked 3:2 on the tuplet itself using the respective tuplet style \override TupletNumber #'text = #tuplet-number::calc-fraction-text then it makes no sense at all that I have to enter it as \tuplet 2/3 { ... } for tuplets that are three to two normal notes. Touché. You have a point. That's not merely unintuitive, it is (oh goodie, no [talk] tag) plain absurd. How can anybody write \tuplet 2/3 is better than \tuplet 3/2 (for 3 notes in time of 2), because it corresponds to mathematical ratio, with a straight keyboard? How does 2/3 correspond to 3 notes in time of 2? Let me stomp my feet in defiance and holler. Ah, that's better. LOL -- David Kastrup -Harm ___ 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 wrote Monday, October 08, 2012 10:45 PM Thomas Morley thomasmorle...@googlemail.com writes: [...] So, i believe that LilyPond shouldn't always follow her users' intuition, even if they are professional musicians. In this case, i think that \tuplet 2/3 is better than \tuplet 3/2 (for 3 notes in time of 2), because it corresponds to mathematical ratio, and is similar to scaling durations. +1 -1 from me for this one. We have \times for that already and I can't count the times it took me to get the fraction right. And with the name \times there is at least the mnemonic of the name itself. Absolutely! Inverting the fraction for \tuplet was the original reason for inventing it, IIRC. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] turn xxx.yyy into (xxx yyy)
Werner LEMBERG w...@gnu.org writes: \override Bottom.TextSpanner #'(bound-details left text) = rit. as \override Bottom.TextSpanner bound-details.left.text = rit. I like this. Voila. URL:http://code.google.com/p/lilypond/issues/detail?id=2883 -- 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
On Mon, Oct 08, 2012 at 11:49:39PM +0100, Trevor Daniels wrote: David Kastrup wrote Monday, October 08, 2012 10:45 PM Thomas Morley thomasmorle...@googlemail.com writes: In this case, i think that \tuplet 2/3 is better than \tuplet 3/2 (for 3 notes in time of 2), because it corresponds to mathematical ratio, and is similar to scaling durations. -1 from me for this one. We have \times for that already and I can't count the times it took me to get the fraction right. And with the name \times there is at least the mnemonic of the name itself. Absolutely! Inverting the fraction for \tuplet was the original reason for inventing it, IIRC. Woah, really? I thought the whole point was to avoid the confusion between \time and \times. I think it would be extremely confusing for \tuplet x/y to mean the same thing as \times y/x. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [proposal] easy triplets and tuplets - Draft 3
On 10/08/2012 10:44 PM, Janek Warchoł wrote: First, we shouldn't mix content and presentation. I think it's a very important rule; one of the best things in LilyPond is that she allows to separate music from its layout. Yes, fair point. But one thing to be careful of particularly as regards contemporary music is that where in earlier music it's often possible to define standardized engraving rules, a lot of more recent works frequently switch between different stylistic choices as a means of indicating nuance. If you can't do those switches quickly and easily from the syntax, you have a problem. Looking at it a slightly different way, what may be merely presentation in earlier music, can actually be content for contemporary music. I could give quite a lot of examples, but let's stick for now with the tuplets. I think that what Joseph suggested is mostly a matter of layout. Thus, it shouldn't require any additional user input. For example, displaying the total duration of the tuplet can be done in an automated way - i'm sure LilyPond can calculate it. So, instead of having an additional optional argument that the user would have to provide, we should just create some property of TupletNumber (e.g. display-total-duration) that would print these when set to true. That's broadly what I mean, although I don't think you can do it without _any_ additional user input. What we're certainly in agreement on is that it shouldn't be about manual overrides of what literally appears; I want to be able to easily choose between different stylistic options _and have the precise notation calculated automatically and correctly_. You _do_ need to provide extra information about the stylistic choices, though (more on that below, following your suggestions). We could then go as far as to create a function that would evaluate a tuplet and set this property to true if the tuplet was complicated enough. That's a nice suggestion in and of itself, and would probably simplify a lot of notational issues. You can probably specify some broad stylistic properties for tuplet notation such as number-only, ratio-when-nonstandard (e.g. you display 3, 5, 7, 11, 12 for respectively 3:2, 5:4, 7:4, 11:8 and 12:8, but ratios for other cases), always-use-ratio, and so on. Similarly, deciding what should be displayed inside the TupletBracket is another layout decision - it seems doable to define several styles (e.g. denominator only, ratio with slash, ratio with colon, ratio with noteheads etc) and choose between them using 'style properrty of the TupletNumber. Just bear in mind that \once \override is almost unbearably verbose and confusing if you're doing it very regularly. Joseph mentioned scores in which tuplet style changes all the time. I think that a proper solution to this problem is to create custom shortcuts for overriding TupletNumber style - this way you still have layout separated from score (i.e. one can easily turn these functions off; the layout decisions aren't hardcoded in the music code itself. Yes, that's probably fair, though I think with frequency even a short, easily-legible shortcut can become irritating, which is why I tried to develop a more flexible syntax for \tuplet itself. From a strictly user point of view (not necessarily a developer's!), the ideal would probably be an ability to put in place detailed stylistic rules that depend on the precise tuplet ratios, the position in a nested tuplet hierarchy (top-level, 2nd-level, 3rd ... ?), whether or not the tuplet's beginning and end both coincide with a barline, and probably other factors besides; and then combine that with custom shortcuts for the few cases that slip through the cracks. Secondly, there is a general design principle which says that different things shouldn't be too similar. Because of that i think that we shouldn't allow \tuplet {} (without ratio argument) to mean a triplet - it would be confusing (to say the least). Indeed, but you could reasonably allow \tuplet n {} ... to be used for an n-tuplet for values of n that have a definitively standardized interpretation. (Might be more trouble than it's worth though.) In my opinion, we need a powerful function that can be used to notate any conceiveable tuplet - that would be \tuplet x/y {}. In addition to this, we may define some shorthands, but it's crucial that they are distinct from \tuplet x/y. It should be obvious for everyone, including all LilyPond beginners right from the start, that \tuplet x/y is THE way to enter tuplets, and everything else is just a shorthand. One remark -- this concept of a \tuplet is basically just an inversion of \times, but you do have other opportunities here. A tuplet is in practice not just a ratio but is a ratio _of note values_. So there is a _content_ value in giving the user the opportunity to specify not just x/y but x/y of what? (Or, x of what to y of what?), whether or not you
Re: [proposal] easy triplets and tuplets - Draft 3
2012/10/9 Graham Percival gra...@percival-music.ca: On Mon, Oct 08, 2012 at 11:49:39PM +0100, Trevor Daniels wrote: David Kastrup wrote Monday, October 08, 2012 10:45 PM Thomas Morley thomasmorle...@googlemail.com writes: In this case, i think that \tuplet 2/3 is better than \tuplet 3/2 (for 3 notes in time of 2), because it corresponds to mathematical ratio, and is similar to scaling durations. -1 from me for this one. We have \times for that already and I can't count the times it took me to get the fraction right. And with the name \times there is at least the mnemonic of the name itself. Absolutely! Inverting the fraction for \tuplet was the original reason for inventing it, IIRC. Woah, really? I thought the whole point was to avoid the confusion between \time and \times. I think it would be extremely confusing for \tuplet x/y to mean the same thing as \times y/x. I always understood that way. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.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
On 10/08/2012 11:25 PM, Thomas Morley wrote: But once I saw a bigband-part for guitar, notated with changing clefs between bass and treble. Well, it was the real treble, no transposition. That it was the real treble was only understandable from the context. The real stupidity there is surely that they bothered switching clefs at all? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [proposal] easy triplets and tuplets - Draft 3
On 10/09/2012 01:12 AM, Graham Percival wrote: On Mon, Oct 08, 2012 at 11:49:39PM +0100, Trevor Daniels wrote: Absolutely! Inverting the fraction for \tuplet was the original reason for inventing it, IIRC. Woah, really? I thought the whole point was to avoid the confusion between \time and \times. I think it would be extremely confusing for \tuplet x/y to mean the same thing as \times y/x. Aren't they both good reasons? You get to avoid too-similar command names, _and_ you get a syntax that matches more closely to the musical notation. Seems like a win on both counts. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Patchy report
21:58:01 (UTC) Begin LilyPond compile, previous commit at c7a3623a056891d48b13fe14fd6ee042ac666822 21:58:27 Merged staging, now at:c7a3623a056891d48b13fe14fd6ee042ac666822 21:58:29Success:sudo -u lilybuild ./autogen.sh --noconfigure 21:59:05Success:sudo -u lilybuild /home/lilybuild/staging/configure --disable-optimising 21:59:15Success:sudo -u lilybuild nice make clean 22:16:12Success:sudo -u lilybuild nice make -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 22:38:05Success:sudo -u lilybuild nice make test -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 00:33:31 *** FAILED BUILD *** sudo -u lilybuild nice make doc -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 Previous good commit: 6addf21b5bc485d30e63bf2f04d371c10b902cdb Current broken commit: c7a3623a056891d48b13fe14fd6ee042ac666822 00:33:31 *** 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 00:33:31 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: [proposal] easy triplets and tuplets - Draft 3
Graham Percival gra...@percival-music.ca writes: On Mon, Oct 08, 2012 at 11:49:39PM +0100, Trevor Daniels wrote: David Kastrup wrote Monday, October 08, 2012 10:45 PM Thomas Morley thomasmorle...@googlemail.com writes: In this case, i think that \tuplet 2/3 is better than \tuplet 3/2 (for 3 notes in time of 2), because it corresponds to mathematical ratio, and is similar to scaling durations. -1 from me for this one. We have \times for that already and I can't count the times it took me to get the fraction right. And with the name \times there is at least the mnemonic of the name itself. Absolutely! Inverting the fraction for \tuplet was the original reason for inventing it, IIRC. Woah, really? I thought the whole point was to avoid the confusion between \time and \times. Both the whole point impressions are mistaken if you look at the original proposal in URL:http://permalink.gmane.org/gmane.comp.gnu.lilypond.devel/50803. It was one, deliberately separate point to discuss. It was discussed, and a consensus was reached. I think it would be extremely confusing for \tuplet x/y to mean the same thing as \times y/x. Only if both are intended to be used interchangeably. But use of \times would be discouraged because of _both_ whole points. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)
LGTM, without testing, and without really understanding the change. However, simplifications and generalizations are always a good thing. http://codereview.appspot.com/6635050/diff/1/Documentation/de/notation/pitches.itely File Documentation/de/notation/pitches.itely (right): http://codereview.appspot.com/6635050/diff/1/Documentation/de/notation/pitches.itely#newcode1529 Documentation/de/notation/pitches.itely:1529: \accidentalStyle StaffGroup.voice This looks strange. I don't expect double quotes after a dot. Any better representation possibility? http://codereview.appspot.com/6635050/ ___ 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)
http://codereview.appspot.com/6561064/diff/17001/Documentation/notation/changing-defaults.itely File Documentation/notation/changing-defaults.itely (right): http://codereview.appspot.com/6561064/diff/17001/Documentation/notation/changing-defaults.itely#newcode3916 Documentation/notation/changing-defaults.itely:3916: @subsubsubheading Cubic Bézier curves Are there too many 'subs' here? I only mention it because the headings are bold _italic_ which really jars on the eye when it's not used anywhere else (at least when I make a quick scroll through the resulting pdf). Ditto for the other headings. http://codereview.appspot.com/6561064/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [proposal] easy triplets and tuplets - Draft 3
On Mon, 8 Oct 2012, Trevor Daniels wrote: David Kastrup wrote Monday, October 08, 2012 10:45 PM Thomas Morley thomasmorle...@googlemail.com writes: [...] So, i believe that LilyPond shouldn't always follow her users' intuition, even if they are professional musicians. In this case, i think that \tuplet 2/3 is better than \tuplet 3/2 (for 3 notes in time of 2), because it corresponds to mathematical ratio, and is similar to scaling durations. +1 -1 from me for this one. We have \times for that already and I can't count the times it took me to get the fraction right. And with the name \times there is at least the mnemonic of the name itself. I am not in favour of allowing different commands \times 2/3 and \tuplet 3/2 to do the same job. My voice would go to: just keep \times x/y the way it is. I can't see what makes 3/2 easier than 2/3. And having the choice of two commands doing the same job with a slightly different syntax only makes things more confusing for me. -- MT ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel