"Keith OHara" <k-ohara5...@oco.net> writes: > On Mon, 24 Sep 2012 15:51:43 -0700, Francisco Vila > <paconet....@gmail.com> wrote: > >> 2012/9/24 Janek Warchoł <janek.lilyp...@gmail.com>: >>> Seriously though, i think this syntax would be very useful for >>> algorithmic composers and computer programs manipulating Lily code. >>> Another advantage is code readability and ease of copying it (shall i >>> elaborate?) >>> >>> Besides, it's not like we would loose any functionality: \times would >>> still be there. >> >> This convinces me. I'm for it. > > I'll be against it. I make typos of c3 or c5 when I want to type c4
One thing that I find bad about it is that we lose a straightforward relation between input and output. Our durations are composed of log2, dots, and scale factor. We then get a mushy "duration is the following rational, can I have tuplet brackets with that somehow?" instead. Why is there no notation for \times 2/3 c1 ? > Let the humans use \tuplet as proposed years ago, > <http://lists.gnu.org/archive/html/lilypond-user/2006-12/msg00489.html> > and which is easy to implement (attached) now that David has added the > infrastructure to write music-functions that take fractions, and > optional arguments (although I'm not sure if the optional argument is > wise in this case). Well, "music argument after left-out optional argument" at the current point of time means "closed music". It is likely a safe bet that we rarely need a single note for a tuplet, so it is not much of a problem, and I am chugging away at getting the "closed music" thing scrapped, but that's still a month left at least. What possibly would make sense as an optional argument would be a setting for tupletSpannerDuration. I am not sure about it, though, since one would usually want the same duration for a number of calls. While we still have the [talk] tag, we could use the name \tup-let for a version automatically using baseMoment for tupletSpannerDuration, and \tuplet for no subdivision. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
