[Top][All Lists]
[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
signature.asc
Description: This is a digitally signed message part.
- Re: Implement framework for post-fix text (de)cresc spanners,
Reinhold Kainhofer <=