[Top][All Lists]
[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