[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: \time vs. \times
From: |
Erik Sandberg |
Subject: |
Re: \time vs. \times |
Date: |
Sat, 1 Oct 2005 16:28:03 +0200 |
User-agent: |
KMail/1.8.1 |
On Friday 30 September 2005 18.49, Werner LEMBERG wrote:
> While writing scores with LilyPond I've mixed up \time and \times
> again and again.
>
> Thus I have the following suggestion: Make a new command `\tuplet',
> which is an alias of \times and deprecate the latter.
If we are going to change this, I suggest that we also make \tuplet a true
Scheme function. Lots of commands that now have their own tokens in the
grammar could be Schemified, and IMHO, iwbn to do this.
I started a thread on 2005-07-20 on this issue; however no conclusion was made
at that point. I'd be happy to change the parser, if we just can agree on a
good convention.
I think it would be a good idea to leave out parameter type checking from the
grammar, and support n-parameter functions in general, for large enough
values of n (say 10). The parser would use the same grammar rule for each
parameter, and do type checking after parsing all parameters.
The simplest way to do this, would be to say
parameter = SCM | Music | Markup;
This has the problem that all non-music parameters would need a # before them;
e.g., \bar would need to be written as
\bar #"|.". We could therefore extend the rule to
parameter = SCM | Music | Markup | String;
but unfortunately, it's impossible to extend the rule to re-implement all
commands.
When looking at this problem, it's good to look at this set of commands:
\transpose c d {e}
\times 2/3 {c}
\set Voice.foo = bar
\repeat volta 2 {c d e f}
\repeat volta 2 {c d e f} \alternative {{d}{e}}
The main problems are:
- c 4 can either be interpreted as one music expression c4, or as an
expression c followed by number 4.
- Special characters such as . and = and / are problematic; for example c4*2/3
could be interpreted either as three parameters c4*2 / 3 or as a single music
expression.
- repeat uses a variable number of parameters.
I've done some quick thinking again, and one idea is to do the follwoing:
1. Forbid simple music expressions which aren't enclosed in {} or <<>>. This
has the points that
- It seems to solve many problems with the grammar.
- It is a simple rule, easy to remember.
- It is consistent with e.g. toplevel_music.
- I don't know about any cases when it makes music much more tedious to
enter. If you can enter a function name, you can also enter a pair of
brackets.
Technically, this restriction can be implemented by replacing Music by
Composite_music everywhere in the grammar, except in Music_list.
2. The function parameter rule can look like:
parameter = pitch | '/' | '.' | '=' | NUMBER | String | Markup |
Composite_music;
3. Re-implement \times, \transpose, etc. as music functions. This should be
possible for all commands except \lyricsto (etc) and \repeat.
4. Change the repeat syntax to
\repeat volta 2 {c d e f}
\repeat volta 2 {c d e f \alternative {{d}{e}}}
I.e., alternative is a unary music function, which creates a music
subexpression that is recognised only by the \repeat function. This is an
ugly hack, but it removes a shift/reduce conflict, and it makes it possible
to implement alternatives in the middle of a repeat (which Sven asked for
some time ago).
It would be possible to support functions with any number of parameters, by
allowing a syntax similar to \func '<' param1 param2 ... '>'. There's
something inelegant about this IMHO, and it's only needed for functions with
variable number of arguments. Hence, I don't think we need to add it now.
Han-Wen, do you have any objections against imposing this restriction?
--
Erik
- Re: \time vs. \times,
Erik Sandberg <=