lilypond-devel
[Top][All Lists]
Advanced

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

Re: Music functions and #


From: Erik Sandberg
Subject: Re: Music functions and #
Date: Wed, 20 Jul 2005 22:43:40 +0200
User-agent: KMail/1.8

On Wednesday 20 July 2005 19.29, Han-Wen Nienhuys wrote:
> Erik Sandberg wrote:
> >>it's possible, but you have to have extra error checking to catch things
> >>like
> >>
> >>   \transpose { f } \lyrics { bar }  { ..victic-music.. }
> >
> > What if we just define transpose using something like
> > transpose = #(def-music-function .. (ly:pitch? ly:pitch? ly:music?) .. )
> > ?
> >
> > I think this would catch the above with something like
> > wrong type for argument 1.  Expecting pitch.
> > which IMHO even is better than the current
> > Unexpected '{'
>
> yes, but a ly:pitch? object is a C++ Pitch object, which is different
> from Music.  So you would define transpose as
>
>    (ly:music? ly:music? ly:music?)

Ah.

> and check that the first 2 arguments are event-chords with a single
> noteevent inside. Right now, you cannot define it as
>
>    (pitch, pitch, music)
>
> since lily interprets
>
>    \transpose c d {..stuff..}
>
> as
>
>    \transpose c4 d4 {..stuff..}
>
> where c4 and d4 are in fact EventChords.

We could change rule Music -> Composite_music for the parameters; I think this 
would make both the solutions I proposed work.

So the two options are:
a) Arbitrary number of non-Music parameters, followed by one or two Music 
parameters, or alternatively 0-2 non-Music parameters followed by no Music 
parameter.
b) Maximally N parameters, of any allowed parameter types, mixed in any order, 
where N is a small integer.

I'd vote for (b), since it's a cleaner rule, easier to extend, and probably 
more useful.

Erik




reply via email to

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