lilypond-devel
[Top][All Lists]
Advanced

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

Re: Music functions with pitch and duration arguments


From: David Kastrup
Subject: Re: Music functions with pitch and duration arguments
Date: Fri, 22 Jul 2011 22:15:08 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Han-Wen Nienhuys <address@hidden> writes:

> On Fri, Jul 22, 2011 at 3:32 AM, David Kastrup <address@hidden> wrote:
>
>>>> Anyway, this is not particularly complex either.  Could possibly pave
>>>> the way for a nicer function for setting up strings for tabulatures.
>>>> Also stuff like \transpose can be implemented by users with a
>>>> straightforward syntax accepting just pitches where pitches are asked
>>>> for, without the user needing to disassemble music in order to get at
>>>> the pitch somewhere in the center of the mess.
>>>
>>> It would be awesome to implement \transpose (and relative, for that
>>> matter) as a music function.
>>
>> Not likely a speed gain.
>
>
> It's not for speed. I have always been annoyed by the special parser
> rules for those, so it would be neat to be able to drop those.
>
>
>>> It seems to be missing the init for the _proc variables you added,
>>> though.
>>
>> No.  They are created by the existing calls of IMPLEMENT_TYPE_P in
>> pitch.cc and duration.cc and initialized there.
>
> Ah, I forgot.  LGTM then.

I'll try fudging up documentation for it, and I'll check the
perspectives for minimizing the combinations of duration and music
arguments that are not either accepted or flagged with a proper error
message rather than a generic syntax error.

With regard to merging: this is an incompatible change since arguments
of type ly:pitch? or ly:duration? previously asked for Scheme arguments
like
#(ly:make-pitch ... or #(ly:make-duration

The Lilypond codebase does not contain such music function arguments I
think.  It should actually work to convert them to
#(ly:export (ly:make-pitch ...
so there is a straightforward (but more likely than not untowardly
awkward) migration path.

Apart from this change in semantics, this should not cause regressions.

-- 
David Kastrup




reply via email to

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