Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project!

## Re: [Rosegarden-devel] `Diatonic' transposition

 Re: [Rosegarden-devel] `Diatonic' transposition From: Arnout Engelen - 2007-02-23 23:46:35 ```Dougie McGilvray wrote: > might be worth a looking at the base-40 system if you haven't already. > It's a numerical representation of enharmonic pitch which I'm sure > would allow 'easy' diatonic transposition, but I didn't look into it > too deeply. > > http://www.ccarh.org/publications/reprints/base40/ Interesting read (and pleasantly written) indeed - however, quoting from the article: ---- The most successful systems to be proposed thus far have been those which recognize the two-dimensional nature of pitch notation, i.e., that the unambiguous representation of pitch notation requires two independent parameters. (..) From the standpoint of data storage and retrieval, however, the representation of musical pitch by a single numerical parameter would be superior to any system using two parameters. (..) any single-parameter system will have inherent ambiguities. ---- I think for Rosegarden a simple 2-parameter representation is clearer and more elegant, and does not neccessarily have the limitations* imposed by a 1-parameter system. I haven't been able to find out more about the representations by Norbert Boerker-Heil mentioned in the article. The Binomal representation** by Alexander Brinkman mentioned in the article is, however, a lot more like I'd have imagined this (except much more nicely worked out and documented ;) ). Basically, a note or interval is stored as a pair of pitch and step. So C is <0,0>, D <2,1>, E <4,2>, F <5,3>, et cetera. This has nice properties: D3 transposed upwards by a major triad will simply be, for example, <(3*12)+2,(3*7)+1> + <(0*12)+4,(0*7)+2> = <36+2+4,19+2> = <42,24>. Converting that back to conventional notation is simple: the octave is 42div12 or 24div7 = 3, 24%7=3 means 'F', F's pitch-%-12 is normally 5, but 42%12=6, hence one # needs be added, yielding F#3. Computing the interval between 2 notes can be done by substracting them much like how transposing is done by adding. I like it. We could use the proposed single-number representation, but I guess it'd be neater to do it 'the C++ way' and just store it as a class with 3 fields. Nice stuff, thanks for the pointer. Arnout * the base40-system works as long as a note never has more than 2 flats or sharps. The article nicely explains how the system can be scaled up to a base-54 system (3 flats/sharps) and beyond, which could be sufficient, but isn't really elegant. ** A Binomial Representation of Pitch for Computer Processing of Musical Data, http://www.jstor.org/view/01956167/ap020010/02a00030/0 (if that url works) ```

 [Rosegarden-devel] `Diatonic' transposition From: Arnout Engelen - 2007-02-23 08:11:24 ```Hi, Currently the only parameter, when transposing, is the number of semitones. This might be too coarse for notation, as you can't distinguish between transposing from C to A# and transposing from C to Bb. While those are of course equivalent for most practical purposes, the difference is really relevant when sight-reading: for example, for a more experienced sight-reader Bb-D-F will be instantly recognisable as a major Bb chord, whereas A#-D-F is something random that upon closer inspection turns out to be equivalent to a major Bb chord. I could take a stab at extending the transpose dialog* and refining the tranposition algorithm to take into account not only the chromatic distance but also the number of diatonic steps taken - which could be tricky here and there :). Any ideas, recommendations, possible problems? Regards, Arnout * Perhaps simply letting the user select a reference and target note? Of course specifying the transposition by number of semitones should still be possible, in that case we could just choose a suitable number of steps automatically, or perhaps fall back to a simplest-fit algorithm ('choose the most common accidental'). ```
 Re: [Rosegarden-devel] `Diatonic' transposition From: Arnout Engelen - 2007-02-23 23:46:35 ```Dougie McGilvray wrote: > might be worth a looking at the base-40 system if you haven't already. > It's a numerical representation of enharmonic pitch which I'm sure > would allow 'easy' diatonic transposition, but I didn't look into it > too deeply. > > http://www.ccarh.org/publications/reprints/base40/ Interesting read (and pleasantly written) indeed - however, quoting from the article: ---- The most successful systems to be proposed thus far have been those which recognize the two-dimensional nature of pitch notation, i.e., that the unambiguous representation of pitch notation requires two independent parameters. (..) From the standpoint of data storage and retrieval, however, the representation of musical pitch by a single numerical parameter would be superior to any system using two parameters. (..) any single-parameter system will have inherent ambiguities. ---- I think for Rosegarden a simple 2-parameter representation is clearer and more elegant, and does not neccessarily have the limitations* imposed by a 1-parameter system. I haven't been able to find out more about the representations by Norbert Boerker-Heil mentioned in the article. The Binomal representation** by Alexander Brinkman mentioned in the article is, however, a lot more like I'd have imagined this (except much more nicely worked out and documented ;) ). Basically, a note or interval is stored as a pair of pitch and step. So C is <0,0>, D <2,1>, E <4,2>, F <5,3>, et cetera. This has nice properties: D3 transposed upwards by a major triad will simply be, for example, <(3*12)+2,(3*7)+1> + <(0*12)+4,(0*7)+2> = <36+2+4,19+2> = <42,24>. Converting that back to conventional notation is simple: the octave is 42div12 or 24div7 = 3, 24%7=3 means 'F', F's pitch-%-12 is normally 5, but 42%12=6, hence one # needs be added, yielding F#3. Computing the interval between 2 notes can be done by substracting them much like how transposing is done by adding. I like it. We could use the proposed single-number representation, but I guess it'd be neater to do it 'the C++ way' and just store it as a class with 3 fields. Nice stuff, thanks for the pointer. Arnout * the base40-system works as long as a note never has more than 2 flats or sharps. The article nicely explains how the system can be scaled up to a base-54 system (3 flats/sharps) and beyond, which could be sufficient, but isn't really elegant. ** A Binomial Representation of Pitch for Computer Processing of Musical Data, http://www.jstor.org/view/01956167/ap020010/02a00030/0 (if that url works) ```
 Re: [Rosegarden-devel] `Diatonic' transposition From: D. Michael McIntyre - 2007-02-24 05:33:40 ```On Friday 23 February 2007 3:11 am, Arnout Engelen wrote: > This might be too coarse for notation, as you can't distinguish between > transposing from C to A# and transposing from C to Bb. I suggest transposing by changing the key signature, or adding a key signature and choosing the transpose option. That usually makes good choices, with the occasional need to tweak things up or down an octave. Play with that first, and if it doesn't make you happy, then hack away. -- D. Michael McIntyre ```
 Re: [Rosegarden-devel] `Diatonic' transposition From: Arnout Engelen - 2007-02-24 08:32:32 ```D. Michael McIntyre wrote: > On Friday 23 February 2007 3:11 am, Arnout Engelen wrote: > >> This might be too coarse for notation, as you can't distinguish between >> transposing from C to A# and transposing from C to Bb. >> > > I suggest transposing by changing the key signature, or adding a key signature > and choosing the transpose option. That usually makes good choices, with the > occasional need to tweak things up or down an octave. > Thanks for mentioning that: that makes me realize there are actually 2 transposition use cases: transposing within the current key and transposing changing the key. The latter case indeed seems already implemented via 'change key, transpose into this key'. For the former case it might be sufficient to first do 'change key, maintain pitches' in the reverse direction, and then 'change key, transpose into this key' back to the original key. I still think it's useful to have a 'diatonically aware' transposition dialog UI-wise, but indeed much of the code for actually performing the transposition properly might already be there. Arnout ```