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
