Re: Constructive Criticism and a Question
On Sunday 07 January 2007 04:55, [EMAIL PROTECTED] wrote:
. . . Note also that the tupletSequence
function would be implemented entirely in Scheme . . .
I'm not very fluent in Scheme, so this is a naive question.
I presume that ratios like 3:2 (or 2/3) could be made into some kind of
object type (possibly a moment). So I could imagine that it would be
possible to write a Scheme function definition to cover a syntax like
\tupletSequence m:n #'( {...} {...} ... )
where the first argument is a moment and the second is a list of literal
music expressions. (And I suppose I'm too optimistic about that syntax;
probably those {...} would have to be sprinkled with # or $ or other
spices.) But there are some questions:
1) I don't see how this could accommodate the case where one of the music
expressions *were* a variable reference (\var) or *contained* a variable
reference.
Music functions are not macros; the arguments are evaluated before the
function is called. So \var always means to dereference a variable.
(I'm working on a system for 'music macros', which should make it possible to
delay the dereferencing of variables, this will mainly be useful to clean up
\relative)
2) Because the syntax \tupletSequence m:n { {...} {...} }
is nicer, it would be good if it could be written that way, but then the
second argument would not be a standard Scheme entity, so I don't see how
Scheme could handle it at all.
There is a distinction between Scheme functions and Music functions. Music
functions are invoked as \function arg1 arg2, while Scheme functions are
invoked in Scheme expressions, as #(function arg1 arg2). tupletSequence would
be a music function.
There are three types of arguments to music functions: Music, Markup and
Scheme. This suggestion would add another argument type 'fraction'. The
parser takes care of identifying argument types. Music arguments are notated
as music, so you can use {{c}{d}} syntax out-of-the-box. E.g., partcombine is
a music function.
In Scheme functions, you can use the #{ #} syntax to easily create music
expressions as arguments.
Can tupletSequence really be defined in pure Scheme, as long as the parser
is modified to recognize the object m:n or n/m (so that there would exist
a type-verification-name for the object m:n for use in defining Scheme
functions)?
yes, the only thing we need is a new parameter type.
BTW, one of the biggest problems (IMHO) in the lilypond language is that we
can't extend the parser to accept durations as parameters to music functions:
\foo c 4. is ambiguous; it's unclear whether the 4. is the c's duration, or
if it's a separate argument.
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Friday 05 January 2007 22:53, [EMAIL PROTECTED] wrote:
. . . The { m1 m2 m3 } syntax is used for repeat alternatives
already, and the meaning is very clear: Each music expression between the
outer { } is a separate argument. Note also that the tupletSequence
function would be implemented entirely in Scheme . . .
{ {g8 f e} \seq {b8 a g} }
\tuplet {g f e} \tuplet \seq \tuplet {b a g}
{{c d e} {{f g} a} b c}
\tuplet {c d e} \tuplet {{f g} a} \tuplet b \tuplet c
OK. Thank you for clarifying that. I understand, from your original
remarks, that (here) you have written just \tuplet in the interest of
brevity, and that the full form would be
\tupletSequence 3:2 {{c d e} {{f g} a} b c}
meaning
\tuplet 3:2 {c d e} \tuplet 3:2 {{f g} a} \tuplet 3:2 b \tuplet 3:2 c
yes, that's right.
which implies the following things:
a) tupletSequence is a Scheme function which just breaks up its
subexpressions naively, without any semantic analysis.
b) \tuplet is a real LilyPond function; it is identical to \times,
except that the notation 3:2 (meaning 2/3) would be allowed.
c) People would have to write \tupletSequence m:n { {...} {...} },
not \tuplet m:n { {...} {...} }.
yep, this is right (thanks for expressing it clearly).
d) Any semantic errors in the subexpressions would be reported by the
\tuplet function, not by the \tupletSequence Scheme function.
technically this is not correct (the \tuplet function doesn't detect semantic
errors), but in principle you're right (\tuplet and \tupletSequence actually
only create Music data structures, without performing semantic analysis;
most 'semantic errors' are detected either when these data structures are
further processed into typeset scores, or by the parser before the function
applications)
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
My point when I started this topic was not to change the whole definition of
the \times function. In fact, I think the function works quite well as it
is. I was mostly talking about improving the interface - i.e. the words
and the syntax we use to call the functions - to make it more intuitive,
especially for a non-programmer. The \times function was an example among
other. I was proposing to change it to \tuplet x:y, simply because it is
closer to the musicians' language (tuplet), and it reflects more the result
we see and we would write manually (3:2 or 7:5, even if we have 6
sixteenth-notes for the 7:5 in contemporary music).
In fact, if we forget a few little bugs, LilyPond is already VERY powerful
and versatile. The point is not much to improve its features (even if it is
important), but to improve - even maybe rethink - its code entry. Some
symbols, most of the basics in fact, work very well (the notes names (a b
c), the durations (4., 8, 16, \breve), \stemUp, \cadenzaOn, the fantastic
*x/y function, etc.). But the syntax gets hard when getting in
kind-of-Scheme syntax for every tweak, and it changes a lot!
For example, we can write :
\override Voice.Stem #'transparent = ##t
#'(set-global-staff-size 13)
\set fontSize = #14
\override Voice.NoteHead #'stencil = (ly:make-textscript) (?) (which is a
function, why not simply a font character?)
And I am sure to make mistakes!
Just to make functions with a more constant syntax would be a great help for
us, simple users. Like making functions with \ most of the time (inspired by
LaTeX) :
\transparent{Voice.Stem}
\globalStaffSize{13}
\fontSize{14}
\setStencil{Voice.NoteHead, cross} (or even better, \setNotehead{cross} )
or any other syntax, but the thing is to make it constant.
The inconstant syntax to make anything a little outside the ordinary is, in
my humble opinion, the most time wasting feature of LilyPond. The problem is
that we always need to refer to the manual to find the way to write the
tweak, then we always forget how to do it for another score, since all the
tweaks we use have a different syntax.
Also, when doing this, the point would be to keep the names of the functions
as close to the musical terms and to the musical written symbols.
But a little program editor like the LilyPondTool in jEdit makes it much
easier indeed! Maybe that is the solution to the sometimes too complex
syntax of LilyPond.
Also, thanks for the changes in micro-intervals symbols, especially the db
for -eseh!
Frédéric
Note, importantly, that, with the present tuplet syntax, lily handles
all tuplets -- *including broken ones* -- correctly out of the box.
This sort of thing brings Finale and Sibelius screaming to their
knees. (This seems to be an extension of the fact that lily gets one
thing *exceedingly* correct: the duration model of musical time. Out
of the box you can also specify time signatures like 6/15, 5/28, 3/10
and so on, all of which bring other musical notation programs -- with
the the notable exception of SCORE -- to a crashing standstill. Or at
least the last time I bothered to check.)
I've been watching the tuplet discussion with some hesitation. I think
chaning \times to \tuplet is a great idea for the reason that started
the thread: \times is too close to \time. But it seems to me that most
of the suggestions following that initial suggestion begin to confuse
the essential time-scaling function of tuplet brackets (which is their
absolutely core purpose, both in the common practice and now) and
other graphical aspects of the notation such as beaming, grouping (and
even accentuation). Beaming and grouping are terribly important, of
course, but I think that it's best to leave their specification out of
the core tuplet syntax.
More important is to fix the fact that
\times { c8 d e f }
will currently by default print with only a 4 in the tuplet bracket,
which is mathematically wrong; the denominator 5 must appear.
--
Trevor Bača
[EMAIL PROTECTED]
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Frédéric Chiasson wrote:
My point when I started this topic was not to change the whole
definition of the \times function. In fact, I think the function works
quite well as it is. I was mostly talking about improving the
interface - i.e . the words and the syntax we use to call the
functions - to make it more intuitive, especially for a
non-programmer. The \times function was an example among other. I was
proposing to change it to \tuplet x:y, simply because it is closer to
the musicians' language (tuplet), and it reflects more the result we
see and we would write manually (3:2 or 7:5, even if we have 6
sixteenth-notes for the 7:5 in contemporary music).
The issue that's emerged out of this discussion, apart from the question
of \times / \tuplet, is that some users (including myself) would like to
see a more obvious (intuitive?) way of generating *sequences* of
tuplets. As has been mentioned before, \times 2/3 { a8 a a b b b }
doesn't produce two triplets, as you might expect, but six notes with a
single bracket and a 3 over it - to get the desired result, it's
necessary to add \set tupletSpannerDuration = #(ly:make-moment 1 4). For
new users especially, this is a bit daunting IMO.
Changing \times x/y to \tuplet y:x may be more intuitive for
non-programmer musician, but if they still have to use \set
tupletSpannerDuration = #(ly:make-moment ...), I don't see that you've
gained much.
For this reason, I think Erik's proposal of a \tupletSequence function
makes a lot of sense. (Though \tupletSet is shorter to type. ;-) )
Brett
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
. . . Note also that the tupletSequence
function would be implemented entirely in Scheme . . .
I'm not very fluent in Scheme, so this is a naive question.
I presume that ratios like 3:2 (or 2/3) could be made into some kind of
object type (possibly a moment). So I could imagine that it would be
possible to write a Scheme function definition to cover a syntax like
\tupletSequence m:n #'( {...} {...} ... )
where the first argument is a moment and the second is a list of literal
music expressions. (And I suppose I'm too optimistic about that syntax;
probably those {...} would have to be sprinkled with # or $ or other
spices.) But there are some questions:
1) I don't see how this could accommodate the case where one of the music
expressions *were* a variable reference (\var) or *contained* a variable
reference.
2) Because the syntax \tupletSequence m:n { {...} {...} }
is nicer, it would be good if it could be written that way, but then the
second argument would not be a standard Scheme entity, so I don't see how
Scheme could handle it at all.
I don't really want you to explain to me how the tupletSequence function
would be written in Scheme, as I think that that would wind up being an
exceedingly long answer. My question is only this: with your knowledge of
Scheme, is it clear to you that difficulties (1) (2) are handleable?
Can tupletSequence really be defined in pure Scheme, as long as the parser
is modified to recognize the object m:n or n/m (so that there would exist
a type-verification-name for the object m:n for use in defining Scheme
functions)?
-- Tom
*
On Sat, 6 Jan 2007, Erik Sandberg wrote:
On Friday 05 January 2007 22:53, [EMAIL PROTECTED] wrote:
. . . The { m1 m2 m3 } syntax is used for repeat alternatives
already, and the meaning is very clear: Each music expression between the
outer { } is a separate argument. Note also that the tupletSequence
function would be implemented entirely in Scheme . . .
{ {g8 f e} \seq {b8 a g} }
\tuplet {g f e} \tuplet \seq \tuplet {b a g}
{{c d e} {{f g} a} b c}
\tuplet {c d e} \tuplet {{f g} a} \tuplet b \tuplet c
OK. Thank you for clarifying that. I understand, from your original
remarks, that (here) you have written just \tuplet in the interest of
brevity, and that the full form would be
\tupletSequence 3:2 {{c d e} {{f g} a} b c}
meaning
\tuplet 3:2 {c d e} \tuplet 3:2 {{f g} a} \tuplet 3:2 b \tuplet 3:2 c
yes, that's right.
which implies the following things:
a) tupletSequence is a Scheme function which just breaks up its
subexpressions naively, without any semantic analysis.
b) \tuplet is a real LilyPond function; it is identical to \times,
except that the notation 3:2 (meaning 2/3) would be allowed.
c) People would have to write \tupletSequence m:n { {...} {...} },
not \tuplet m:n { {...} {...} }.
yep, this is right (thanks for expressing it clearly).
d) Any semantic errors in the subexpressions would be reported by the
\tuplet function, not by the \tupletSequence Scheme function.
technically this is not correct (the \tuplet function doesn't detect semantic
errors), but in principle you're right (\tuplet and \tupletSequence actually
only create Music data structures, without performing semantic analysis;
most 'semantic errors' are detected either when these data structures are
further processed into typeset scores, or by the parser before the function
applications)
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Trevor --
Thank you for your very clear explanation. I learned a lot from that.
I am nevertheless amazed that a performer would be able to keep track of
15/56ths of a whole note(!).
Note, importantly, that, with the present tuplet syntax, lily handles
all tuplets -- *including broken ones* -- correctly out of the box.
This sort of thing brings Finale and Sibelius screaming to their
knees. (This seems to be an extension of the fact that lily gets one
thing *exceedingly* correct: the duration model of musical time.
Well, isn't that a good argument for just leaving the whole thing alone?
I think changing \times to \tuplet is a great idea for the reason that
started the thread: \times is too close to \time.
That I really don't get. LilyPond is written in *English*. There is a
word time and there is another word times; they don't mean the same
thing, that's all. To write LilyPond code, we have to distinguish between
\override \set,
Script TextScript,
\addlyrics \lyricsto,
(not to mention foo bar).
People who speak a Romance language have to learn the difference between
\clef \key.
And we have to write things like
#(override-auto-beam-setting '(end * * 5 8) 3 8)
and
\override Score.RehursalMarc #'brake-visibility =
#begin-of-align-invisibile
and
\acciaccatura { c16[ d] } e4 % 4 c's, not 2 or 3, no ch's or k's
correctly. But people are confused by \time vs. \times ?
Hmmm. Well then, I'm confused about \with-color, \center-align, and
\lyricmode (I've never seen a lyric). Could we please get these changed
to \with-colour, \centre-align, and \lyricsmode?
-- Tom
On Tue, 2 Jan 2007, [UTF-8] Trevor BaÄa wrote:
On 1/2/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
... in irregular, tuplet-intensive music it may be sensible to create a
music function for sequences of tuplets. In addition, it's IMHO a more
lilypondesque solution than tupletSpannerDuration, once we support
fractions
as music function arguments.
If I understand you correctly, this would involve specifying, one way or
another, the duration of each actual tuplet. Explicit specification of a
duration (other than by an external tupletSpannerDuration declaration) has
been suggested by another user, and IMO it would be a good idea, although
I gather that Han-Wen is not in favour of the idea.
But I have a question about how one would specify a duration. Specifying
durations in the way we usually think about them allows actual durations
that look like this:
1== 1
2... == 15/16
2.. == 7/8
2. == 3/4
4... == 15/32
4.. == 7/16
4. == 3/8
4== 1/4
(etc.)
so that only durations of the form
2^(p-1) / 2^q (where p q)
can be specified this way. But given the extravagancies of contemporary
music, wouldn't it be possible, for example, to have a tuplet where 4
eighth notes would be played over a time interval of 5 eighths --
\times 5/4 {c8 d e f}
Or does such a thing never happen?
It most certainly does. All the time, in fact.
Not only that, but an increasing amount of modern music considers the
following valid:
\times 5/7 { c'16 c'16 c'16 c'16 c'16 c'16 } % note six sixteenths
only (not seven)
What's going on here are 7 sixteenths in the time of 5 sixteenths BUT
only the first 6 of those 7 sixteenths actually appear. You could call
this sort of thing a broken tuplet, and the overall duration of the
figure here is then 6/7 of 5 sixteenths or 15/56 of a whole note
(which lily would express as #(ly:make-moment 15 56)).
These broken tuplets would then pose a much, much greater difficulty
of expressing were we to move to a duration-based syntax for tuplets.
Broken tuplets may look insane, but take a look at the devestatingly
beatiful Sciarrino flute pieces -- plenty of examples, and all
completely idiomatic.
Note, importantly, that, with the present tuplet syntax, lily handles
all tuplets -- *including broken ones* -- correctly out of the box.
This sort of thing brings Finale and Sibelius screaming to their
knees. (This seems to be an extension of the fact that lily gets one
thing *exceedingly* correct: the duration model of musical time. Out
of the box you can also specify time signatures like 6/15, 5/28, 3/10
and so on, all of which bring other musical notation programs -- with
the the notable exception of SCORE -- to a crashing standstill. Or at
least the last time I bothered to check.)
I've been watching the tuplet discussion with some hesitation. I think
chaning \times to \tuplet is a great idea for the reason that started
the thread: \times is too close to \time. But it seems to me that most
of the suggestions following that initial suggestion begin to confuse
the essential time-scaling function of tuplet brackets (which is their
absolutely core purpose, both in the common practice and now) and
Re: Constructive Criticism and a Question
I think changing \times to \tuplet is a great idea for the reason that started the thread: \times is too close to \time. That I really don't get. LilyPond is written in *English*. US English or British English? This makes a difference... There is a word time and there is another word times; they don't mean the same thing, that's all. Only a native speaker can say that :-) Honestly, it's very easy to intermix them during fast typing. I don't say that the difference between those two words is problematic, just that it unnecessarily increases the probability of a typo. To write LilyPond code, we have to distinguish between \override \set, Script TextScript, \addlyrics \lyricsto, (not to mention foo bar). you are missing the point here. People who speak a Romance language have to learn the difference between \clef \key. Hehe. :-) Hmmm. Well then, I'm confused about \with-color, \center-align, and \lyricmode (I've never seen a lyric). Could we please get these changed to \with-colour, \centre-align, and \lyricsmode? Regarding \lyricsmode I agree. The other two, well, could be handled easily with aliases. Werner ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
. . . \tupletSequence 2/3 {{c d e} {f g a} {b c d}}
would just be a shorthand for
\tuplet 2/3 {c d e} \tuplet 2/3 {f g a} \tuplet 2/3 {b c d}
That would add a big semantic burden to the meaning of { and }.
Currently {{c d e} {f g a} {b c d}} means the same thing as
{c d e f g a b c d}. I would hate to have to write the parser that would
figure out (reliably) what
{{c d e} {f g} {a b c}}
or
{{c d e} {{f g} a} b c}
or
{{c8 d e} {f4 g a}}
mean (as arguments to \tupletSequence). And if
\seq = {{a8 b c} {d8 e f}}
then, since LP macros are *not* string macros, what will the parser
do with the argument
{ {g8 f e} \seq {b8 a g} }
??? I think the parsing problem would be wildly intractable.
-- Tom
***
On Wed, 3 Jan 2007, Erik Sandberg wrote:
On Tuesday 02 January 2007 22:29, [EMAIL PROTECTED] wrote:
... in irregular, tuplet-intensive music it may be sensible to create a
music function for sequences of tuplets. In addition, it's IMHO a more
lilypondesque solution than tupletSpannerDuration, once we support
fractions as music function arguments.
If I understand you correctly, this would involve specifying, one way or
another, the duration of each actual tuplet. Explicit specification of a
duration (other than by an external tupletSpannerDuration declaration) has
been suggested by another user, and IMO it would be a good idea, although
I gather that Han-Wen is not in favour of the idea.
No, \tupletSequence 2/3 {{c d e} {f g a} {b c d}} would just be a shorthand
for \tuplet 2/3 {c d e} \tuplet 2/3 {f g a} \tuplet 2/3 {b c d}
It is problematic to use durations to decide the scaling of a tuplet; this has
been discussed previously in this thread. E.g., if you scale 3 8th notes to
duration 4, then it is unclear whether it corresponds to factor 2/3 or 4/6.
But I have a question about how one would specify a duration. Specifying
durations in the way we usually think about them allows actual durations
that look like this:
1== 1
2... == 15/16
2.. == 7/8
2. == 3/4
4... == 15/32
4.. == 7/16
4. == 3/8
4== 1/4
(etc.)
so that only durations of the form
2^(p-1) / 2^q (where p q)
can be specified this way. But given the extravagancies of contemporary
music, wouldn't it be possible, for example, to have a tuplet where 4
eighth notes would be played over a time interval of 5 eighths --
\times 5/4 {c8 d e f}
Or does such a thing never happen? If it does, then the tuplet's
duration, equal to 5/8 here, cannot be expressed simply by a dotted-note
notation such as in the preceding list.
you could always write 1*5/8, which is a valid duration.
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
There is a word time and there is another word times; they don't
mean the same thing, that's all.
Only a native speaker can say that :-) Honestly, it's very easy to
intermix them during fast typing. I don't say that the difference
between those two words is problematic, just that it unnecessarily
increases the probability of a typo.
I respectfully disagree. I've never mistyped either word in a LilyPond
file. Typing / for \, yes, I've done that; does that mean that I
should be asking for the elimination of the \ symbol? And how many
times have I seen the query . . . Score.RehersalMark . . . doesn't work.
Should we change that to R-mark to avoid typos? Apostrophes (') are a
problem too: it's hard to see them when you're looking for errors; let's
replace them with something clear like *.
Hehe. :-)
That's heehee on this side of the pond. Be glad it's not a LilyPond
keyword. (Although I have frequently felt the need for a
\hoho What the [EMAIL PROTECTED]
construct when I'm trying to position markup.)
-- Tom
**
On Fri, 5 Jan 2007, Werner LEMBERG wrote:
I think changing \times to \tuplet is a great idea for the reason
that started the thread: \times is too close to \time.
That I really don't get. LilyPond is written in *English*.
US English or British English? This makes a difference...
There is a word time and there is another word times; they don't
mean the same thing, that's all.
Only a native speaker can say that :-) Honestly, it's very easy to
intermix them during fast typing. I don't say that the difference
between those two words is problematic, just that it unnecessarily
increases the probability of a typo.
To write LilyPond code, we have to distinguish between
\override \set,
Script TextScript,
\addlyrics \lyricsto,
(not to mention foo bar).
you are missing the point here.
People who speak a Romance language have to learn the difference
between
\clef \key.
Hehe. :-)
Hmmm. Well then, I'm confused about \with-color, \center-align, and
\lyricmode (I've never seen a lyric). Could we please get these
changed to \with-colour, \centre-align, and \lyricsmode?
Regarding \lyricsmode I agree. The other two, well, could be handled
easily with aliases.
Werner
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Only a native speaker can say that :-) Honestly, it's very easy to
intermix them during fast typing. I don't say that the difference
between those two words is problematic, just that it unnecessarily
increases the probability of a typo.
I respectfully disagree. I've never mistyped either word in a
LilyPond file.
Congratulations! I do it regularly.
should be asking for the elimination of the \ symbol? And how
many times have I seen the query . . . Score.RehersalMark
. . . doesn't work. Should we change that to R-mark to avoid
typos?
This is harmless compared to `acciaccatura' :-)
Apostrophes (') are a problem too: it's hard to see them when
you're looking for errors; let's replace them with something clear
like *.
It seems that you should write your scores with MusicXML... This
greatly increases verbosity...
To be serious: Do you see a necessity for a basic LilyPond command to
be an abbreviation of another? Just think of editors which are able
to complete a command with the tab key as soon as you type the first
few letters (Emacs, for example). In case of \time vs. \times, you
always have to add a final `s' or select between two choices.
It would be interesting to do a survey whether there are other
commands belonging into this category. I favour to rename them all to
disambiguate.
Werner
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Friday 05 January 2007 09:22, [EMAIL PROTECTED] wrote:
. . . \tupletSequence 2/3 {{c d e} {f g a} {b c d}}
would just be a shorthand for
\tuplet 2/3 {c d e} \tuplet 2/3 {f g a} \tuplet 2/3 {b c d}
That would add a big semantic burden to the meaning of { and }.
Currently {{c d e} {f g a} {b c d}} means the same thing as
{c d e f g a b c d}.
It's not a problem. The { m1 m2 m3 } syntax is used for repeat alternatives
already, and the meaning is very clear: Each music expression between the
outer { } is a separate argument. Note also that the tupletSequence function
would be implemented entirely in Scheme, the parser would not be modified.
Examples:
I would hate to have to write the parser that would
figure out (reliably) what
{{c d e} {f g} {a b c}}
\tuplet {c d e} \tuplet {f g} \tuplet {a b c}
or
{{c d e} {{f g} a} b c}
\tuplet {c d e} \tuplet {{f g} a} \tuplet b \tuplet c
or
{{c8 d e} {f4 g a}}
\tuplet {c d e} \tuplet {f4 g a}
mean (as arguments to \tupletSequence). And if
\seq = {{a8 b c} {d8 e f}}
then, since LP macros are *not* string macros, what will the parser
do with the argument
{ {g8 f e} \seq {b8 a g} }
\tuplet {g f e} \tuplet \seq \tuplet {b a g}
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
[EMAIL PROTECTED] escreveu: I think changing \times to \tuplet is a great idea for the reason that started the thread: \times is too close to \time. That I really don't get. LilyPond is written in *English*. There is a the other, perhaps more valid reason, is that \tuplet more closely matches the purpose than \times. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
When I started this topic, the point was to suggest a more intuitive syntax, which is closer to the musicians' language and the output on the score. That is why I proposed \tuplet (closer to musicians's language) and 3:2 (closer to the output of the score). In my opinion, I though this function was working very well the way it was. For the syntax topic, I would also suggest to standardize the tweak entries. At this moment, we can have for example : \override Voice.Textscript #'padding = #3 (a number) \override Voice.Stem #'stencil = #ly:stem::print (a function) #(set-global-staff-size 13) \set fontSize = #2 This diversity of syntax is hard to understand and very hard to remember for a non-programmer. Maybe we could replace them by \ functions?? By the way, happy new year to everyone! Frédéric 2007/1/5, Han-Wen Nienhuys [EMAIL PROTECTED]: [EMAIL PROTECTED] escreveu: I think changing \times to \tuplet is a great idea for the reason that started the thread: \times is too close to \time. That I really don't get. LilyPond is written in *English*. There is a the other, perhaps more valid reason, is that \tuplet more closely matches the purpose than \times. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
. . . The { m1 m2 m3 } syntax is used for repeat alternatives
already, and the meaning is very clear: Each music expression between the
outer { } is a separate argument. Note also that the tupletSequence
function would be implemented entirely in Scheme . . .
{ {g8 f e} \seq {b8 a g} }
\tuplet {g f e} \tuplet \seq \tuplet {b a g}
{{c d e} {{f g} a} b c}
\tuplet {c d e} \tuplet {{f g} a} \tuplet b \tuplet c
OK. Thank you for clarifying that. I understand, from your original
remarks, that (here) you have written just \tuplet in the interest of
brevity, and that the full form would be
\tupletSequence 3:2 {{c d e} {{f g} a} b c}
meaning
\tuplet 3:2 {c d e} \tuplet 3:2 {{f g} a} \tuplet 3:2 b \tuplet 3:2 c
which implies the following things:
a) tupletSequence is a Scheme function which just breaks up its
subexpressions naively, without any semantic analysis.
b) \tuplet is a real LilyPond function; it is identical to \times,
except that the notation 3:2 (meaning 2/3) would be allowed.
c) People would have to write \tupletSequence m:n { {...} {...} },
not \tuplet m:n { {...} {...} }.
d) Any semantic errors in the subexpressions would be reported by the
\tuplet function, not by the \tupletSequence Scheme function.
I know this was all clear to you before; I am just summarizing what I got
out of your explanation. I think I have to withdraw my objections; your
reminder that the \alternative construct already uses {...} to indicate
subexpressions is a good point.
-- Tom
On Fri, 5 Jan 2007, Erik Sandberg wrote:
On Friday 05 January 2007 09:22, [EMAIL PROTECTED] wrote:
. . . \tupletSequence 2/3 {{c d e} {f g a} {b c d}}
would just be a shorthand for
\tuplet 2/3 {c d e} \tuplet 2/3 {f g a} \tuplet 2/3 {b c d}
That would add a big semantic burden to the meaning of { and }.
Currently {{c d e} {f g a} {b c d}} means the same thing as
{c d e f g a b c d}.
It's not a problem. The { m1 m2 m3 } syntax is used for repeat alternatives
already, and the meaning is very clear: Each music expression between the
outer { } is a separate argument. Note also that the tupletSequence function
would be implemented entirely in Scheme, the parser would not be modified.
Examples:
I would hate to have to write the parser that would
figure out (reliably) what
{{c d e} {f g} {a b c}}
\tuplet {c d e} \tuplet {f g} \tuplet {a b c}
or
{{c d e} {{f g} a} b c}
\tuplet {c d e} \tuplet {{f g} a} \tuplet b \tuplet c
or
{{c8 d e} {f4 g a}}
\tuplet {c d e} \tuplet {f4 g a}
mean (as arguments to \tupletSequence). And if
\seq = {{a8 b c} {d8 e f}}
then, since LP macros are *not* string macros, what will the parser
do with the argument
{ {g8 f e} \seq {b8 a g} }
\tuplet {g f e} \tuplet \seq \tuplet {b a g}
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Fri, 5 Jan 2007, Han-Wen Nienhuys wrote:
the other, perhaps more valid reason, is that \tuplet more closely matches
the purpose than \times.
OK, I'm clearly in the minority here; I think of
\times 2/3 {c8 d e}
as a series of 12th notes. I would be delighted if LilyPond let me
write
c12 d e
-- Tom
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Quoting [EMAIL PROTECTED]:
On Fri, 5 Jan 2007, Han-Wen Nienhuys wrote:
the other, perhaps more valid reason, is that \tuplet more closely matches
the purpose than \times.
OK, I'm clearly in the minority here; I think of
\times 2/3 {c8 d e}
as a series of 12th notes. I would be delighted if LilyPond let me
write
c12 d e
Then it would need to know what kind of note head and how many flags
it should use for the note. However, you can write c8*2/3 d e
to get the duration you want (even though LilyPond won't add any tuplet
marker).
/Mats
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
To be serious: Do you see a necessity for a basic LilyPond command to be an abbreviation of another? Just think of editors which are able to complete a command with the tab key as soon as you type the first few letters (Emacs, for example). In case of \time vs. \times, you always have to add a final `s' or select between two choices. OK, I use Visual Basic's IDE with auto-completion, so I'm familiar with what you're talking about. (Yes, I hate Microsoft, but I don't have much choice.) But I can see this boils down to broad cultural differences -- -- I touch type, so I could care less how easy something is to type: it's all easy (I use NotePad in Windows). -- 99% of my time is spent arranging ( re-arranging); the minuscule amount of time I spend creating a .ly file is negligible. -- I have skeleton .ly files; I load one of them into NotePad and make some minor changes in the boilerplate. Virtually everything I type is notes, not keywords. So we've got different needs. De gustibus... -- Tom ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
I would be delighted if LilyPond let me write c12 d e Then it would need to know what kind of note head and how many flags it should use for the note. However, you can write c8*2/3 d e to get the duration you want (even though LilyPond won't add any tuplet marker). You're right. There are no 12th-note noteheads; a tuplet function is a necessity. My remark was flippant. I've never used the c8*m/n notation, as I can't figure out why it would be useful. But I appreciate your reminding me of it; maybe someday I'll see the light. -- Tom ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
For the syntax topic, I would also suggest to standardize the tweak entries. At this moment, we can have for example : \override Voice.Textscript #'padding = #3 (a number) \override Voice.Stem #'stencil = #ly:stem::print (a function) #(set-global-staff-size 13) \set fontSize = #2 This diversity of syntax is hard to understand and very hard to remember for a non-programmer. Maybe we could replace them by \ functions?? Ho ho. So the hue and cry for replacing \times by \tuplet has now led to a request to overhaul all of LilyPond's syntax. *That* will be a big job! -- Tom ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Tuesday 02 January 2007 22:29, [EMAIL PROTECTED] wrote:
... in irregular, tuplet-intensive music it may be sensible to create a
music function for sequences of tuplets. In addition, it's IMHO a more
lilypondesque solution than tupletSpannerDuration, once we support
fractions as music function arguments.
If I understand you correctly, this would involve specifying, one way or
another, the duration of each actual tuplet. Explicit specification of a
duration (other than by an external tupletSpannerDuration declaration) has
been suggested by another user, and IMO it would be a good idea, although
I gather that Han-Wen is not in favour of the idea.
No, \tupletSequence 2/3 {{c d e} {f g a} {b c d}} would just be a shorthand
for \tuplet 2/3 {c d e} \tuplet 2/3 {f g a} \tuplet 2/3 {b c d}
It is problematic to use durations to decide the scaling of a tuplet; this has
been discussed previously in this thread. E.g., if you scale 3 8th notes to
duration 4, then it is unclear whether it corresponds to factor 2/3 or 4/6.
But I have a question about how one would specify a duration. Specifying
durations in the way we usually think about them allows actual durations
that look like this:
1== 1
2... == 15/16
2.. == 7/8
2. == 3/4
4... == 15/32
4.. == 7/16
4. == 3/8
4== 1/4
(etc.)
so that only durations of the form
2^(p-1) / 2^q (where p q)
can be specified this way. But given the extravagancies of contemporary
music, wouldn't it be possible, for example, to have a tuplet where 4
eighth notes would be played over a time interval of 5 eighths --
\times 5/4 {c8 d e f}
Or does such a thing never happen? If it does, then the tuplet's
duration, equal to 5/8 here, cannot be expressed simply by a dotted-note
notation such as in the preceding list.
you could always write 1*5/8, which is a valid duration.
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Monday 01 January 2007 20:57, Mats Bengtsson wrote:
Frédéric Chiasson wrote:
Might it be possible to use
\tuplet 3:2 {x x x}
for the usual operation, and if we want to have many tuplets of the
same kind, to use
\tuplet 3:2 { {x x x} {y y y} {z z z} }
Might resolve the clarity problems.
Since it's easy to define your own function \triplet which
does the equivalent of \tuplet 3:2 ..., and since you could
give it a short name like \t, your proposal wouldn't save
much typing or increase the clarity compared to
\t {x x x} \t {y y y} \t {z z z}
In these situations with repetitive triplet patterns, I definitely
prefer the current kind of solution with
\set tupletSpannerDuration = #(ly:make-moment 1 4)
There is one problem with this: If the 'most common' tuplet duration is 1/4,
but you occasionally have a different tuplet with _longer_ duration, then
tupletSpannerDuration will break the long tuplet into several shorter
durations, unless you always remember to \unset tupletSpannerDuration all the
time.
So, in irregular, tuplet-intensive music it may be sensible to create a music
function for sequences of tuplets. In addition, it's IMHO a more
lilypondesque solution than tupletSpannerDuration, once we support fractions
as music function arguments.
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
... in irregular, tuplet-intensive music it may be sensible to create a
music function for sequences of tuplets. In addition, it's IMHO a more
lilypondesque solution than tupletSpannerDuration, once we support fractions
as music function arguments.
If I understand you correctly, this would involve specifying, one way or
another, the duration of each actual tuplet. Explicit specification of a
duration (other than by an external tupletSpannerDuration declaration) has
been suggested by another user, and IMO it would be a good idea, although
I gather that Han-Wen is not in favour of the idea.
But I have a question about how one would specify a duration. Specifying
durations in the way we usually think about them allows actual durations
that look like this:
1== 1
2... == 15/16
2.. == 7/8
2. == 3/4
4... == 15/32
4.. == 7/16
4. == 3/8
4== 1/4
(etc.)
so that only durations of the form
2^(p-1) / 2^q (where p q)
can be specified this way. But given the extravagancies of contemporary
music, wouldn't it be possible, for example, to have a tuplet where 4
eighth notes would be played over a time interval of 5 eighths --
\times 5/4 {c8 d e f}
Or does such a thing never happen? If it does, then the tuplet's
duration, equal to 5/8 here, cannot be expressed simply by a dotted-note
notation such as in the preceding list. A duration of 5/8 would have to
be expressed by something similar to a make-moment fraction. (Even with
this complication, I would still find it desirable to be able to express
the duration of a tuplet within the [hypothetical] \tuplet construct;
it's the only thing that would make \tuplet functionally different from
\times anyway.)
-- Tom
**
On Tue, 2 Jan 2007, Erik Sandberg wrote:
On Monday 01 January 2007 20:57, Mats Bengtsson wrote:
Frédéric Chiasson wrote:
Might it be possible to use
\tuplet 3:2 {x x x}
for the usual operation, and if we want to have many tuplets of the
same kind, to use
\tuplet 3:2 { {x x x} {y y y} {z z z} }
Might resolve the clarity problems.
Since it's easy to define your own function \triplet which
does the equivalent of \tuplet 3:2 ..., and since you could
give it a short name like \t, your proposal wouldn't save
much typing or increase the clarity compared to
\t {x x x} \t {y y y} \t {z z z}
In these situations with repetitive triplet patterns, I definitely
prefer the current kind of solution with
\set tupletSpannerDuration = #(ly:make-moment 1 4)
There is one problem with this: If the 'most common' tuplet duration is 1/4,
but you occasionally have a different tuplet with _longer_ duration, then
tupletSpannerDuration will break the long tuplet into several shorter
durations, unless you always remember to \unset tupletSpannerDuration all the
time.
So, in irregular, tuplet-intensive music it may be sensible to create a music
function for sequences of tuplets. In addition, it's IMHO a more
lilypondesque solution than tupletSpannerDuration, once we support fractions
as music function arguments.
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On 1/2/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
... in irregular, tuplet-intensive music it may be sensible to create a
music function for sequences of tuplets. In addition, it's IMHO a more
lilypondesque solution than tupletSpannerDuration, once we support fractions
as music function arguments.
If I understand you correctly, this would involve specifying, one way or
another, the duration of each actual tuplet. Explicit specification of a
duration (other than by an external tupletSpannerDuration declaration) has
been suggested by another user, and IMO it would be a good idea, although
I gather that Han-Wen is not in favour of the idea.
But I have a question about how one would specify a duration. Specifying
durations in the way we usually think about them allows actual durations
that look like this:
1== 1
2... == 15/16
2.. == 7/8
2. == 3/4
4... == 15/32
4.. == 7/16
4. == 3/8
4== 1/4
(etc.)
so that only durations of the form
2^(p-1) / 2^q (where p q)
can be specified this way. But given the extravagancies of contemporary
music, wouldn't it be possible, for example, to have a tuplet where 4
eighth notes would be played over a time interval of 5 eighths --
\times 5/4 {c8 d e f}
Or does such a thing never happen?
It most certainly does. All the time, in fact.
Not only that, but an increasing amount of modern music considers the
following valid:
\times 5/7 { c'16 c'16 c'16 c'16 c'16 c'16 } % note six sixteenths
only (not seven)
What's going on here are 7 sixteenths in the time of 5 sixteenths BUT
only the first 6 of those 7 sixteenths actually appear. You could call
this sort of thing a broken tuplet, and the overall duration of the
figure here is then 6/7 of 5 sixteenths or 15/56 of a whole note
(which lily would express as #(ly:make-moment 15 56)).
These broken tuplets would then pose a much, much greater difficulty
of expressing were we to move to a duration-based syntax for tuplets.
Broken tuplets may look insane, but take a look at the devestatingly
beatiful Sciarrino flute pieces -- plenty of examples, and all
completely idiomatic.
Note, importantly, that, with the present tuplet syntax, lily handles
all tuplets -- *including broken ones* -- correctly out of the box.
This sort of thing brings Finale and Sibelius screaming to their
knees. (This seems to be an extension of the fact that lily gets one
thing *exceedingly* correct: the duration model of musical time. Out
of the box you can also specify time signatures like 6/15, 5/28, 3/10
and so on, all of which bring other musical notation programs -- with
the the notable exception of SCORE -- to a crashing standstill. Or at
least the last time I bothered to check.)
I've been watching the tuplet discussion with some hesitation. I think
chaning \times to \tuplet is a great idea for the reason that started
the thread: \times is too close to \time. But it seems to me that most
of the suggestions following that initial suggestion begin to confuse
the essential time-scaling function of tuplet brackets (which is their
absolutely core purpose, both in the common practice and now) and
other graphical aspects of the notation such as beaming, grouping (and
even accentuation). Beaming and grouping are terribly important, of
course, but I think that it's best to leave their specification out of
the core tuplet syntax.
More important is to fix the fact that
\times { c8 d e f }
will currently by default print with only a 4 in the tuplet bracket,
which is mathematically wrong; the denominator 5 must appear.
--
Trevor Bača
[EMAIL PROTECTED]
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Thursday 28 December 2006 11:13, Brett Duncan wrote:
Erik Sandberg wrote:
On Monday 25 December 2006 06:32, David Fedoruk wrote:
Hello:
I've been watching this discussion or debate. There are two ways to
look at this problem. The first is from a programmer's point of view
where the programmer is experienced with some computer languages,
these days its upper level languages more and more. For these people,
lilypond typesetting code feels comfortable when it is syntactically
correct and when it makes sense in either computer or mathematical
terms. A mathematical algorithm is what they are used to seeing.
The other group has less mathematical knowledge, very little (very
little compared to a programmer working on a major project like
Lilypond) programming knowledge or experience. In all likelihood the
only thing that connects these people is the printed musical score.
At least in part I think these points have already been made. The
question that occurs to me as a novice Lilypond user (and one who
jumps in the deep end with complex scores!) is this: How will you
deal with other types of prolongation or compression of notes into one
or more beats or where the composers intentions are clear but they are
not immediately mathematically correct?
The example below is a single bar from a Beethoven Piano Sonata (Opus
31 number 3, 1st mvt. bar 53) in which two more out of the ordinary
examples occur next to each other. You will excuse any mistakes in
coding here, this doesn't render as it should.
upper = \relative c'' {
\clef treble
\key ef \major
\time 3
bf16[d f ef] \times 5/4 d16[ ef f g a] bf32[bf a c bf d c bf a g c g
ef]
}
You can see how there are three beams, one for the notes in eaech
beat. The first and second beat are quite clear, but the third one has
eluded me as yet. The score has 12 thirty-second notes beamed together
with 12 below the note heads.
The printed score is clear to the performer. The Lilypond code I
suspect is far more complex. The only way that 12 thirty-second notes
will fit into one beat is if they are triplets, but in context, they
are not played or heard as triplets.
My only comment in this discussion is that the Lilypond code to
represent this short passage should be as clear as the printed score I
am reading.
try \times 8/12 { ... }
(by default, this will probably display as 12:8 above the notes, which
can be tweaked to just show 12)
IMHO, this is an argument for a mathematical notation: You must know what
you are doing to notate the music (i.e., multiplying durations with
8/12), just saying that a 12 should be displayed above would make it
difficult to maintain the .ly code.
Here's a different idea: instead of specifying the ratio for a tuplet or
set of tuplets, what about specifying the duration of a tuplet, and
letting LP determine what number appears over the beam?
For example, where we now use
\times 2/3 { a8 b c }
to get a triplet of three quavers in the time of two, instead have
\tuplet 4 { a8 b c }
LP can calculate the ratio (and hence what should appear over the
tuplet) from the time given before the {...} and the cumulative time of
the notes inside the {...}.
This would mean that users do not need to work out the ratio, they just
need to know how long the tuplet should last. Further to this idea would
be to allow an internal division inside the {...}, so that multiple
tuplets could be entered, maybe something like \tuplet 4 { a8 b c ! c4
a8 ! b8 c4 }. (I've used ! only for explaining the idea - I'm NOT
advocating it as the desired syntax.)
This would mean that for the Beethoven snippet in David Fedoruk's post,
instead of
bf16[d, f ef] \times 4/5 {d16[ ef f g a]} \times 8/12 {bf32[a c bf d c
bf a g f g ef]}
you would put
bf16[d, f ef] \tuplet 4 { d16 ef f g a ! bf32a c bf d c bf a g f g ef }
Just a thought!
Unfortunately, the number above does not always follow from the duration.
E.g., the factors 2/3 and 4/6 are mathematically equal, but give different
numbers. It is probably difficult to define when to use 4/6 and 2/3,
respectively (e.g., I guess {c8[ c16 c c8]} could have either a 3 or a 6
above it, depending on context)
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Erik Sandberg escreveu:
Unfortunately, the number above does not always follow from the duration.
E.g., the factors 2/3 and 4/6 are mathematically equal, but give different
numbers. It is probably difficult to define when to use 4/6 and 2/3,
respectively (e.g., I guess {c8[ c16 c c8]} could have either a 3 or a 6
above it, depending on context)
Frankly, this discussion has wandered off into bikeshed land. We will not base
typesetting decisions on the form of the \times/\tuplet argument, for it
is incompatible with using identifiers.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Erik Sandberg wrote:
On Thursday 28 December 2006 11:13, Brett Duncan wrote:
Erik Sandberg wrote:
On Monday 25 December 2006 06:32, David Fedoruk wrote:
Hello:
I've been watching this discussion or debate. There are two ways to
look at this problem. The first is from a programmer's point of view
where the programmer is experienced with some computer languages,
these days its upper level languages more and more. For these people,
lilypond typesetting code feels comfortable when it is syntactically
correct and when it makes sense in either computer or mathematical
terms. A mathematical algorithm is what they are used to seeing.
The other group has less mathematical knowledge, very little (very
little compared to a programmer working on a major project like
Lilypond) programming knowledge or experience. In all likelihood the
only thing that connects these people is the printed musical score.
At least in part I think these points have already been made. The
question that occurs to me as a novice Lilypond user (and one who
jumps in the deep end with complex scores!) is this: How will you
deal with other types of prolongation or compression of notes into one
or more beats or where the composers intentions are clear but they are
not immediately mathematically correct?
The example below is a single bar from a Beethoven Piano Sonata (Opus
31 number 3, 1st mvt. bar 53) in which two more out of the ordinary
examples occur next to each other. You will excuse any mistakes in
coding here, this doesn't render as it should.
upper = \relative c'' {
\clef treble
\key ef \major
\time 3
bf16[d f ef] \times 5/4 d16[ ef f g a] bf32[bf a c bf d c bf a g c g
ef]
}
You can see how there are three beams, one for the notes in eaech
beat. The first and second beat are quite clear, but the third one has
eluded me as yet. The score has 12 thirty-second notes beamed together
with 12 below the note heads.
The printed score is clear to the performer. The Lilypond code I
suspect is far more complex. The only way that 12 thirty-second notes
will fit into one beat is if they are triplets, but in context, they
are not played or heard as triplets.
My only comment in this discussion is that the Lilypond code to
represent this short passage should be as clear as the printed score I
am reading.
try \times 8/12 { ... }
(by default, this will probably display as 12:8 above the notes, which
can be tweaked to just show 12)
IMHO, this is an argument for a mathematical notation: You must know what
you are doing to notate the music (i.e., multiplying durations with
8/12), just saying that a 12 should be displayed above would make it
difficult to maintain the .ly code.
Here's a different idea: instead of specifying the ratio for a tuplet or
set of tuplets, what about specifying the duration of a tuplet, and
letting LP determine what number appears over the beam?
For example, where we now use
\times 2/3 { a8 b c }
to get a triplet of three quavers in the time of two, instead have
\tuplet 4 { a8 b c }
LP can calculate the ratio (and hence what should appear over the
tuplet) from the time given before the {...} and the cumulative time of
the notes inside the {...}.
This would mean that users do not need to work out the ratio, they just
need to know how long the tuplet should last. Further to this idea would
be to allow an internal division inside the {...}, so that multiple
tuplets could be entered, maybe something like \tuplet 4 { a8 b c ! c4
a8 ! b8 c4 }. (I've used ! only for explaining the idea - I'm NOT
advocating it as the desired syntax.)
This would mean that for the Beethoven snippet in David Fedoruk's post,
instead of
bf16[d, f ef] \times 4/5 {d16[ ef f g a]} \times 8/12 {bf32[a c bf d c
bf a g f g ef]}
you would put
bf16[d, f ef] \tuplet 4 { d16 ef f g a ! bf32a c bf d c bf a g f g ef }
Just a thought!
Unfortunately, the number above does not always follow from the duration.
E.g., the factors 2/3 and 4/6 are mathematically equal, but give different
numbers. It is probably difficult to define when to use 4/6 and 2/3,
respectively (e.g., I guess {c8[ c16 c c8]} could have either a 3 or a 6
above it, depending on context)
Yes, you're quite correct - I'd overlooked that. So Rick Hansen's
suggestion of a tuplet number function would also be necessary,
But given Han-Wen's post:
Frankly, this discussion has wandered off into bikeshed land. We will
not base typesetting decisions on the form of the \times/\tuplet
argument, for it is incompatible with using identifiers.
I guess there's no point in continuing the discussion.
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Erik Sandberg wrote:
On Monday 25 December 2006 06:32, David Fedoruk wrote:
Hello:
I've been watching this discussion or debate. There are two ways to
look at this problem. The first is from a programmer's point of view
where the programmer is experienced with some computer languages,
these days its upper level languages more and more. For these people,
lilypond typesetting code feels comfortable when it is syntactically
correct and when it makes sense in either computer or mathematical
terms. A mathematical algorithm is what they are used to seeing.
The other group has less mathematical knowledge, very little (very
little compared to a programmer working on a major project like
Lilypond) programming knowledge or experience. In all likelihood the
only thing that connects these people is the printed musical score.
At least in part I think these points have already been made. The
question that occurs to me as a novice Lilypond user (and one who
jumps in the deep end with complex scores!) is this: How will you
deal with other types of prolongation or compression of notes into one
or more beats or where the composers intentions are clear but they are
not immediately mathematically correct?
The example below is a single bar from a Beethoven Piano Sonata (Opus
31 number 3, 1st mvt. bar 53) in which two more out of the ordinary
examples occur next to each other. You will excuse any mistakes in
coding here, this doesn't render as it should.
upper = \relative c'' {
\clef treble
\key ef \major
\time 3
bf16[d f ef] \times 5/4 d16[ ef f g a] bf32[bf a c bf d c bf a g c g ef]
}
You can see how there are three beams, one for the notes in eaech
beat. The first and second beat are quite clear, but the third one has
eluded me as yet. The score has 12 thirty-second notes beamed together
with 12 below the note heads.
The printed score is clear to the performer. The Lilypond code I
suspect is far more complex. The only way that 12 thirty-second notes
will fit into one beat is if they are triplets, but in context, they
are not played or heard as triplets.
My only comment in this discussion is that the Lilypond code to
represent this short passage should be as clear as the printed score I
am reading.
try \times 8/12 { ... }
(by default, this will probably display as 12:8 above the notes, which can be
tweaked to just show 12)
IMHO, this is an argument for a mathematical notation: You must know what you
are doing to notate the music (i.e., multiplying durations with 8/12), just
saying that a 12 should be displayed above would make it difficult to
maintain the .ly code.
Here's a different idea: instead of specifying the ratio for a tuplet or
set of tuplets, what about specifying the duration of a tuplet, and
letting LP determine what number appears over the beam?
For example, where we now use
\times 2/3 { a8 b c }
to get a triplet of three quavers in the time of two, instead have
\tuplet 4 { a8 b c }
LP can calculate the ratio (and hence what should appear over the
tuplet) from the time given before the {...} and the cumulative time of
the notes inside the {...}.
This would mean that users do not need to work out the ratio, they just
need to know how long the tuplet should last. Further to this idea would
be to allow an internal division inside the {...}, so that multiple
tuplets could be entered, maybe something like \tuplet 4 { a8 b c ! c4
a8 ! b8 c4 }. (I've used ! only for explaining the idea - I'm NOT
advocating it as the desired syntax.)
This would mean that for the Beethoven snippet in David Fedoruk's post,
instead of
bf16[d, f ef] \times 4/5 {d16[ ef f g a]} \times 8/12 {bf32[a c bf d c
bf a g f g ef]}
you would put
bf16[d, f ef] \tuplet 4 { d16 ef f g a ! bf32a c bf d c bf a g f g ef }
Just a thought!
Brett
--
Brett Duncan
[EMAIL PROTECTED]
Always do right - this will gratify some and astonish the rest.
Mark Twain
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Brett Duncan-2 wrote:
Here's a different idea: instead of specifying the ratio for a tuplet or
set of tuplets, what about specifying the duration of a tuplet, and
letting LP determine what number appears over the beam?
For example, where we now use
\times 2/3 { a8 b c }
to get a triplet of three quavers in the time of two, instead have
\tuplet 4 { a8 b c }
LP can calculate the ratio (and hence what should appear over the
tuplet) from the time given before the {...} and the cumulative time of
the notes inside the {...}.
This would mean that users do not need to work out the ratio, they just
need to know how long the tuplet should last. Further to this idea would
be to allow an internal division inside the {...}, so that multiple
tuplets could be entered, maybe something like \tuplet 4 { a8 b c ! c4
a8 ! b8 c4 }. (I've used ! only for explaining the idea - I'm NOT
advocating it as the desired syntax.)
This would mean that for the Beethoven snippet in David Fedoruk's post,
instead of
bf16[d, f ef] \times 4/5 {d16[ ef f g a]} \times 8/12 {bf32[a c bf d c
bf a g f g ef]}
you would put
bf16[d, f ef] \tuplet 4 { d16 ef f g a ! bf32a c bf d c bf a g f g ef }
Just a thought!
Brett
--
Brett Duncan
[EMAIL PROTECTED]
Always do right - this will gratify some and astonish the rest.
Mark Twain
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Given your example of...
bf16[d, f ef] \tuplet 4 { d16 ef f g a ! bf32a c bf d c bf a g f g ef }
could be even more intuitive by using only nested brackets with each nested
bracket pair determining a tuplet bracket and note counter, and the
outermost bracket pair encompassing the preceeding duration number, like
this:
bf16[d, f ef] \tuplet 4 { { d16 ef f g a } { bf32a c bf d c bf a g f g ef }
}
Then tuplets can be nested both horizontally and depth-wise with the
graphical brackets automatically generated with the note counter equal to
the number of noted in that bracket pair. If the user wants a different
number or no number on the tuplet bracket then they can specify a different
value within the bracket pair like this (with 0 meaning no number):
bf16[d, f ef] \tuplet 4 { { \tupletNbr 0 d16 ef f g a } { bf32a c bf d c bf
a g f g ef } }
In the above they could eliminate the auto-generated 5 if for some reason
they wanted to.
With this syntax they could also create sub groupings of tuplet brackets:
bf16[d, f ef] \tuplet 4 { { { d16 ef f } { g a } } { bf32a c bf d c bf a g f
g ef } }
The above would generate a parent tuplet with the number 5 and two
sub-tuplets with 3 and 2, followed horizontally by the 12 tuplet.
--
View this message in context:
http://www.nabble.com/Constructive-Criticism-and-a-Question-tf2832276.html#a8077255
Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com.
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Brett Duncan-2 wrote:
Here's a different idea: instead of specifying the ratio for a
tuplet or set of tuplets, what about specifying the duration of a
tuplet, and letting LP determine what number appears over the beam?
...to which Rick Hansen replied:
Given your example of...
bf16[d, f ef] \tuplet 4 { d16 ef f g a ! bf32a c bf d c bf a g f g ef }
could be even more intuitive by using only nested brackets with each
nested bracket pair determining a tuplet bracket and note counter, and
the outermost bracket pair encompassing the preceeding duration
number, like this:
bf16[d, f ef] \tuplet 4 { { d16 ef f g a } { bf32a c bf d c bf a g f g
ef }
}
Then tuplets can be nested both horizontally and depth-wise with the
graphical brackets automatically generated with the note counter equal
to the number of noted in that bracket pair. If the user wants a
different number or no number on the tuplet bracket then they can
specify a different value within the bracket pair like this (with 0
meaning no number):
bf16[d, f ef] \tuplet 4 { { \tupletNbr 0 d16 ef f g a } { bf32a c bf d c
bf
a g f g ef } }
In the above they could eliminate the auto-generated 5 if for some
reason they wanted to.
With this syntax they could also create sub groupings of tuplet
brackets:
bf16[d, f ef] \tuplet 4 { { { d16 ef f } { g a } } { bf32a c bf d c bf a
g f
g ef } }
The above would generate a parent tuplet with the number 5 and two
sub-tuplets with 3 and 2, followed horizontally by the 12 tuplet.
Wow! Why didn't I think of that!
I have no idea what kind of work this would be to implement, but to me
something like this seems an excellent solution. Clear to read under almost any
circumstances, easy to write, and would (I think) reduce user errors
considerably.
David
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Am 28. Dezember 2006, 11:30 Uhr (-0800) schrieb David Rogers:
bf16[d, f ef] \tuplet 4 { { { d16 ef f } { g a } } { bf32a c bf d c bf a
g f
g ef } }
The above would generate a parent tuplet with the number 5 and two
sub-tuplets with 3 and 2, followed horizontally by the 12 tuplet.
If you intend to think of tuplets as collections of notes of the same
duration, the syntax is fine. But what happens, if the elements of the
tuplet contain things of different durations (for example, the first
part of your suggested tuplet is of an quarter duration and the second
half containing the 12 32nds should last a dotted quarter within the
parent 5 tuplet)?
--
Orm
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Orm Finnendahl wrote:
Am 28. Dezember 2006, 11:30 Uhr (-0800) schrieb David Rogers:
bf16[d, f ef] \tuplet 4 { { { d16 ef f } { g a } } { bf32a c bf d c
bf a
g f
g ef } }
The above would generate a parent tuplet with the number 5 and two
sub-tuplets with 3 and 2, followed horizontally by the 12
tuplet.
If you intend to think of tuplets as collections of notes of the same
duration, the syntax is fine. But what happens, if the elements of the
tuplet contain things of different durations (for example, the first
part of your suggested tuplet is of an quarter duration and the second
half containing the 12 32nds should last a dotted quarter within the
parent 5 tuplet)?
In the Beethoven example, Op.31 Nr.3 at bar 53, the 5-let is a quarter-note
duration, and the 12-let is another quarter-note duration.
But this was Rick Hansen's proposal, for how to solve a problem pointed out by
David Fedoruk, and I was only admiring his solution.
David
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
David Rogers wrote:
Orm Finnendahl wrote:
Am 28. Dezember 2006, 11:30 Uhr (-0800) schrieb David Rogers:
bf16[d, f ef] \tuplet 4 { { { d16 ef f } { g a } } { bf32a c bf d c
bf a
g f
g ef } }
The above would generate a parent tuplet with the number 5 and two
sub-tuplets with 3 and 2, followed horizontally by the 12
tuplet.
If you intend to think of tuplets as collections of notes of the same
duration, the syntax is fine. But what happens, if the elements of the
tuplet contain things of different durations (for example, the first
part of your suggested tuplet is of an quarter duration and the second
half containing the 12 32nds should last a dotted quarter within the
parent 5 tuplet)?
In the Beethoven example, Op.31 Nr.3 at bar 53, the 5-let is a
quarter-note duration, and the 12-let is another quarter-note duration.
But this was Rick Hansen's proposal, for how to solve a problem pointed
out by David Fedoruk, and I was only admiring his solution.
David
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
When the notes in a bracket are of mixed durations then by default no digit
would be generated only the bracket. If the user wanted a digit on a
mixed-note tuplet they can add the \tupletNbr x indicator within that
bracket of notes.
As for summing the durations to match the parent stated \tuplet x
duration... This would not happen, instead durations stated within a
\tuplet structure would be there solely for the purpose of determining the
STYLE of the noteheads being printed. IOW durations in a known-duration
tuplet contruct would not participate in any further evaluation math-wise of
expired time, just as a convenient way of setting the noteheads. Because
the true duration of the whole construct has already been stated on the
\tuplet x there is no need to validate further, the tuplets total duration
is still whatever they coded it to be at the outset.
--
View this message in context:
http://www.nabble.com/Constructive-Criticism-and-a-Question-tf2832276.html#a8079920
Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com.
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Rick Hansen (aka RickH) wrote:
David Rogers wrote:
Orm Finnendahl wrote:
Am 28. Dezember 2006, 11:30 Uhr (-0800) schrieb David Rogers:
bf16[d, f ef] \tuplet 4 { { { d16 ef f } { g a } } { bf32a c bf d c
bf a
g f
g ef } }
The above would generate a parent tuplet with the number 5 and two
sub-tuplets with 3 and 2, followed horizontally by the 12
tuplet.
If you intend to think of tuplets as collections of notes of the same
duration, the syntax is fine. But what happens, if the elements of the
tuplet contain things of different durations (for example, the first
part of your suggested tuplet is of an quarter duration and the second
half containing the 12 32nds should last a dotted quarter within the
parent 5 tuplet)?
In the Beethoven example, Op.31 Nr.3 at bar 53, the 5-let is a
quarter-note duration, and the 12-let is another quarter-note duration.
But this was Rick Hansen's proposal, for how to solve a problem pointed
out by David Fedoruk, and I was only admiring his solution.
David
When the notes in a bracket are of mixed durations then by default no digit
would be generated only the bracket. If the user wanted a digit on a
mixed-note tuplet they can add the \tupletNbr x indicator within that
bracket of notes.
As for summing the durations to match the parent stated \tuplet x
duration... This would not happen, instead durations stated within a
\tuplet structure would be there solely for the purpose of determining the
STYLE of the noteheads being printed. IOW durations in a known-duration
tuplet contruct would not participate in any further evaluation math-wise of
expired time, just as a convenient way of setting the noteheads. Because
the true duration of the whole construct has already been stated on the
\tuplet x there is no need to validate further, the tuplets total duration
is still whatever they coded it to be at the outset.
Hmm, I think I agree with Rick about the nested braces - that seems to
be more Lilypond-ish than my original suggestion.
OTOH, I don't think the situation with mixed durations is really a problem.
For example,
\tuplet 4 {{ a4 b8 } { c16 b a b8. } { a16 b c b a }}
(using nested brackets, as Rick suggested) should produce a 3 over the
first and second bracket groups, and a 5 over the third, all based on
the ratio of the cumulative duration of the notes within the brackets to
the duration given after \tuplet. (For the first two groups, the ratio
is 3:2, for the third group of notes, 5:4)
I think the digit on the tuplet bracket SHOULD be generated, regardless
of what the notes and durations are within the tuplet. I don't like the
idea that the user could put a number on the bracket that doesn't make
sense musically - if you have a group of five notes in the time of four,
then either a 5 should appear, or the ratio 5:4. The only exception
I can see to this is to be able to suppress the number altogether for
those situations where the pattern of tuplets is repeated through the
piece (e.g. Schubert's Impromptu No. 3, Op. 90). So I don't think a
\tupletNbr function is really necessary. But others may it differently
to me.
My $0.02 (Australian, so worth even less!)
Brett
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Saturday 23 December 2006 03:10, Frédéric Chiasson wrote:
Might it be possible to use
\tuplet 3:2 {x x x}
for the usual operation, and if we want to have many tuplets of the same
kind, to use
\tuplet 3:2 { {x x x} {y y y} {z z z} }
Might resolve the clarity problems.
Doesn't look good to me, syntax becomes unclear for cases like
\tuplet 3:2 { x {y y y } z }
However, it would IMHO be OK to write a separate music function with this
syntax, something like:
\tupletSequence 3:2 {{ x x x} {y y y} {z z z}}
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Monday 25 December 2006 07:05, Joe Neeman wrote: On 12/21/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote: Erik Sandberg escreveu: BTW, in this case it may be good to register the fraction as its own argument type, so \tuplets and \tuplet are generic music functions, both with signature (tuplet-fraction? music?) it would be cool if we could pull this off, that would make \time generic too. Could you make 3:2 equivalent to #'(3 . 2)? Then - you don't need to introduce a new type - we could use x:y everywhere instead of the scary (it certainly was for me when I first started with lilypond) #'(x . y) With the current way the parser works, you'd probably be able to do something like #(ly:export '(x . y)); of course we can add a define-music-function style synonym on top of that, like #(make-fraction x y) BTW, I have some ideas to change the way SCM expressions work in the parser; unfortunately I haven't had the time to code lilypond for a very long time though, and other things are of higher priority. My idea is that the detection of types after ly:export should be carried out by the parser rather than lexer; this would allow a more intuitive behaviour of music macros the day they are implemented (it would be possible to delay the evaluation of inline SCM expressions) -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Monday 25 December 2006 06:32, David Fedoruk wrote:
Hello:
I've been watching this discussion or debate. There are two ways to
look at this problem. The first is from a programmer's point of view
where the programmer is experienced with some computer languages,
these days its upper level languages more and more. For these people,
lilypond typesetting code feels comfortable when it is syntactically
correct and when it makes sense in either computer or mathematical
terms. A mathematical algorithm is what they are used to seeing.
The other group has less mathematical knowledge, very little (very
little compared to a programmer working on a major project like
Lilypond) programming knowledge or experience. In all likelihood the
only thing that connects these people is the printed musical score.
At least in part I think these points have already been made. The
question that occurs to me as a novice Lilypond user (and one who
jumps in the deep end with complex scores!) is this: How will you
deal with other types of prolongation or compression of notes into one
or more beats or where the composers intentions are clear but they are
not immediately mathematically correct?
The example below is a single bar from a Beethoven Piano Sonata (Opus
31 number 3, 1st mvt. bar 53) in which two more out of the ordinary
examples occur next to each other. You will excuse any mistakes in
coding here, this doesn't render as it should.
upper = \relative c'' {
\clef treble
\key ef \major
\time 3
bf16[d f ef] \times 5/4 d16[ ef f g a] bf32[bf a c bf d c bf a g c g ef]
}
You can see how there are three beams, one for the notes in eaech
beat. The first and second beat are quite clear, but the third one has
eluded me as yet. The score has 12 thirty-second notes beamed together
with 12 below the note heads.
The printed score is clear to the performer. The Lilypond code I
suspect is far more complex. The only way that 12 thirty-second notes
will fit into one beat is if they are triplets, but in context, they
are not played or heard as triplets.
My only comment in this discussion is that the Lilypond code to
represent this short passage should be as clear as the printed score I
am reading.
try \times 8/12 { ... }
(by default, this will probably display as 12:8 above the notes, which can be
tweaked to just show 12)
IMHO, this is an argument for a mathematical notation: You must know what you
are doing to notate the music (i.e., multiplying durations with 8/12), just
saying that a 12 should be displayed above would make it difficult to
maintain the .ly code.
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On 12/21/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote: Erik Sandberg escreveu: BTW, in this case it may be good to register the fraction as its own argument type, so \tuplets and \tuplet are generic music functions, both with signature (tuplet-fraction? music?) it would be cool if we could pull this off, that would make \time generic too. Could you make 3:2 equivalent to #'(3 . 2)? Then - you don't need to introduce a new type - we could use x:y everywhere instead of the scary (it certainly was for me when I first started with lilypond) #'(x . y) ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
--- Brett Duncan wrote:
\tuplet 3:2 {c4 c8 c c4}
should be printed as
|- 3 |
__
| | | |
| | | |
X X X X
or as
|- 3 -| |- 3 -|
| |\ |\ |
| | | |
X X X X
If we are going to worry about seperating the music from the typesetting, then
it is worth observing that these two are equivalent musically. It doesn't
matter which way the typesetter chooses as it's default as they are both
valid. If a more advanced user wants to change the default behaviour they can
do so using \setTupletSpanner. The beginner user is going to get something
meaningful and what they had intended musically.
I would propose the default implementation tries to figure it out from the
length of the first note in the tuplet musical expression. It seems there is
president for this approach (although I am to new to remember where I saw
it...). In that case it would probably pick the first example.
Jonathan
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Jonathan Henkelman escreveu:
--- Brett Duncan wrote:
\tuplet 3:2 {c4 c8 c c4}
should be printed as
|- 3 |
__
| | | |
| | | |
X X X X
or as
|- 3 -| |- 3 -|
| |\ |\ |
| | | |
X X X X
If we are going to worry about seperating the music from the typesetting,
then
it is worth observing that these two are equivalent musically. It doesn't
No, they aren't. The stresses fall in different places. In bottom example, the
stress is
on the 2nd 8th note.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Han-Wen Nienhuys hanwen at lilypond.org writes:
Jonathan Henkelman escreveu:
--- Brett Duncan wrote:
\tuplet 3:2 {c4 c8 c c4}
should be printed as
|- 3 |
__
| | | |
| | | |
X X X X
or as
|- 3 -| |- 3 -|
| |\ |\ |
| | | |
X X X X
If we are going to worry about seperating the music from the typesetting,
then
it is worth observing that these two are equivalent musically. It doesn't
No, they aren't. The stresses fall in different places. In bottom example,
the stress is
on the 2nd 8th note.
True enough, but it will also depend on the time signature. However, we still
need to have a default and it seems deciding based on the value of the first
note is as reasonable a guess as any. It can always be overriden by an
experienced user.
Jonathan
PS. Sorry Han-wen for the double mailing - I'm still not totally comfortable
with this archive interface...
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Jonathan Henkelman wrote:
Han-Wen Nienhuys hanwen at lilypond.org writes:
If we are going to worry about seperating the music from the
typesetting,
then
it is worth observing that these two are equivalent musically.
It doesn't
No, they aren't. The stresses fall in different places. In bottom
example,
the stress is
on the 2nd 8th note.
True enough, but it will also depend on the time signature.
However, we still need to have a default and it seems deciding based
on the value of the first note is as reasonable a guess as any. It
can always be overriden by an experienced user.
I respectfully disagree. In a lot of the music you will see rhythms like
|--3--| |--3--|
| |\ | |\
| || |
X XX X
but your suggestion of basing the tuplet span on the first note would
generate
|--3--|
| |\ | |\
| || |
X XX X
which implies a different emphasis. I would not like to see this as a
default.
Han-Wen Nienhuys wrote
\tuplet 6:4 2. { .. } is a lot of numbers. Not very readable IMO.
No argument here - I wasn't advocating a specific syntax, but simply
raising the possibility that the tuplet's span could be an argument of
the function. Otherwise, we're simply turning \times into \tuplet
without really changing anything about its functionality.
My $0.02
Brett
--
Brett Duncan [EMAIL PROTECTED]
opinio tam stulta non est quam philosophus quidam exprimere non possit
(there is no opinion so absurd that some philosopher will not express it)
Marcus Tullius Cicero (106 BC-43 BC)
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Might it be possible to use
\tuplet 3:2 {x x x}
for the usual operation, and if we want to have many tuplets of the same
kind, to use
\tuplet 3:2 { {x x x} {y y y} {z z z} }
Might resolve the clarity problems.
Frédéric
2006/12/22, Han-Wen Nienhuys [EMAIL PROTECTED]:
[EMAIL PROTECTED] escreveu:
Since the duration would be the second of three arguments, it could not
be
optional, but that's not a problem.
I think (?) this would have the side effect that \tuplet 3:2 2. would
be the same as \tuplet 6:4 2. or \tuplet 9:6 2., which would mean
that it would always be OK (even if not required) to express the ratio
in reduced form (3:2 here).
1. We want to cut back on optional constructs
2. \tuplet 6:4 2. { .. } is a lot of numbers. Not very readable IMO.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Frédéric Chiasson wrote:
Might it be possible to use
\tuplet 3:2 {x x x}
for the usual operation, and if we want to have many tuplets of the
same kind, to use
\tuplet 3:2 { {x x x} {y y y} {z z z} }
Might resolve the clarity problems.
That sounds like a great idea! (or some similar syntax).
Paul Scott
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Wednesday 20 December 2006 10:58, Mats Bengtsson wrote:
Graham Percival wrote:
... hmm, what about allowing
\tuplet 3:2 {c8 d e} \tuplet { f e d}
Again, I definitely vote against! We already now have too many
optional constructs in the syntax, which causes more confusion than
it helps.
I also vote against this. AFAIK, this kind of repetition seldom happens for
other cases than 2/3 and 4/6; we can easily build music functions for those
cases (i.e., create a unary function \triplet etc.)
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Wednesday 20 December 2006 07:51, Graham Percival wrote:
Han-Wen Nienhuys wrote:
Jonathan Henkelman escreveu:
I think Eriks point is actually well founded. The discussion started
with my discussion of trying to trim down the grammer complexity. Adding
syntax is not really in that direction.
Another option:
- add \tuplet 3:2 {.. }
- replace \times 2/3 by \times #'(2 . 3) ; this can be implemented with
a standard music function
Oh God no. It took me a year to get used to #'(2 . 3) -- I kept on
trying '#( and #( and #'(2.3)... every time I gave up after ten minutes
and found an example from the documentation to copy.
Scheme has rational numbers as a builtin type, so it _is_ possible to pass the
easy-to-type #2/3 as an argument to a music function (AFAIK, this is the only
case where scheme doesn't use polish notation).
Unfortunately, this would not work with \times: #2/3 and #4/6 are the same
rational number, but 2/3 and 4/6 are different tuplet fractions. Also, Scheme
rational numbers may not contain whitespaces, so #2 / 3 is not the same as
#2/3.
(hm.. for obvious mathematical reasons this solution doesn't work, but if it
WOULD have worked, it would have been a nice solution in a mathematical
sense)
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Tuesday 19 December 2006 15:25, Mats Bengtsson wrote:
Werner LEMBERG wrote:
\tuplet 3:2 {...}
One minor detail is that the name isn't exactly appropriate when you
do
\set tupletSpannerDuration = #(ly:make-moment 1 4)
\times 2/3 {c8 d e f e d e f g f e d }
Well, in that case just stay with \times.
I thought the proposal was to completely get rid of \times and replace it
by \tuplet (which I think is a good idea). Just wanted to see if anybody
had any bright idea on a command name that's accurate also in this
special case.
What about:
\tuplets 2/3 {c8 d e f e d e f g f e d }
We could also make \tuplet and \tuplets differ on the iterator level, so that
the tupletSpannerDuration property affects \tuplets expressions but not
\tuplet expressions.
BTW, in this case it may be good to register the fraction as its own argument
type, so \tuplets and \tuplet are generic music functions, both with
signature
(tuplet-fraction? music?)
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Erik Sandberg wrote:
What about:
\tuplets 2/3 {c8 d e f e d e f g f e d }
We could also make \tuplet and \tuplets differ on the iterator level, so that
the tupletSpannerDuration property affects \tuplets expressions but not
\tuplet expressions.
I think that may just cause more confusion. I vote for the single
command \tuplet
(which occasionally might mean tuplets as well).
BTW, in this case it may be good to register the fraction as its own argument
type, so \tuplets and \tuplet are generic music functions, both with
signature
(tuplet-fraction? music?)
Maybe such an argument type can also be used in functions like
\compressMusic and perhaps also as the value for some properties.
/Mats
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Erik Sandberg escreveu: BTW, in this case it may be good to register the fraction as its own argument type, so \tuplets and \tuplet are generic music functions, both with signature (tuplet-fraction? music?) it would be cool if we could pull this off, that would make \time generic too. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Mats Bengtsson wrote: BTW, in this case it may be good to register the fraction as its own argument type, so \tuplets and \tuplet are generic music functions, both with signature (tuplet-fraction? music?) Maybe such an argument type can also be used in functions like \compressMusic and perhaps also as the value for some properties. At second thought, couldn't we expect problems since as you said in an earlier email, #6/8 is interpreted by Scheme as a rational number, so \tuplet #6/8 wouldn't be the same thing as \tuplet 6/8 (the former would perhaps give a syntax error). /Mats ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Paul Scott: Karl Hammar wrote: ... I support Eriks idea: . it is much easier to write 2 3 instead of 2/3 much?? It's about the same on my keyboard. 2/3 is even easier with the numeric keypad. Well, it depends on which keyboard layout you are using. The swedish one is like shift-7. Regards /Karl Hammar ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Thursday 21 December 2006 12:55, Han-Wen Nienhuys wrote: Erik Sandberg escreveu: BTW, in this case it may be good to register the fraction as its own argument type, so \tuplets and \tuplet are generic music functions, both with signature (tuplet-fraction? music?) it would be cool if we could pull this off, that would make \time generic too. Hm, if we do this together with the 2:3 syntax change, then we would suddenly be able to write: \time 4:3 which would be equivalent to: \time 3/4 That's a bit confusing. BTW, if we start adding new types, it would be nice to create a new 'type' data structure, to be used in function signatures. The data structure would contain a type-checking predicate, a name (displayed when type-check fails), and perhaps a type ID for the lexer. This would allow more complex types, e.g. 'sequential music', 'single note or chord', 'pair of numbers' (as in #'(1 . 3)), etc; perhaps the system could be used for define-context-properties.scm as well. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Erik Sandberg escreveu: On Thursday 21 December 2006 12:55, Han-Wen Nienhuys wrote: Erik Sandberg escreveu: BTW, in this case it may be good to register the fraction as its own argument type, so \tuplets and \tuplet are generic music functions, both with signature (tuplet-fraction? music?) it would be cool if we could pull this off, that would make \time generic too. Hm, if we do this together with the 2:3 syntax change, then we would suddenly be able to write: \time 4:3 which would be equivalent to: \time 3/4 That's a bit confusing. BTW, if we start adding new types, it would be nice to create a new 'type' data structure, to be used in function signatures. The data structure would contain a type-checking predicate, a name (displayed when type-check fails), and perhaps a type ID for the lexer. This would allow more complex types, e.g. 'sequential music', 'single note or chord', 'pair of numbers' (as in #'(1 . 3)), etc; perhaps the system could be used for define-context-properties.scm as well. be careful. If you introduce type, you will have to introduce subtypes as well: seq-music is a subtype of music. Before you know, we'll be writing a type inference engine. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Stephen Kress wrote:
4. By default, a single number will be engraved in the tuplet bracket.
There is already the text property of the TupletNumber object that can be
tweaked to get the ratio printed if one so desires. In other words, no
changes need to be made to LP in how the single number vs. ratio engraving is
done; LP already does it right.
How exactly will this work. \times 2/3 {c8 d e f g a} does not produce the
output _I_ would expect, which is two standard triplets. Instead it produces
two triplets with a single spanner with the text '3' in it. Do we want to
work on this default notation at the same time?
J
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Jonathan Henkelman wrote:
How exactly will this work. \times 2/3 {c8 d e f g a} does not produce the
output _I_ would expect, which is two standard triplets. Instead it produces
two triplets with a single spanner with the text '3' in it. Do we want to
work on this default notation at the same time?
That's an example where you need to set the tupletSpannerDuration property:
\set tupletSpannerDuration = #(ly:make-moment 1 4)
\times 2/3 {c8 d e f g a}
/Mats
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Thursday 21 December 2006 15:01, Han-Wen Nienhuys wrote:
Erik Sandberg escreveu:
On Thursday 21 December 2006 12:55, Han-Wen Nienhuys wrote:
Erik Sandberg escreveu:
BTW, in this case it may be good to register the fraction as its own
argument type, so \tuplets and \tuplet are generic music functions,
both with signature
(tuplet-fraction? music?)
it would be cool if we could pull this off, that would make \time
generic too.
Hm, if we do this together with the 2:3 syntax change, then we would
suddenly be able to write:
\time 4:3
which would be equivalent to:
\time 3/4
That's a bit confusing.
BTW, if we start adding new types, it would be nice to create a new
'type' data structure, to be used in function signatures. The data
structure would contain a type-checking predicate, a name (displayed when
type-check fails), and perhaps a type ID for the lexer. This would allow
more complex types, e.g. 'sequential music', 'single note or chord',
'pair of numbers' (as in #'(1 . 3)), etc; perhaps the system could be
used for
define-context-properties.scm as well.
be careful. If you introduce type, you will have to introduce subtypes as
well: seq-music is a subtype of music. Before you know, we'll be writing a
type inference engine.
I don't understand. Why isn't is sufficient to let typechecking be carried out
by an arbitrary user-defined turing-complete function? music and seq-music
don't need to share any code, the type inference engine machinery would be
voluntary AFAICS (seq-music's predicate would check that the object is a
Music and that it's of type SequentialMusic, and seq-music's name would
be sequential music).
And when it comes to parser, seq-music can just tell it that it expects a
Music, and typecheck after parsing. Alternatively, we create an independent
rule for seq-music which only accepts stuff on the form { }. This rule will
exist independently of the generic Music rule.
Or did I miss something?
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Frédéric Chiasson wrote:
But to avoid repeating \tuplet functions for long passages with the
same tuplets, we could admit that kind of syntax :
\tuplet 3:2 {c8 d e f g a b c d e d c b a g f e d}
without having one long bracket going through all the notes. But I
understand that you don't want to change that for programming issues.
It is not possible to determine whether long tuplets should be
splitted or not; how then would you determine whether
\tuplet 3:2 {c4 c8 c c4}
should be printed as
|- 3 |
__
| | | |
| | | |
X X X X
or as
|- 3 -| |- 3 -|
| |\ |\ |
| | | |
X X X X
?
In your example,
\set tupletSpannerDuration = #(ly:make-moment 1 4)
can already save from typing \tuplet (\times today) a lot of times.
Cheers,
--
John Mandereau [EMAIL PROTECTED]
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Mats Bengtsson mats.bengtsson at ee.kth.se writes:
Jonathan Henkelman wrote:
How exactly will this work. \times 2/3 {c8 d e f g a} does not produce
the
output _I_ would expect, which is two standard triplets. Instead it
produces
two triplets with a single spanner with the text '3' in it. Do we want to
work on this default notation at the same time?
That's an example where you need to set the tupletSpannerDuration property:
\set tupletSpannerDuration = #(ly:make-moment 1 4)
\times 2/3 {c8 d e f g a}
/Mats
I understand from the manual and the archives that \set tupletSpanner... etc.
will do what I am expecting, but in the interest of making the language more
intuitive, esp. for new users, it is worth considering having the default
behaviour as follows:
\tuplet 3:2 {c8 d e f g a} yielding:
__3__ __3__
| | | | | |
| | | | | |
X X X X X X
which is what I would expect from an instruction told to parse a musical
stream such that 3 notes take the space of two. Instead, what I do get is
rather meaningless:
+---3---+
_ _
| | | | | |
| | | | | |
X X X X X X
It means a new user has to set an internal variable to get the behaviour they
expect. It would make more sense to have an experienced user, who might want
the latter, setting the internal variable to get the more unusal behaviour.
Jonathan
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Yes, that makes sense.
Frédéric
2006/12/21, John Mandereau [EMAIL PROTECTED]:
Frédéric Chiasson wrote:
But to avoid repeating \tuplet functions for long passages with the
same tuplets, we could admit that kind of syntax :
\tuplet 3:2 {c8 d e f g a b c d e d c b a g f e d}
without having one long bracket going through all the notes. But I
understand that you don't want to change that for programming issues.
It is not possible to determine whether long tuplets should be
splitted or not; how then would you determine whether
\tuplet 3:2 {c4 c8 c c4}
should be printed as
|- 3 |
__
| | | |
| | | |
X X X X
or as
|- 3 -| |- 3 -|
| |\ |\ |
| | | |
X X X X
?
In your example,
\set tupletSpannerDuration = #(ly:make-moment 1 4)
can already save from typing \tuplet (\times today) a lot of times.
Cheers,
--
John Mandereau [EMAIL PROTECTED]
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On 12/20/06, Kress, Stephen [EMAIL PROTECTED] wrote:
Ok. Based on what everyone has been saying and seeming to come to an
agreement on, here's the details of the changes that we are proposing be
made.
1. \times is replaced by \tuplet since tuplet makes more musical sense and
convert-ly can easily be updated to make the change. Because of convert-ly,
there's not a real reason (other than the status quo people are used to) to
keep \times around.
2. The first argument to \tuplet may be either a ratio (more
understandable to musicians) or a division (as is currently supported). The
punctuation between the two numbers marks what it is. A single number will
not be supported.
3. The second argument remains an arbitrary musical expression. There is
no reason to force the expression to contain only the proper duration of
notes since LP is already built to engrave this situation properly.
4. By default, a single number will be engraved in the tuplet bracket.
There is already the text property of the TupletNumber object that can be
tweaked to get the ratio printed if one so desires. In other words, no
changes need to be made to LP in how the single number vs. ratio engraving
is done; LP already does it right.
The first three of these suggestions make great sense.
But could we please change #4?
Note that, today, the expression
\times 3/5 { c'16 c'16 c'16 c'16 c'16 }
prints with a lone 5 above the backet. A lone 5 is interpreted as an
abbreviation of 5:4 and not as 5:3. This means that hte output is
not merely typographically incorrect but musically incorrect.
(The solution in the current implementations of the program is to
override TupletNumber to a fraction, which definitely does work.
However, this means that we have a rare example of a case where Lily's
default behavior is actually musically incorrect.)
If we're going to change tuplet input and rendering behavior, I think
a better version of #4 might be something like print, by default, a
lone integer over the bracket, except where a lone integer is
musically incorrect, in which case print the ratio over the bracket.
See http://lists.gnu.org/archive/html/lilypond-user/2006-11/msg00514.html
--
Trevor Bača
[EMAIL PROTECTED]
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
I have enclosed two messages which I think are getting at the same problem in
different ways. Regardless of \tuplet vs. \times and the associated programming
discussion, I think the fact that Lily's default is to print nonsense in this
kind of case, should be thought of as a bug.
Jonathan Henkelman wrote:
I understand from the manual and the archives that \set tupletSpanner... etc.
will do what I am expecting, but in the interest of making the language more
intuitive, esp. for new users, it is worth considering having the default
behaviour as follows:
\tuplet 3:2 {c8 d e f g a} yielding:
__3__ __3__
| | | | | |
| | | | | |
X X X X X X
which is what I would expect from an instruction told to parse a musical
stream such that 3 notes take the space of two. Instead, what I do get is
rather meaningless:
+---3---+
_ _
| | | | | |
| | | | | |
X X X X X X
It means a new user has to set an internal variable to get the behaviour they
expect. It would make more sense to have an experienced user, who might want
the latter, setting the internal variable to get the more unusal behaviour.
and Trevor Bacˇa wrote:
On 12/20/06, Kress, Stephen [EMAIL PROTECTED] wrote:
Ok. Based on what everyone has been saying and seeming to come to an
agreement on, here's the details of the changes that we are proposing
be
made.
1. \times is replaced by \tuplet since tuplet makes more musical
sense and
convert-ly can easily be updated to make the change. Because of
convert-ly,
there's not a real reason (other than the status quo people are used
to) to
keep \times around.
2. The first argument to \tuplet may be either a ratio (more
understandable to musicians) or a division (as is currently
supported). The
punctuation between the two numbers marks what it is. A single number
will
not be supported.
3. The second argument remains an arbitrary musical expression.
There is
no reason to force the expression to contain only the proper
duration of
notes since LP is already built to engrave this situation properly.
4. By default, a single number will be engraved in the tuplet
bracket.
There is already the text property of the TupletNumber object that can
be
tweaked to get the ratio printed if one so desires. In other words,
no
changes need to be made to LP in how the single number vs. ratio
engraving
is done; LP already does it right.
The first three of these suggestions make great sense.
But could we please change #4?
Note that, today, the expression
\times 3/5 { c'16 c'16 c'16 c'16 c'16 }
prints with a lone 5 above the backet. A lone 5 is interpreted as an
abbreviation of 5:4 and not as 5:3. This means that hte output is
not merely typographically incorrect but musically incorrect.
(The solution in the current implementations of the program is to
override TupletNumber to a fraction, which definitely does work.
However, this means that we have a rare example of a case where Lily's
default behavior is actually musically incorrect.)
If we're going to change tuplet input and rendering behavior, I think
a better version of #4 might be something like print, by default, a
lone integer over the bracket, except where a lone integer is
musically incorrect, in which case print the ratio over the bracket.
See
http://lists.gnu.org/archive/html/lilypond-user/2006-11/msg00514.html
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
John Mandereau wrote:
Frédéric Chiasson wrote:
But to avoid repeating \tuplet functions for long passages with the
same tuplets, we could admit that kind of syntax :
\tuplet 3:2 {c8 d e f g a b c d e d c b a g f e d}
without having one long bracket going through all the notes. But I
understand that you don't want to change that for programming issues.
It is not possible to determine whether long tuplets should be
splitted or not; how then would you determine whether
\tuplet 3:2 {c4 c8 c c4}
should be printed as
|- 3 |
__
| | | |
| | | |
X X X X
or as
|- 3 -| |- 3 -|
| |\ |\ |
| | | |
X X X X
?
In your example,
\set tupletSpannerDuration = #(ly:make-moment 1 4)
can already save from typing \tuplet (\times today) a lot of times.
Cheers,
Yes, I was wondering about this too. It seems to me that either you
still need to have \set tupletSpannerDuration or you need to build the
tuplet duration into the tuplet function itself, e.g. \tuplet 3:2 2. {c
c8 c c4} for John's first example, and \tuplet 3:2 4. {c4 c8 c c4} for
the second. But then this is probably making \tuplet a little more
complicated than people would like. (unless maybe the duration value is
optional and can be omitted?)
Just a thought.
Brett
--
Brett Duncan
[EMAIL PROTECTED]
opinio tam stulta non est quam philosophus quidam exprimere non possit
(there is no opinion so absurd that some philosopher will not express it)
Marcus Tullius Cicero (106 BC-43 BC)
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Werner LEMBERG wrote:
(1) If you reduce this to a single keyword, then don't allow the
bare argument 3: \times 3 looks like \times 3/1 to me; so of
course, I'm a dodo, but I predict that Mats Erik several others
would wind up spending a lot of time explaining what \times 7 (or
\tuplet 7) means.
Indeed, `\times 3' is problematic, but `\tuplet 3' sounds clear to me.
Additionally, I suggest that `\tuplet 3' prints the `3' above the
group, while `\tuplet 3:2' prints `3:2' (which some composers prefer).
You *could* keep \times and *add* the keyword \tuplet with the
syntax \tuplet m:n {sequence-of-notes},
Actually, I would prefer this too.
Yes! \times is shorter than \tuplet to type.
Paul Scott
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Paul Scott wrote:
Werner LEMBERG wrote:
Indeed, `\times 3' is problematic, but `\tuplet 3' sounds clear to me.
Additionally, I suggest that `\tuplet 3' prints the `3' above the
group, while `\tuplet 3:2' prints `3:2' (which some composers prefer).
You *could* keep \times and *add* the keyword \tuplet with the
syntax \tuplet m:n {sequence-of-notes},
Actually, I would prefer this too.
Yes! \times is shorter than \tuplet to type.
You're joking, right? It's one letter -- and it really _is_ a letter,
not one of those silly ()# characters that require the use of the shift key.
Although I like the idea of accepting both \tuplet 3:2 and \tuplet 2/3,
I don't like the notion of having \tuplet and \times. I suppose we
could keep \times as an old command and remove it from the manual to
avoid confusion... but that seems silly. Either eliminate \times, or
don't bother introducing \tuplet.
Cheers,
- Graham
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Please don't add redundant constructs, that will just cause the confusion.
If we introduce \tuplet, then we should definitely remove \times, just as
Graham said.
Werner LEMBERG wrote:
Indeed, `\times 3' is problematic, but `\tuplet 3' sounds clear to me.
Additionally, I suggest that `\tuplet 3' prints the `3' above the
group, while `\tuplet 3:2' prints `3:2' (which some composers prefer).
This would break the separation between music semantics and typesetting
layout.
We used to have such features in very early versions of LilyPond, where it
was possible to say both \time C and \time 4/4, where both denoted common
time but one was typeset as C and the other as 4/4.
Please, please let's continue to use property settings to determine the
printed layout
and use the input syntax only for representing the musical meaning,
otherwise
we will get a completely confusing syntax.
Regarding the very minor issue I brought up when using
tupletSpannerDuration,
it's just a matter of clarifying in the documentation that \tuplet
actually can be
used also for multiple tuplets.
Graham Percival wrote:
... hmm, what about allowing
\tuplet 3:2 {c8 d e} \tuplet { f e d}
Again, I definitely vote against! We already now have too many
optional constructs in the syntax, which causes more confusion than
it helps.
I agree that the scores that take most time to type in are those that have
repeated rhythms like
\times 2/3 {c c c } c4 \times 2/3 {c c c } c4
or
c8 c16 c c4 c8 c16 c c4
especially if these are combined with slurs. It is certainly possible to
implement your
own music function that applies a specific rhyhtmic pattern to a set of
pitches.
However, this if fairly clumsy to do for the moment. I'm sure that some
clever
Scheme hacker can come up with some solution like
mypattern = #(make-rhythmization #{ c8 c16 c16 c4 #})
so that
\mypattern {c d e f }
results in
c8 d16 e16 f4
Of course, it would be even better if the function also could produce
the \pat
function in input/test/music-box.ly, i.e. where some of the pitches are
repeated
in the rhythmic pattern.
/Mats
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Wed, 20 Dec 2006 [EMAIL PROTECTED] wrote:
(2) \times 2/3 and \tuplet 3:2 don't mean the same thing:
\times 2/3 {c8 d e d e f}
makes sense, but I don't think that
\tuplet 3:2 {c8 d e d e f}
does. The least messy option would be the status quo. The keyword
\times is perfectly clear. You *could* keep \times and *add* the keyword
\tuplet with the syntax \tuplet m:n {sequence-of-notes}, but then
when the \tuplet expression is parsed, checks should be performed that
would accept
\tuplet 3:2 {c8 d e}
I definitely agree that \times x/y is the least messy option.
I use Lilypond since 1.4.12 (yes, that's a long time ago and, yes, I
suffered with the syntax change of brackets and slurs, among many other
- but it has been worthwhile) Since I started to learn Lilypond, I
thought \times one of the most clear and elegant parts of Lilypond,
concerning the x/y.
The very few times I confused it with \time - usually a typing error -
it was always one of those easy to find and fix problems.
I hope that this (\times x/y) does not change, but if it does, well, I
will live with it also
Thanks to all for Lilypond and for the user- and devel- lists
Best regards,
Luise
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Karl Hammar wrote:
Werner:
Erik:
I think these changes sound scary, it is an additional hack in the
parser machinery.
...
I think it would be cleaner if \times could be changed to a
proper music function, e.g. as
\tuplet 2 3 {...}
This would remove rules from the parser instead of adding them.
You are thinking too mathematically IMHO.
I support Eriks idea:
. it is much easier to write 2 3 instead of 2/3
much?? It's about the same on my keyboard. 2/3 is even easier with the
numeric keypad.
Paul Scott
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
« Although I like the idea of accepting both \tuplet 3:2 and \tuplet 2/3,
I don't like the notion of having \tuplet and \times. I suppose we
could keep \times as an old command and remove it from the manual to
avoid confusion... but that seems silly. Either eliminate \times, or
don't bother introducing \tuplet.
Cheers,
- Graham
»
I agree totally to that Graham. Also, the advanced users can make the
semantic differences between the real meaning of tuplet and the effect
produced with #setTupletSpannerDuration or whatever.
Indeed, `\times 3' is problematic, but `\tuplet 3' sounds clear to me.
Additionally, I suggest that `\tuplet 3' prints the `3' above the
group, while `\tuplet 3:2' prints `3:2' (which some composers prefer).
You *could* keep \times and *add* the keyword \tuplet with the
syntax \tuplet m:n {sequence-of-notes},
Actually, I would prefer this too.
Yes! \times is shorter than \tuplet to type.
Wow, you are that slow at typing? :))
Seriously, the problem to change \times for \tuplet is to break an habit for
many users. But since LilyPond has changed a lot since its beginnings and
convert-ly can easily make the conversion, why not!
But I'm not keen to admit typing \tuplet 3 to have a 3 over the notes and
\tuplet 3:2 to have 3:2. What about wanting a 7:8 but only print 7 when
the standard for 7 is 7:4? Also, that situation would surely add a lot of
code! That would also happen for using only \tuplet without arguments.
But to avoid repeating \tuplet functions for long passages with the same
tuplets, we could admit that kind of syntax :
\tuplet 3:2 {c8 d e f g a b c d e d c b a g f e d}
without having one long bracket going through all the notes. But I
understand that you don't want to change that for programming issues.
Better keep 3:2 and 2/3. And if you want a function for triplets, just type
triplet = \tuplet 3:2 and it's done.
And I definitely don't want \times #'(2 . 3) This pseudo-Scheme syntax is
very hard to understand for the beginner, especially the ' ! The least
Scheme syntax necessary, the better!
Greetings,
Frédéric
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
RE: Constructive Criticism and a Question
Ok. Based on what everyone has been saying and seeming to come to an agreement on, here's the details of the changes that we are proposing be made. 1. \times is replaced by \tuplet since tuplet makes more musical sense and convert-ly can easily be updated to make the change. Because of convert-ly, there's not a real reason (other than the status quo people are used to) to keep \times around. 2. The first argument to \tuplet may be either a ratio (more understandable to musicians) or a division (as is currently supported). The punctuation between the two numbers marks what it is. A single number will not be supported. 3. The second argument remains an arbitrary musical expression. There is no reason to force the expression to contain only the proper duration of notes since LP is already built to engrave this situation properly. 4. By default, a single number will be engraved in the tuplet bracket. There is already the text property of the TupletNumber object that can be tweaked to get the ratio printed if one so desires. In other words, no changes need to be made to LP in how the single number vs. ratio engraving is done; LP already does it right. That's all we seem to be talking about. A minor syntactic change that adds clarity and flexibility without making anything (except maybe the parser) more complicated. I think this captures the consensus of the discussion. If we're agreed, we can find out what the price tag will be... Stephen 2006-12-20, 15:33:08 The information contained in this e-mail message and any attachments may be privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to this e-mail and delete the message and any attachments from your computer.___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Good! Frédéric 2006/12/20, Kress, Stephen [EMAIL PROTECTED]: Ok. Based on what everyone has been saying and seeming to come to an agreement on, here's the details of the changes that we are proposing be made. 1. \times is replaced by \tuplet since tuplet makes more musical sense and convert-ly can easily be updated to make the change. Because of convert-ly, there's not a real reason (other than the status quo people are used to) to keep \times around. 2. The first argument to \tuplet may be either a ratio (more understandable to musicians) or a division (as is currently supported). The punctuation between the two numbers marks what it is. A single number will not be supported. 3. The second argument remains an arbitrary musical expression. There is no reason to force the expression to contain only the proper duration of notes since LP is already built to engrave this situation properly. 4. By default, a single number will be engraved in the tuplet bracket. There is already the text property of the TupletNumber object that can be tweaked to get the ratio printed if one so desires. In other words, no changes need to be made to LP in how the single number vs. ratio engraving is done; LP already does it right. That's all we seem to be talking about. A minor syntactic change that adds clarity and flexibility without making anything (except maybe the parser) more complicated. I think this captures the consensus of the discussion. If we're agreed, we can find out what the price tag will be... Stephen 2006-12-20, 15:33:08 The information contained in this e-mail message and any attachments may be privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to this e-mail and delete the message and any attachments from your computer. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tuplets (was Re: Constructive Criticism and a Question)
And I definitely don't want \times #'(2 . 3) This pseudo-Scheme syntax is very hard to understand for the beginner, especially the ' ! The least Scheme syntax necessary, the better! I agree! Tim Reeves___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On the contrary, I think making mathematical sense serves a very
practical purpose: it is more consistent with the non-tuplet method
of scaling duration and it is (at least for me) easier to remember.
Mhmm.
In LilyPond, if I want to print a half note but I only want it to
use the duration of a quarter note, I use c2*1/2. [...]
Well, this is not the same as having a tuplet... And I fully agree
that this is the right notation here.
I suppose you could add the command \times 3:2 {a b c} to do exactly
the same as \times 2/3 {a b c} [...]
If at all, then
\tuplet 3:2 {...}
which should be the same as
\tuplet 3 {...}
And of course it would be nice to make this particular case identical
to
\triplet {...}
but I thought that this thread was about _reducing_ the number of
redundant constructs.
Well, I don't consider this a real redundancy. Compare this to, say,
the unit `Hertz' (Hz) which is `redundant' because it's just `per
second' (s ^ -1). In spite of this, nobody would use Gs^-1 instead of
GHz.
A tuplet notation is really not comparable to making a note longer or
shorter.
I think that having two ways to do tuplets (that are exactly the
same except for taking the reciprocal of the fraction) is a recipe
for confusion.
I disagree. I regularly confuse \times with \time -- it's really a
bad idea IMHO to have two such important commands with almost
identical names.
My personal favour would be the introduction of `\tuplet' as described
above.
By the way, if you really want to use 3/2 instead of 2/3, I'm sure it's
possible to whip up a scheme function.
Werner
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Werner LEMBERG wrote:
If at all, then
\tuplet 3:2 {...}
One minor detail is that the name isn't exactly appropriate when you do
\set tupletSpannerDuration = #(ly:make-moment 1 4)
\times 2/3 {c8 d e f e d e f g f e d }
/Mats
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Werner LEMBERG escreveu:
I suppose you could add the command \times 3:2 {a b c} to do exactly
the same as \times 2/3 {a b c} [...]
If at all, then
\tuplet 3:2 {...}
I don't mind changing \times to \tuplet, and agree that the confusion with
\time is a bad thing. We could make \tuplet accept 3:2 2/3 and 3.
Since it is a change that can be accomodated with convert-ly, we wouldn't even
need a major version bump for it.
This should be a rather trivial change, so once we have consensus on the list
I would welcome a patch. It should include
- convert-ly and
- changes for all .ly's
- updates of the manual.
which should be the same as
\tuplet 3 {...}
And of course it would be nice to make this particular case identical
to
\triplet {...}
the latter can be achieved with a music function.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
\tuplet 3:2 {...}
One minor detail is that the name isn't exactly appropriate when you
do
\set tupletSpannerDuration = #(ly:make-moment 1 4)
\times 2/3 {c8 d e f e d e f g f e d }
Well, in that case just stay with \times.
Werner
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Tue 19 December 2006 10:57, Han-Wen Nienhuys wrote: This should be a rather trivial change, so once we have consensus on the list I consent. I don't mind the current syntax, but \tuplet is definitely more clear than \times. Eyolf -- It is Mr. Mellon's credo that $200,000,000 can do no wrong. Our offense consists in doubting it. -- Justice Robert H. Jackson ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Han-Wen Nienhuys wrote:
Werner LEMBERG escreveu:
I suppose you could add the command \times 3:2 {a b c} to do exactly
the same as \times 2/3 {a b c} [...]
If at all, then
\tuplet 3:2 {...}
I don't mind changing \times to \tuplet, and agree that the confusion with
\time is a bad thing. We could make \tuplet accept 3:2 2/3 and 3.
Is it relevant that ':' and '/' actually both mean divide?
Paul Scott
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Paul Scott wrote: Is it relevant that ':' and '/' actually both mean divide? In music, an expression like 3:2 has a specific, universally-agreed-upon meaning. Therefore, IMO, a broader mathematical meaning is not really important in this context. David ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Well, in that case just stay with \times. I thought the proposal was to completely get rid of \times and replace it by \tuplet (which I think is a good idea). Just wanted to see if anybody had any bright idea on a command name that's accurate also in this special case. Han-Wen says that it's no problem to make \tuplet accept both X/Y and Y:X, so I withdraw the above remark. Werner ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Tuesday 19 December 2006 10:57, Han-Wen Nienhuys wrote:
Werner LEMBERG escreveu:
I suppose you could add the command \times 3:2 {a b c} to do exactly
the same as \times 2/3 {a b c} [...]
If at all, then
\tuplet 3:2 {...}
I don't mind changing \times to \tuplet, and agree that the confusion with
\time is a bad thing. We could make \tuplet accept 3:2 2/3 and 3.
Since it is a change that can be accomodated with convert-ly, we wouldn't
even need a major version bump for it.
I think these changes sound scary, it is an additional hack in the parser
machinery. I think it would be cleaner if \times could be changed to a proper
music function, e.g. as
\tuplet 2 3 {...}
This would remove rules from the parser instead of adding them.
(Hm, my suggestion is not really in line with this discussion; I can agree
that \tuplet 2 3 would be easier to confuse with 3:2 than \tuplet 2/3 is).
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Might be an idea, but why should we keep two functions making the same
function?
Does it cost that much on functionality to use two differents syntax in the
same function?
Frédéric
2006/12/19, Han-Wen Nienhuys [EMAIL PROTECTED]:
Jonathan Henkelman escreveu:
Erik Sandberg mandolaerik at gmail.com writes:
I think these changes sound scary, it is an additional hack in the
parser
machinery. I think it would be cleaner if \times could be changed to a
proper
music function, e.g. as
\tuplet 2 3 {...}
This would remove rules from the parser instead of adding them.
(Hm, my suggestion is not really in line with this discussion; I can
agree
that \tuplet 2 3 would be easier to confuse with 3:2 than \tuplet 2/3
is).
I think Eriks point is actually well founded. The discussion started
with my
discussion of trying to trim down the grammer complexity. Adding syntax
is not
really in that direction.
That being said, \tuplet 2 3 {...} is rather confusing. I can live with
Another option:
- add \tuplet 3:2 {.. }
- replace \times 2/3 by \times #'(2 . 3) ; this can be implemented with
a standard music function
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
I think these changes sound scary, it is an additional hack in the
parser machinery.
Why do you think so? Sometimes syntactic sugar is essential to make
certain situations more comprehensible. Just think of TeX's `=' mark
in things like
\count\foo=1
which can be omitted.
I think it would be cleaner if \times could be changed to a
proper music function, e.g. as
\tuplet 2 3 {...}
This would remove rules from the parser instead of adding them.
You are thinking too mathematically IMHO.
Werner
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
I don't mind changing \times to \tuplet, and agree that the confusion
with \time is a bad thing. We could make \tuplet accept 3:2 2/3 and 3.
Opinion --
(1) If you reduce this to a single keyword, then don't allow the bare
argument 3: \times 3 looks like \times 3/1 to me; so of course, I'm a
dodo, but I predict that Mats Erik several others would wind up
spending a lot of time explaining what \times 7 (or \tuplet 7) means.
(2) \times 2/3 and \tuplet 3:2 don't mean the same thing:
\times 2/3 {c8 d e d e f}
makes sense, but I don't think that
\tuplet 3:2 {c8 d e d e f}
does. The least messy option would be the status quo. The keyword
\times is perfectly clear. You *could* keep \times and *add* the keyword
\tuplet with the syntax \tuplet m:n {sequence-of-notes}, but then
when the \tuplet expression is parsed, checks should be performed that
would accept
\tuplet 3:2 {c8 d e}
and probably accept
\tuplet 3:2 {g4 b8}
but would reject
\tuplet 3:2 {c8 d e d e f}
You would be opening up a big can of worms by adding a *genuine*
\tuplet construct.
-- Tom
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Han-Wen Nienhuys wrote:
Jonathan Henkelman escreveu:
I think Eriks point is actually well founded. The discussion started with my
discussion of trying to trim down the grammer complexity. Adding syntax is not
really in that direction.
Another option:
- add \tuplet 3:2 {.. }
- replace \times 2/3 by \times #'(2 . 3) ; this can be implemented with
a standard music function
Oh God no. It took me a year to get used to #'(2 . 3) -- I kept on
trying '#( and #( and #'(2.3)... every time I gave up after ten minutes
and found an example from the documentation to copy.
I'm with Werner here -- I don't see grammar complexity as a problem. I
enthusiastically support
\tuplet 3:2 { }
\tuplet 2/3 { }
meaning the same thing. I'm not convinced that
\triplet { }
is worth having, though. The advantage of \triplet{} over \tuplet X:/Y
isn't clear to me.
As long as we only introduce one of them (probably 3:2) in the tutorial,
I don't see it being a problem for new users.
Cheers,
- Graham
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Mats Bengtsson wrote:
Werner LEMBERG wrote:
\tuplet 3:2 {...}
One minor detail is that the name isn't exactly appropriate when you
do
\set tupletSpannerDuration = #(ly:make-moment 1 4)
\times 2/3 {c8 d e f e d e f g f e d }
I thought the proposal was to completely get rid of \times and replace it
by \tuplet (which I think is a good idea). Just wanted to see if anybody
had any bright idea on a command name that's accurate also in this
special case.
I have a bright idea: it's a special case. New users will be encouraged
to write
\tuplet 3:2 {c8 d e} \tuplet 3:2 { f e d} \tuplet 3:2 {e f g} \tuplet
3:2 { f e d}
(that's what I do all the time anyway)
Advanced users who read the program reference to discover the
tupletSpannerduration can deal with the extra complexity. :)
... hmm, what about allowing
\tuplet 3:2 {c8 d e} \tuplet { f e d}
i.e. as well as remembering the duration 8, remember the value of \tuplet.
Cheers,
- Graham
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
(1) If you reduce this to a single keyword, then don't allow the
bare argument 3: \times 3 looks like \times 3/1 to me; so of
course, I'm a dodo, but I predict that Mats Erik several others
would wind up spending a lot of time explaining what \times 7 (or
\tuplet 7) means.
Indeed, `\times 3' is problematic, but `\tuplet 3' sounds clear to me.
Additionally, I suggest that `\tuplet 3' prints the `3' above the
group, while `\tuplet 3:2' prints `3:2' (which some composers prefer).
You *could* keep \times and *add* the keyword \tuplet with the
syntax \tuplet m:n {sequence-of-notes},
Actually, I would prefer this too.
but then when the \tuplet expression is parsed, checks should be
performed that would accept
\tuplet 3:2 {c8 d e}
and probably accept
\tuplet 3:2 {g4 b8}
but would reject
\tuplet 3:2 {c8 d e d e f}
Why that?
You would be opening up a big can of worms by adding a *genuine*
\tuplet construct.
Which one? I can't see a problem here. Particularly, it's quite
annoying to write
\tuplet 3 { c8 c c } \tuplet 3 { c c c } ...
over and over again for longer sequences consisting of triplets.
Werner
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Graham Percival gpermus at gmail.com writes: Jonathan Henkelman wrote: In terms of making it easier, I don't know if it would be straight forward or not, but if the PDF version of the manual had chapter numbers in the table on contents that showed on the bookmark pane (to the left) it would make it much easier to bounce around and find one's way back again. I'm sure that this can be done by adding a few words to some part of the doc and/or makefiles; the problem is simply finding the right place and figuring out the words. I'll look into this. Thanks much. Is there a copy of the so called programmers documentation in a suitable format to download i.e. PDF (I know it would be long) or a few large HTML files, or an archive (tarball - whatever) of the current HTML documentation. I was hoping to do a bit more work on this over the break, but will have very limited web access... There _is_ a documentation tarball, but I'm not certain if it includes the program reference. I have downloaded the tarball and it had the internals, but the links are broken apparently because the file extensions are not explicitly in the links. I am running IE 6.0. on Win XP. Perhaps it is a configuration problem in IE on my part. Some type of doc. that oulined the lexical construction of Lilypond would be helpful. I am not used to the level on confusion I am experiencing now, when learning a language. As with all open-source projects, documentation depends on interested people writing material. I don't have the time to pursue such a project, but if you (or somebody else) wrote this material, I'd be more than happy to add it to the manual. Ay - I hear you there. I have been considering taking on this project, and I still need to figure out if I have time before I get myself in over my head and unable to keep up with the commitment others might have made to me. A couple of questions I have been pondering in this regard: 1) Since I am fairly new to Lilypond, are there folks out there that would be willing to aid me in the likely event of confusion (I assume this group will do). 2) If/when inconsistencies in the language turn up - as I'm sure they will - is there an interest amoung the programmers to correct these? 3) A complaint I have seen both commonly on this archive and also on the todo list of the co-ordinators for lilypond, is to try and make the learning curve a bit less steep. One logical outcome of a document of this type is that it can be used to clean up the language - i.e. fulfilling this last goal. Is there any interest on the part of the programmers/organizers to undertake this task should I ever get this doc completed. I envision a process whereby the basic notation of lilypond stays the same (obviously), but: - perhaps some command forms would be dropped, - perhaps users would be forced into less freedom in the syntax - perhaps come commands would be morphed to fit into a framework that more closely matches other commands. - any changes would idealy be changeable in input scripts using some sed/diff routines to update routines would be automated (no point in unnecessarily agravating the end user) Some examples: As I can see it now, there are numerous ways to create contexts. In fact if I understand correctly, most commands create contexts. One example I saw in the archive explicly used the context command in all (most?) of these cases. Perhaps either forcing the use of context everywhere a context is being created, or eliminating its use altogether as it is basically implied everywhere would be helpful I have been banging my head against the \combineparts routine. Mats suggested a different form using polyphonic notation which does the task just as nicely. \combineParts does not (to my naive eyes seem to fit the same form as the other commands (e.g. \new Staff, \new Voice etc.) Differences such as this make the learning curve steeper. I think in the end Lilypond would be a cleaner language, but as always happens when trying to eliminate legacy code there is always someones toes being stepped on... What do people think about this... [snip established and reported error] Finally, is the web interface for posting to this archive the most straight forward method? I tried posting this yesterday, but it got lost in the ether. Is there perhaps an email address I can send the post to, where it will get sent back for validation etc. I believe the email address is at the bottom of every message on the list: lilypond-user at gnu.org Not on my web based threaded client (Loom?). I feel like such a newbie, but I can't find it on the FAQ or anywhere else... I can post to gmane.test, but how would I post to followup without using the web interface (i.e. to avoid the top-post checking in cases when I am not actually top-posting...) Thanks, Jonathan
Re: Constructive Criticism and a Question
Jonathan Henkelman wrote: Ay - I hear you there. I have been considering taking on this project, and I still need to figure out if I have time before I get myself in over my head and unable to keep up with the commitment others might have made to me. A couple of questions I have been pondering in this regard: 1) Since I am fairly new to Lilypond, are there folks out there that would be willing to aid me in the likely event of confusion (I assume this group will do). Of course! 2) If/when inconsistencies in the language turn up - as I'm sure they will - is there an interest amoung the programmers to correct these? Since the parser is implemented using lex and bison, there shouldn't be any formal inconsistencies. At second thought, larger and larger parts of the syntax is now implemented as Scheme functions, but they too have a formal syntax check. However, I'm sure you can find lots of language constructs that are confusing. Note that the syntax and semantics has evolved over the years and still is. Many of these changes have in my opinion made the syntax more consequent and simpler. 3) A complaint I have seen both commonly on this archive and also on the todo list of the co-ordinators for lilypond, is to try and make the learning curve a bit less steep. One logical outcome of a document of this type is that it can be used to clean up the language - i.e. fulfilling this last goal. Is there any interest on the part of the programmers/organizers to undertake this task should I ever get this doc completed. I envision a process whereby the basic notation of lilypond stays the same (obviously), but: - perhaps some command forms would be dropped, - perhaps users would be forced into less freedom in the syntax This is one concern I have raised a couple of times. There are lots of optional constructs, which often confuses new users. They certainly save some typing and perhaps lower the initial threshold a bit for new users. However, I think the reduced number of key strokes only is significant in small test examples (which is what the main developers mostly do, and myself and other who help on the mailing list) but not in any real world typesetting. - perhaps come commands would be morphed to fit into a framework that more closely matches other commands. - any changes would idealy be changeable in input scripts using some sed/diff routines to update routines would be automated (no point in unnecessarily agravating the end user) That's what convert-ly does. Some examples: As I can see it now, there are numerous ways to create contexts. In fact if I understand correctly, most commands create contexts. One example I saw in the archive explicly used the context command in all (most?) of these cases. Perhaps either forcing the use of context everywhere a context is being created, or eliminating its use altogether as it is basically implied everywhere would be helpful See Creating contexts. Use \new if you want to make sure to get a new unique context. Use \context if you want to add on to an already existing one. However, you can use \context to create a new context if you manually make sure that the identifier is unique, so there's a flexibility that may cause confusion. I have been banging my head against the \combineparts routine. Mats suggested a different form using polyphonic notation which does the task just as nicely. \combineParts does not (to my naive eyes seem to fit the same form as the other commands (e.g. \new Staff, \new Voice etc.) Differences such as this make the learning curve steeper. If you search the mailing list archives, you will find lots of discussions on the \partcombine function. The general conclusion is that it often doesn't do what you want to do and that it's impossible to support since the implementation is too complex. However, there are plans to reimplement it from scratch. I think in the end Lilypond would be a cleaner language, but as always happens when trying to eliminate legacy code there is always someones toes being stepped on... What do people think about this... [snip established and reported error] Finally, is the web interface for posting to this archive the most straight forward method? I tried posting this yesterday, but it got lost in the ether. Is there perhaps an email address I can send the post to, where it will get sent back for validation etc. I believe the email address is at the bottom of every message on the list: lilypond-user at gnu.org Not on my web based threaded client (Loom?). I feel like such a newbie, but I can't find it on the FAQ or anywhere else... I can post to gmane.test, but how would I post to followup without using the web interface (i.e. to avoid the top-post checking in cases when I am not actually top-posting...) See www.lilypond.org - Documentation or www.lilypond.org - About for links to the mailing list
Re: Constructive Criticism and a Question
Jonathan «puts the finger» on an interesting topic. While most of the basic commands for note entry are quite intuitive (and that's a good thing!), there are some commands that the syntax seems counter-intuitive for a composer or a simple musician. For example, the command \times. Normally, we only write one number for tuplets, but in contemporary music, it is common to write a ratio to clarify the actual duration of the tuplet. For a triplet, we can write 3, but we can also write 3 : 2 over the note. It says 3 notes in the duration of 2 (I know most of you know that, but it is to explain the syntax. Also my English syntax might be bad). It is useful to make the difference between 7 : 8 and 7 : 4, for example. Some contemporary composers even write 7 : (quarter note figure) to say 7 notes in a quarter note duration But the \times function demands for a triplet to write 2/3. I know it might seem logical to ask for the fraction of the note. But in fact, for a composer, it is far more intuitive to write 3/2 or even better, 3:2 than 2/3 for a triplet. Writing 2/3 for a 3:2 tuplet is not a big problem, but what about 10:7? Also, for simple note entry, I think you should put MORE freedom for the possible order to write all the symbols. For example you want to put a eighth note at c# one octave higher, you want to make an octave check and make sure the sharp appears. We could write it in many ways cis'!=''8 cis'!8='' c8is!'='' cis8'=''! cis'8!='' etc. But LilyPond accepts only one way of writing it ... and I don't remember which one! And I didn't find any syntax rule about the exact order of the commands in the user manual. To put a syntax rule in the user manual would be good, but to make the compiler more flexible would be even better. Finally, it would be a good thing to revise the grammar of the functions in LilyPond by composers and musicians who are NOT programmers to make the LilyPond language more intuitive, so the learning curve would be less steep. That would be a great thing to do for an eventual LilyPond 3.0. And I would be willing to give some of my free time for that! Regards, Frédéric Chiasson 2006/12/18, Mats Bengtsson [EMAIL PROTECTED]: Jonathan Henkelman wrote: Ay - I hear you there. I have been considering taking on this project, and I still need to figure out if I have time before I get myself in over my head and unable to keep up with the commitment others might have made to me. A couple of questions I have been pondering in this regard: 1) Since I am fairly new to Lilypond, are there folks out there that would be willing to aid me in the likely event of confusion (I assume this group will do). Of course! 2) If/when inconsistencies in the language turn up - as I'm sure they will - is there an interest amoung the programmers to correct these? Since the parser is implemented using lex and bison, there shouldn't be any formal inconsistencies. At second thought, larger and larger parts of the syntax is now implemented as Scheme functions, but they too have a formal syntax check. However, I'm sure you can find lots of language constructs that are confusing. Note that the syntax and semantics has evolved over the years and still is. Many of these changes have in my opinion made the syntax more consequent and simpler. 3) A complaint I have seen both commonly on this archive and also on the todo list of the co-ordinators for lilypond, is to try and make the learning curve a bit less steep. One logical outcome of a document of this type is that it can be used to clean up the language - i.e. fulfilling this last goal. Is there any interest on the part of the programmers/organizers to undertake this task should I ever get this doc completed. I envision a process whereby the basic notation of lilypond stays the same (obviously), but: - perhaps some command forms would be dropped, - perhaps users would be forced into less freedom in the syntax This is one concern I have raised a couple of times. There are lots of optional constructs, which often confuses new users. They certainly save some typing and perhaps lower the initial threshold a bit for new users. However, I think the reduced number of key strokes only is significant in small test examples (which is what the main developers mostly do, and myself and other who help on the mailing list) but not in any real world typesetting. - perhaps come commands would be morphed to fit into a framework that more closely matches other commands. - any changes would idealy be changeable in input scripts using some sed/diff routines to update routines would be automated (no point in unnecessarily agravating the end user) That's what convert-ly does. Some examples: As I can see it now, there are numerous ways to create contexts. In fact if I understand correctly, most commands create contexts. One example I saw in the archive explicly used the context command in all (most?) of
Re: Constructive Criticism and a Question
There are also places where 3/2 is necessary with the current way of
doing things. For example, I was just doing a piece in 12/8 time
where triplets are the norm and I needed to do eighth notes with a
two feel. In this case I had to use \times 3/2 { c8 c } etc. I
guess in this case you're saying it would be more intuitive to do
2/3? I really don't mind the way things are now. It's a syntax that
has to be learned anyway, and once you learn it, it seems about the
same effort either way.
On Dec 18, 2006, at 9:30 AM, Frédéric Chiasson wrote:
Jonathan «puts the finger» on an interesting topic.
While most of the basic commands for note entry are quite intuitive
(and that's a good thing!), there are some commands that the syntax
seems counter-intuitive for a composer or a simple musician.
For example, the command \times. Normally, we only write one number
for tuplets, but in contemporary music, it is common to write a
ratio to clarify the actual duration of the tuplet. For a triplet,
we can write 3, but we can also write 3 : 2 over the note. It
says 3 notes in the duration of 2 (I know most of you know that,
but it is to explain the syntax. Also my English syntax might be
bad). It is useful to make the difference between 7 : 8 and 7 :
4, for example. Some contemporary composers even write 7 :
(quarter note figure) to say 7 notes in a quarter note duration
But the \times function demands for a triplet to write 2/3. I
know it might seem logical to ask for the fraction of the note. But
in fact, for a composer, it is far more intuitive to write 3/2 or
even better, 3:2 than 2/3 for a triplet. Writing 2/3 for a
3:2 tuplet is not a big problem, but what about 10:7?
Also, for simple note entry, I think you should put MORE freedom
for the possible order to write all the symbols. For example you
want to put a eighth note at c# one octave higher, you want to make
an octave check and make sure the sharp appears. We could write it
in many ways
cis'!=''8 cis'!8='' c8is!'='' cis8'=''!
cis'8!=''etc.
But LilyPond accepts only one way of writing it ... and I don't
remember which one! And I didn't find any syntax rule about the
exact order of the commands in the user manual. To put a syntax
rule in the user manual would be good, but to make the compiler
more flexible would be even better.
Finally, it would be a good thing to revise the grammar of the
functions in LilyPond by composers and musicians who are NOT
programmers to make the LilyPond language more intuitive, so the
learning curve would be less steep. That would be a great thing to
do for an eventual LilyPond 3.0. And I would be willing to give
some of my free time for that!
Regards,
Frédéric Chiasson
2006/12/18, Mats Bengtsson [EMAIL PROTECTED]:
Jonathan Henkelman wrote:
Ay - I hear you there. I have been considering taking on this
project, and I
still need to figure out if I have time before I get myself in
over my head
and unable to keep up with the commitment others might have made
to me. A
couple of questions I have been pondering in this regard:
1) Since I am fairly new to Lilypond, are there folks out there
that would be
willing to aid me in the likely event of confusion (I assume this
group will
do).
Of course!
2) If/when inconsistencies in the language turn up - as I'm sure
they will -
is there an interest amoung the programmers to correct these?
Since the parser is implemented using lex and bison, there
shouldn't be any
formal inconsistencies. At second thought, larger and larger parts of
the syntax
is now implemented as Scheme functions, but they too have a formal
syntax check.
However, I'm sure you can find lots of language constructs that are
confusing.
Note that the syntax and semantics has evolved over the years and
still is.
Many of these changes have in my opinion made the syntax more
consequent
and simpler.
3) A complaint I have seen both commonly on this archive and also on
the todo list of the co-ordinators for lilypond, is to try and
make the
learning curve a bit less steep. One logical outcome of a
document of this
type is that it can be used to clean up the language - i.e.
fulfilling this
last goal. Is there any interest on the part of the programmers/
organizers to
undertake this task should I ever get this doc completed. I
envision a
process whereby the basic notation of lilypond stays the same
(obviously), but:
- perhaps some command forms would be dropped,
- perhaps users would be forced into less freedom in the syntax
This is one concern I have raised a couple of times. There are lots of
optional
constructs, which often confuses new users. They certainly save
some typing
and perhaps lower the initial threshold a bit for new users.
However, I
think the
reduced number of key strokes only is significant in small test
examples
(which
is what the
RE: Constructive Criticism and a Question
You could compromise and use 2/3 to indicate current fractional time the way
it works now, but support using 3:2 to be more musically intuitive. I.e.,
the separator denotes the meaning; '/' for raw division and : for ratio. Not
knowing how the parser works, it could even be done by the parser itself,
automatically converting 3:2 to 2/3...
This also has the virtue of not breaking existing files.
Stephen
-Original Message-
From: [EMAIL PROTECTED] on behalf of David Rogers
Sent: Mon 12/18/2006 3:48 PM
To: lilypond-user@gnu.org
Subject: Re: Constructive Criticism and a Question
Carl Youngblood wrote:
There are also places where 3/2 is necessary with the current way of
doing things. For example, I was just doing a piece in 12/8 time
where triplets are the norm and I needed to do eighth notes with a
two feel. In this case I had to use \times 3/2 { c8 c } etc. I
guess in this case you're saying it would be more intuitive to do
2/3? I really don't mind the way things are now. It's a syntax that
has to be learned anyway, and once you learn it, it seems about the
same effort either way.
The way the syntax is now, is (in musical terms) the opposite of what's
printed. Having the syntax match the print is likely to be easier to learn for
at least the majority, if not everyone. (The way the syntax is now, it makes
mathematical sense; which is nice - but I don't think it serves a practical
purpose.)
David
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
2006-12-18, 16:52:20
The information contained in this e-mail message and any attachments may be
privileged and confidential. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended recipient,
you are hereby notified that any review, dissemination, distribution or copying
of this communication is strictly prohibited. If you have received this
communication in error, please notify the sender immediately by replying to
this e-mail and delete the message and any attachments from your computer.
2006-12-18, 16:24:45
The information contained in this e-mail message and any attachments may be
privileged and confidential. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended recipient,
you are hereby notified that any review, dissemination, distribution or copying
of this communication is strictly prohibited. If you have received this
communication in error, please notify the sender immediately by replying to
this e-mail and delete the message and any attachments from your computer.___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
To answer Carl, yes! To put 2 notes instead of 3, I would put 2:3, which
means 2 instead of 3 or 2 for 3. As David Rogers said, it fits what is
printed, or what would be printed if the whole ratio was there.
Also, is there a reason why the function wasn't named simply \tuplet ?
Frédéric
2006/12/18, David Rogers [EMAIL PROTECTED]:
Carl Youngblood wrote:
There are also places where 3/2 is necessary with the current way of
doing things. For example, I was just doing a piece in 12/8 time
where triplets are the norm and I needed to do eighth notes with a
two feel. In this case I had to use \times 3/2 { c8 c } etc. I
guess in this case you're saying it would be more intuitive to do
2/3? I really don't mind the way things are now. It's a syntax that
has to be learned anyway, and once you learn it, it seems about the
same effort either way.
The way the syntax is now, is (in musical terms) the opposite of what's
printed. Having the syntax match the print is likely to be easier to learn
for at least the majority, if not everyone. (The way the syntax is now, it
makes mathematical sense; which is nice - but I don't think it serves a
practical purpose.)
David
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Yeah, that would be a good solution satisfying everyone.
Frédéric
2006/12/18, Kress, Stephen [EMAIL PROTECTED]:
You could compromise and use 2/3 to indicate current fractional time the
way it works now, but support using 3:2 to be more musically intuitive.
I.e., the separator denotes the meaning; '/' for raw division and : for
ratio. Not knowing how the parser works, it could even be done by the
parser itself, automatically converting 3:2 to 2/3...
This also has the virtue of not breaking existing files.
Stephen
-Original Message-
From: [EMAIL PROTECTED] on
behalf of David Rogers
Sent: Mon 12/18/2006 3:48 PM
To: lilypond-user@gnu.org
Subject: Re: Constructive Criticism and a Question
Carl Youngblood wrote:
There are also places where 3/2 is necessary with the current way of
doing things. For example, I was just doing a piece in 12/8 time
where triplets are the norm and I needed to do eighth notes with a
two feel. In this case I had to use \times 3/2 { c8 c } etc. I
guess in this case you're saying it would be more intuitive to do
2/3? I really don't mind the way things are now. It's a syntax that
has to be learned anyway, and once you learn it, it seems about the
same effort either way.
The way the syntax is now, is (in musical terms) the opposite of what's
printed. Having the syntax match the print is likely to be easier to learn
for at least the majority, if not everyone. (The way the syntax is now, it
makes mathematical sense; which is nice - but I don't think it serves a
practical purpose.)
David
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
2006-12-18, 16:52:20
The information contained in this e-mail message and any attachments may
be privileged and confidential. If the reader of this message is not the
intended recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that any review, dissemination,
distribution or copying of this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
immediately by replying to this e-mail and delete the message and any
attachments from your computer.
2006-12-18, 16:24:45
The information contained in this e-mail message and any attachments may
be privileged and confidential. If the reader of this message is not the
intended recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that any review, dissemination,
distribution or copying of this communication is strictly prohibited. If you
have received this communication in error, please notify the sender
immediately by replying to this e-mail and delete the message and any
attachments from your computer.
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
I send a copy of this request to bug-lilypond, for the record.
/Mats
Frédéric Chiasson wrote:
To answer Carl, yes! To put 2 notes instead of 3, I would put 2:3,
which means 2 instead of 3 or 2 for 3. As David Rogers said, it
fits what is printed, or what would be printed if the whole ratio was
there.
Also, is there a reason why the function wasn't named simply \tuplet ?
Frédéric
2006/12/18, David Rogers [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
Carl Youngblood wrote:
There are also places where 3/2 is necessary with the current way of
doing things. For example, I was just doing a piece in 12/8 time
where triplets are the norm and I needed to do eighth notes with a
two feel. In this case I had to use \times 3/2 { c8 c } etc. I
guess in this case you're saying it would be more intuitive to do
2/3? I really don't mind the way things are now. It's a syntax that
has to be learned anyway, and once you learn it, it seems about the
same effort either way.
The way the syntax is now, is (in musical terms) the opposite of
what's printed. Having the syntax match the print is likely to be
easier to learn for at least the majority, if not everyone. (The
way the syntax is now, it makes mathematical sense; which is nice
- but I don't think it serves a practical purpose.)
David
___
lilypond-user mailing list
lilypond-user@gnu.org mailto:lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
--
=
Mats Bengtsson
Signal Processing
Signals, Sensors and Systems
Royal Institute of Technology
SE-100 44 STOCKHOLM
Sweden
Phone: (+46) 8 790 8463
Fax: (+46) 8 790 7260
Email: [EMAIL PROTECTED]
WWW: http://www.s3.kth.se/~mabe
=
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
Jonathan Henkelman wrote: In terms of making it easier, I don't know if it would be straight forward or not, but if the PDF version of the manual had chapter numbers in the table on contents that showed on the bookmark pane (to the left) it would make it much easier to bounce around and find one's way back again. I'm sure that this can be done by adding a few words to some part of the doc and/or makefiles; the problem is simply finding the right place and figuring out the words. I'll look into this. Is there a copy of the so called programmers documentation in a suitable format to download i.e. PDF (I know it would be long) or a few large HTML files, or an archive (tarball - whatever) of the current HTML documentation. I was hoping to do a bit more work on this over the break, but will have very limited web access... There _is_ a documentation tarball, but I'm not certain if it includes the program reference. Some type of doc. that oulined the lexical construction of Lilypond would be helpful. I am not used to the level on confusion I am experiencing now, when learning a language. As with all open-source projects, documentation depends on interested people writing material. I don't have the time to pursue such a project, but if you (or somebody else) wrote this material, I'd be more than happy to add it to the manual. I am not even sure the manual is totally consistent on this point, e.g. (pg 209) [I have reformated it so it easier to read here]: ... \applyOutput #'context #function % apply to Voice To have it interpreted at the Score or Staff level use these forms \context \applyOutput #'Score #function \context \applyOutput #'Staff #function Thanks, this has been fixed in the source archive. When the next version of lilypond comes out, it should be fixed on the web. Finally, is the web interface for posting to this archive the most straight forward method? I tried posting this yesterday, but it got lost in the ether. Is there perhaps an email address I can send the post to, where it will get sent back for validation etc. I believe the email address is at the bottom of every message on the list: lilypond-user@gnu.org Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: constructive criticism
While we are on the subject of constructive criticism. Emacs and vim editing. The information for both these modes is only found in the INSTALL file. But I install using apt-get so if I didn't know about these modes I might never find out. There is a section of point and click in the docs. but I would like there to some docs on them. additionally A while back I made an attempt at a ftplugin for vim lilypond, I posted it to the group but no one sounded interested. The idea is to make short cuts for common operations. tuplets slurs etc with the ability to surround notes with that code. I have the feeling that people may be customizing vim/emacs for their own use but we aren't sharing these tweaks. Is there a way that the editor issue could be displayed, promoted more? The better the tools the less likely mistakes will creep into a score. I would certainly like some documentation on how to use what is already there in the vim and emacs stuff. Aaron ___ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user
Re: constructive criticism
[EMAIL PROTECTED] writes: Please! Show some initiative for yourself; I just answered the same question this morning. I am confused, I guess to many emails,flying what are we talking about here? Are we talking cvs? Yes. I actually am not sure in retrospect what I am offering to help on. If it is updating seealso entries you said you already did this one. but if this is to add the same format to other or all see also entries, I would gladly but I should first see what the new format looks like. See http://lilypond.org/doc/v2.1/Documentation/user/out-www/lilypond/Tremolo-repeats.html#Tremolo%20repeats I will mozy over to the cvs and look at the pages, if you like (if that is not you intention let me know) I certainly only intend to help if possible not make things more complicated. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user
Re: constructive criticism
Aaron writes: While we are on the subject of constructive criticism. Yes... The information for both these modes is only found in the INSTALL file. That's because it's only necessary for the packager. But I install using apt-get so if I didn't know about these modes I might never find out. What system do you use? After apt-get install lilypond, opening a .ly file starts lilypond mode for me (debian/unstable), it has done so for years. If it doesn't that's probably a bug. As we're on the topic of constructive criticism, it would be great if you figured out what goes wrong, and send a bug report (possibly with a patch) to the packager. I would certainly like some documentation on how to use what is already there in the vim and emacs stuff. I think it should just work, probably for vim too. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user
Re: constructive criticism
[EMAIL PROTECTED] writes: If the documentation were in docbook, its far more approachable than texinfo (IMHO). No, it's not. If only we had a Wiki, then we could improve the documentation. If only it was in XML, then I could work on the documentation If only it was in Docbook, then it were approachable. If only we had better buzz-word compliant gee-whiz-bang technology, then I would work on it. When will you people get a grip? Someone has to sit down and *write* documentation. Yes, writing. That means: investing time to write down English sentences, rearranging, proofreading, editing, spellchecking, etc. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user
\apply nest-props Re: constructive criticism
Thu, 8 Jan 2004 12:00:14 +0100, Han-Wen a dit :
Come to think of it, this form of \with is superfluous. It is possible
to write it with something like
\apply #(nest-props '((Stem thickness 4) (Slur transparent #t)))
{ .. }
where nest-props takes care of pre- and appending the appropriate
settings.
for the record, here is a possible implementation (using lily 2.1.0):
#(use-modules (ice-9 optargs))
#(define-public (nthcdr n source)
(do ((rest source (if (pair? rest) (cdr rest)))
(i 0 (1+ i)))
((= i n) rest)))
#(define-public (group source n)
(if (zero? n) (error zero length))
(letrec ((rec (lambda (source acc)
(let ((rest (nthcdr n source)))
(if (pair? rest)
(rec rest (cons (list-head source n) acc))
(reverse! (cons source acc)))
(if (null? source) '() (rec source '()
#(defmacro* make-music (name #:rest props)
Make a music expression, of type `name' (a non quoted symbol).
`props' describe the music expression properties. For isntance:
(make-music PropertySet
symbol 'autoBeaming
value #f)
(let ((prop-clauses (group props 2))
(gmus (gensym)))
`(let ((,gmus (make-music-by-name ',name)))
,@(map (lambda (clause)
`(ly:set-mus-property! ,gmus ',(car clause) ,(cadr clause)))
prop-clauses)
,gmus)))
#(defmacro* context-override (context property setting value #:key (once #f))
Make a ContextSpeccedMusic with OverrideProperty element, similar to:
[\\once] \\property context.property \override #'setting = #value
`(context-spec-music
(make-music OverrideProperty
once ,once
symbol ',property
grob-property ',setting
grob-value ,value)
',context))
#(defmacro context-revert (context property setting)
Make a ContextSpeccedMusic with RevertProperty element, similar to:
\\property context.property \revert #'setting
`(context-spec-music
(make-music RevertProperty
symbol ',property
grob-property ',setting)
',context))
#(defmacro* nest-props (#:rest prop-clauses)
`(lambda (mus)
(ly:set-mus-property! mus 'elements
(list
,@(map (lambda (prop-clause)
`(context-override ,@prop-clause))
prop-clauses)
(make-music SequentialMusic elements (ly:get-mus-property mus 'elements))
,@(map (lambda (prop-clause)
`(context-revert ,(car prop-clause) ,(cadr prop-clause) ,(caddr
prop-clause)))
prop-clauses)))
mus))
titi = \notes { c'8( d') e'( f') g'4( a') }
\score {
\notes {
\titi
\apply #(nest-props (Voice Stem thickness 4)
(Voice Slur transparent #t))
{ \titi }
\titi
}
}
attachment: test-nest-props.preview.png
nicolas
___
Lilypond-user mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-user
Re: constructive criticism
[EMAIL PROTECTED] writes: I humbly find it unfair that you didn't quote the clause: unless the reporter literally includes the piece of text she wants But anyway, I'm now aiming at giving you *patches*, which you prefer even to bug reports, don't you? My wish list for suggestions of the manual, ranked from most to least desirable: * Patches, containing well-written and well-edited updates and refinements of the manual. * Bugreports, indicating specific deficiencies of manual sections that are unclear * Patches, containing updates and refinements of the manual. I Usually I have to rewrite these, since they're often not well-written. * Website comments/wikis, where I have to dig through a text to figure out what is not clear and why. Then there is the option of setting up a FAQ/Wiki/whatever that is separate from the manual. You have my blessing to do what you like, and it's probably best to ignore me, because I have grown cynic over the years. I have one advice: just do it! FYI: We started and filled a wikiwiki some three odd years ago, when wikiwikis were the next hot thing. We decided to take it off line last year, because the experiment failed. It is yet another potential source of information to track, it grows stale and it had hardly any contributors besides the developers. Although there are exceptions, lowering the threshold only yields less useful information. Ok, I really did not know about this. My theory, which is exclusively mine and invented be me alone, is that linking it from the individual manual pages would help a lot. Of course, in practice theory and practice are often different. I admit I have no experience besides the Haskell Wiki, which works pretty well serving an identical purpose. Keep in mind that a succesful wiki needs big and active community of people maintaining it. That's fair. Well, before posting I had a look at the .itelys, since I happened to have a source tree handy. You don't expect users have it, do you? Anyway, the point is writing/fixing/asking *while* reading, as opposed to updating from cvs, searching and modifying a file in an editor, diffing, posting and waiting for the changes to appear. You know, if you type make web, the changes appear automagically on your own harddisk. Not much waiting needed. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user
