lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Feature suggestion: unfold shorthand


From: Erik Sandberg
Subject: Feature suggestion: unfold shorthand
Date: Fri, 8 Apr 2005 15:09:34 +0200
User-agent: KMail/1.7.2

Hi all.

I have a feature suggestion.

Symptom: 
I often find myself writing things like "c c c c c c c", or, even worse, "bes8 
bes bes bes bes bse bes" which gives a syntax error. What I really want to 
do, is to do "\repeat unfold 7 bes", but I don't do this since it's too many 
characters to write. The current repeat unfold syntax is practically useful 
mainly for music where a longer period, like one bar, is repeated.

Possible solutions now (without modifying lily):
(a) Some dirty \applymusic trickery, could make it possible to do something 
like
\applymusic \unfold { ... \seven bes ... }
(b) One could use a preprocessor to reduce the number of characters used for 
"\repeat unfold". This solution would be good enough. However, a majority of 
lily users don't use preprocessors (AFAIK).

Suggestion:
A shorthand for \repeat unfold n music, looking something like
n*music
The above example would then look like
7*bes8

Some advantages:
- fast to write, easy to remember
- Would probably be practically useful for the average lilypond user
- I did a quick test on the usefulness of this notation. I used all .ly files 
from the Gimo collection as my test, and concluded that the total .ly file 
size would be reduced by about 6% on average, if this method would be used 
just for repetitions of single notes. This suggest that it _would_ give an 
essential saving of typing work.

Some disadvantages:
- Gives two fundamentally different meanings to *. Some people could find the 
difference between 4*c8 and c8*4 (or the invalidity of c*4) confusing.
- It might require too big/unclean changes to the grammar. I can't find any 
ambiguity, but cases like c4*c8 may make it feel dirty.

An alternative notation could be something like
\cp 7 bes8
This would be cleaner (grammar-wise), but less intuitive. Also, it is very 
much like (b) above, and goes a bit against the principle that lily shouldn't 
support macros.

Any ideas/comments?

(if it sounds like a good idea, I could try to implement it. I need to do some 
real hacking to get to know lily's internals better)

Erik




reply via email to

[Prev in Thread] Current Thread [Next in Thread]