Re: Diatonic/modal transposition function (John Mandereau)

[Stefan Thomas]

Dear John,
I tried now Your key-diatonic tranposition, but, in the below quoted
snippet, it doesn't work. I get the error message:
programming error: moving backwards in time
Here is the snippet:

%%%%%% begin %%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%
\version "2.12.0"
\include "intervalle.ly"

oberstimme = \relative c''
{ b8. c16 d8 r8 e r d r c r b r }

\score {
  <<
    \new Staff { \key g \major \time 2/4 \oberstimme }
    \new Staff { \key g \major  \time 2/4 \keyDiatonicTranspose b g
\oberstimme }
  >> }
%%%%%%%%%%%end %%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%
2008/12/30 John Mandereau <address@hidden>:
> Le lundi 29 décembre 2008 à 12:33 +0100, Tao Cumplido a écrit :
>> As far as I understand it it works independent from a key signature so
>> it doesn't matter if the key is in C or not.
>>
>> The function says taht you transpose a pattern in a given key for X
>> steps, so in your example you transpose a pattern in a-minor one step
>> up, and from C one step is D.
>
> Correct.
>
>
>> Would it be possible to make \diatonicTranspose recognize the key 
>> automatically?
>
> Yes, if you know how to retrieve a context property -- I've started
> looking at this, this is less trivial than setting context properties
> with \set.  It would not be named \diatonicTranspose, though, as this
> function must keep a general enough purpose; would \keyDiatonicTranspose
> be a sensible name?
>
>
>> It would save a lot of typing.
>> e.g.:
>>
>> motive = { c'8 d'8 }
>>
>> \new Staff
>> {
>>    \key c \major
>>    \motive
>>    \diatonicTranspose #1 \motive
>>    \diatonicTranspose #2 \motive
>> }
>
>
>> Maybe the same for modeTranspose, that I only have to specify the mode
>> I transpose into.
>> This would be especially useful for minor keys because a motive is
>> often transposed into minor melodic/harmonic.
>
> Certainly.  The problem is, it's not possible to retrieve the current
> key signature as a context property at parsing stage, because contexts
> (and thus context properties) are built in the next stage "music
> interpretation".  A dirty solution is defining a custom \key command
> (e.g. defining \myKey that calls \key and stores the tonic and scale in
> global variables), then reusing global variables in a
> \keyDiaonicTranspose command; the downside of this is, it would be too
> dirty for inclusion in LilyPond.  A clean solution is delaying
> evaluation of the diatonic applyContext; here's a sample based on
> functions I sent in
> http://lists.gnu.org/archive/html/lilypond-user/2008-12/msg00849.html
>
>
> %%% Begin snippet %%%
>
> #(define (lookup-context-property c symbol)
>  (if (ly:context? c)
>   (let ((v (ly:context-property c symbol)))
>    (if (and v (not (null? v)))
>     v
>     (lookup-context-property (ly:context-parent c) symbol)))
>   #f))
>
>
> keyDiatonicTranspose =
> #(define-music-function
>  (parser location pitch-note1 pitch-note2 music)
>  (ly:music? ly:music? ly:music?)
>  "Transpose music diatonicly by from pitch-note1 to pitch-note2
> in scale on tonic-note."
>  (make-music 'ApplyContext
>   'origin location
>   'procedure (
>     lambda (c)
>     (let ((k (lookup-context-property c 'keySignature)))
>      (ly:interpret-music-expression
>       (make-music
>        'ContextSpeccedMusic
>        'property-operations
>        '()
>        'context-id
>        (ly:context-id c)
>        'context-type
>        (ly:context-name c)
>        'element
>        (mode-transpose
>         pitch-note1 pitch-note2 #{ c #} k #{ c #} k music))
>       (ly:context-find c 'Global))))))
>
> minorPattern = {
>  c'2 ~  c'8 d'16 ees' f' g' aes' bes' c''4 g' ees' c'
> }
>
> {
>  \key c \minor
>  \repeat unfold 2 c'1
>  \keyDiatonicTranspose c d \minorPattern
> }
>
> %%% End snippet %%%
>
> Note the strange spacing I get in the attached PNG; it even segfaults if
> I add c'1 after "\keyDiatonicTranspose c d \minorPattern".  I'll reduce
> try to reduce the problem down and submit a bug report.
>
>
>> I guess the best solution would be to have both options available,
>> e.g. just to specify the key if necessary and automatic recognition of
>> the current key if no key is specified.
>
> It is hardly possible to have optional arguments in music functions,
> because AFAIK the parser grabs next input tokens according to the music
> function prototype.  Having music functions with variable argument count
> would make the parser horribly complex and would create ambiguous cases.
>
>
>
>> Another thing I was thinking about is maybe using interval numbers
>> instead of steps for the integer, so that #2 tranposes a second up and
>> #-4 a fourth down etc.
>
> This would make the arithmetic more complicated (as it already does to
> people that learn western music theory :-P), a better solution is to use
> interval names as I suggested to Stefan, or even better replace this
> integer argument start pitch and final pitch as I proposed.
>
>
>> It's definitely an awesome function and it makes constructing a piece
>> with motives possible.
>
> Yeah, as my flatmate says this function is relevant to composition and
> not pure music typesetting, but by design LilyPond already offers input
> facilities with this kind of side-effect (or at least it has this
> power).
>
> Best,
> John
>

intervalle.ly
Description: Binary data