lilypond-devel
[Top][All Lists]
Advanced

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

Re: Implement framework for post-fix text (de)cresc spanners


From: Reinhold Kainhofer
Subject: Re: Implement framework for post-fix text (de)cresc spanners
Date: Thu, 7 May 2009 19:59:14 +0200
User-agent: KMail/1.11.2 (Linux/2.6.28-11-generic; KDE/4.2.2; i686; ; )

Am Sonntag, 12. April 2009 01:57:02 schrieb Neil Puttock:
> 2009/4/12 Patrick McCarty <address@hidden>:
> > The "music properties" generally follow a specific naming convention:
> > all lowercase, except the multiple-word properties, which contain
> > hyphens between words.
> >
> > I think this is what Neil is referring to.
>
> That's exactly what I meant, though reading back what I posted to
> Rietveld, I don't blame you for becoming confused. :)
>
> Of course, what I should have said was you need to use
> camel_case_to_lisp_identifier () to convert e.g. crescendoSpanner ->
> crescendo-spanner.

I have now implemented this, changed the definitions of the spanners, added 
regtests, etc. Patch can be found at:
http://codereview.appspot.com/39047

However, I'm still unsure about the general design: Which of the following 
possibilities for the internal representation of a text cresc start event 
shall we use:

1) cresc = #(make-music 'CrescendoEvent 'span-direction START 'crescendo-
spanner 'text 'crescendo-text "cresc.")

2) cresc = #(make-music 'CrescendoEvent 'span-direction START 'crescendo-text 
"cresc.")

3)  cresc = #(make-music 'CrescendoEvent 'span-direction START 'spanner-type 
'text 'spanner-text "cresc.")

4)  cresc = #(make-music 'CrescendoEvent 'span-direction START 'spanner-text 
"cresc.")

In particular, the question is whether the properties should be (de)crescendo-
spanner vs. spanner-type, and (de)crescendo-text vs. spanner-text (I prefer 
not to include the crescendo/decrescendo, but keep the same property name for 
both CrescendoEvent and DecrescendoEvent).
The other question is whether we should stick to LilyPond's usual redundancy 
(i.e. defining both the type and if type=='text, then use the text property) or 
simply take the presence of a text property to infer that the type should be a 
text spanner and not a hairpin?

What do you think is the proper internal design for this feature?

Cheers,
Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, address@hidden, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

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