Function to change scale

[Dartelec]

Just wondering:

We have c-minor triad:
60 63 67

We try to put it to C-Major scale by finding closest pitches:
60, 62 is close and 64 is as close, 67
so 63 converts to 62 or to 64

If the context is harmonic/chordal
60 64 67 is "correct"

If the context is melodic
60 62 67 can also be "correct"

So, without knowing the musical context/usage of these pitches, it is difficult to make the proper choice -> this means that it seems difficult to algorithmically make 'change-scale' function, which would perform satisfyingly in every situation.

Any ideas on this is appreciated!

[AnalogGuy1]

In general there are more harmonic rules than melodic ones, so your harmony choices will be more limited.

But this depends on what set of rules you want to apply; you're presupposing certain rules. Many people want some non-diatonic notes in the melody, and similarly you could choose to voice your C-Major chord with a jazzy flatted ninth. Either way you'd keep your 63, even in a major key setting. (Or maybe your C Eb G was an upper structure to an A half-diminished).

Probably best to first specify what harmonic and melodic rules you want to constrain things by first.

[jancivil]

Just wondering:

We have c-minor triad:
60 63 67

We try to put it to C-Major scale by finding closest pitches:
60, 62 is close and 64 is as close, 67
so 63 converts to 62 or to 64

If the context is harmonic/chordal
60 64 67 is "correct"

If the context is melodic
60 62 67 can also be "correct"

So, without knowing the musical context/usage of these pitches, it is difficult to make the proper choice -> this means that it seems difficult to algorithmically make 'change-scale' function, which would perform satisfyingly in every situation.

I have no idea at all what you're trying to say here. You want a C minor triad "put to" C major scale. MIDI notes 60 64 67 is C major triad. 60 62 67, C D G, is a "2 chord" or "sus2" on C. We have_not delineated C major by this. A number of times here I have seen this distinction between "harmonic" and melodic use as if in the abstract. Where are you getting that notion from?

C minor triad (NB: Eb) is not found in 'scale of C major'. Making this C2 chord does avoid the decision of which quality third, so it's ambiguous and as such one supposes it's more or less as happy in C major as in C minor.

"without knowing the musical context/usage of these pitches, it is difficult to..." make a musical decision? I guess so. There is no "correct" outside of all context with no use case whatsoever, there is no meaning to any of this. It appears you would like a one-size-fits-all mechanism obviating all thought in favor of a crutch. You know what, I don't really find such musical decisions a problem like that. I enjoy it. This "'change-scale' function, which would perform satisfyingly in every situation" is crap tho'. It looks like yet another case of fear of music & resorting to retreat into a comfort zone of maths reliance and the familiar. There is no 'harmonic intervals' vs melodic intervals, that whole notion will take us nowhere positive. It feels like someone notable in teh EDMs has talked about that and everyone believes in it now. Word salad.

[Dartelec]

Obviously I did not describe the problem context enough, so there may have risen some misunderstandings.
Sorry! (I assumed wrongly that everybody here in KVR are nerds like me making algorithmic music...)

My question makes sense only from viewpoint of programming algorithmic music functions. When making a tool for converting MIDI-pitches in certain scale/key to some other, user given, scale. One may for example consider Chord Track in Cubase - with functionality, where you can change scale and chord - resulting that original pitches in sequence are converted to these new scales and harmonies.

Developing such tools/functions (a task in which I am quite interested) is not very easy (as my original posting tried to show). But it poses interesting challenges;)

And in comment to previous answers: I am fully aware, that when human being is composing there are no 'rules' and 'functions' - Composers use much more elaborate strategies, musical knowledge and aesthetics in making decisions. Which is really fun and challenging in good way!

[Gamma-UT]

By stripping out note names and using numbers, you're making a rod for your own back because you've then got no reliable way of determining which pitch class maps onto the new pitch class. That's one problem. And you seem to be trying to do this without taking notice of the fact that 12-tet scales are built on intervals that are usually a semitone or two semitones apart. Aside from that, it's going to go great.

[Dartelec]

Gamma-UT, thanks for reply.

I really can not see how note names could give any more info than numbers. All MIDI numbers mod 12 are quite nice pitch-classes, hm (btw. pitch-class is serialistically loaded term)?

In conventional notation, and discussion thereof, note-names (e-flat vs. d-sharp) carry some assumption about current key. But that is just for convenience., not really usable info about the key or harmony.

And I really can not see either how the semitone-two semitones construction of scales relates to my original scaling function. Info about the scale structure does not help if you are trying to find nearest possible mapping and two pitches are found, which are equal distance apart:

63 -> 62 or 64 - distance 1, no help from scale-structure. Only thing which I really think could help to select proper pitch is some contextual info about the usage of the pitch (melodic, harmonic etc.), which is difficult to obtain or analyse automatically.

Instead of thinking rods, please buy yourself a strawberry ice cream! It makes thinking of music theory more enjoyable!

By stripping out note names and using numbers, you're making a rod for your own back because you've then got no reliable way of determining which pitch class maps onto the new pitch class. That's one problem. And you seem to be trying to do this without taking notice of the fact that 12-tet scales are built on intervals that are usually a semitone or two semitones apart. Aside from that, it's going to go great.

[Gamma-UT]

And I really can not see either how the semitone-two semitones construction of scales relates to my original scaling function. Info about the scale structure does not help if you are trying to find nearest possible mapping and two pitches are found, which are equal distance apart:

63 -> 62 or 64 - distance 1, no help from scale-structure. Only thing which I really think could help to select proper pitch is some contextual info about the usage of the pitch (melodic, harmonic etc.), which is difficult to obtain or analyse automatically.

Well, if you're using numbers and nearest-neighbour relationships, mapping from C harmonic minor to C major is going to give you a bit of a problem. Knowing the named note relationships makes it a snap to do.

Just trying to help. But this is your choice to make.

[peersh]

Using MIDI numbers for programming surely is the way to go as note names are historcally grown, partly ambigous and hard to handle in algorithms. But you should be aware of the fact that a scale like C major is more than a set of pitches. Each note of the scale has a role within harmonic or melodic constructions, a quality which you cannot measure by distance considerations which is a quantitative point of view. If you want to map one scale to another in a meaningful way you have to map one net of relations to another net of relations. To put it simpler: If you want to map a melody or triad from C major to C minor and have the MIDI note 64 then you have the C major "mediant", the third scale degree which should be mapped to its C minor counterpart which is MIDI 63 and nothing else. Your algorithm surely needs some additional information about the context (how does he get to know that he starts from C major?) as well as the structure of scales to perform meaningful mappings. Of course you can program algorithms which do numerical mappings of any kind but the result will presumably be a sequence of pitches who lost their musical sense.

[MadBrain]

Suggested algo: in the key of C:
C is the tonic
Db and D are 2nds
Eb and E are 3rds
F is the 4th, F# is more commonly augmented 4th
G is the 5th
Ab and A are 6ths
Bb and B are 7ths

Select the kind of 2nd, 3rd, 4th, 6th and 7th to match the selected scale
Major: major 2nd 3rd 6th 7th, perfect 4th
Minor natural: minor 3rd 6th 7th, major 2nd, perfect 4th
Minor melodic (going up): minor 3rd, major 2nd 6th 7th, perfect 4th
Minor harmonic: minor 3rd 6th, major 2nd 7th, perfect 4th
Mixolydian: major 2nd 3rd 6th, minor 7th, perfect 4th
Dorian: major 2nd 6th, minor 3rd 7th, perfect 4th
Phrygian: minor 2nd 3rd 6th 7th, perfect 4th
Lydian: major 2nd 3rd 6th 7th, augmented 4th

C++ pseudocode:

Code: Select all

int fitToScale(int midiNote, int scaleRoot, int scaleId) {
  int octaveStart = (scaleRoot % 12) - 12;
  while(midiNote - octaveStart >= 12)
    octaveStart += 12;
  int noteInOctave = midiNote - octaveStart;
  
  static const int scaleDegrees[] = {1, 2, 2, 3, 3, 4, 4, 5, 6, 6, 7, 7};
  int noteDegree = scaleDegrees[noteInOctave];
  static const int scales[][7] = {
    {0, 2, 4, 5, 7, 9, 11}, // major
    {0, 2, 4, 5, 7, 8, 10}, // minor natural
    {0, 2, 3, 5, 7, 9, 11}, // minor melodic ascending
    {0, 2, 3, 5, 7, 8, 11}, // minor harmonic
    {0, 2, 4, 5, 7, 9, 10}, // mixolydian
    {0, 2, 3, 5, 7, 9, 10}, // dorian
    {0, 1, 3, 5, 7, 8, 10}, // phrygian
    {0, 2, 4, 6, 7, 9, 11}  // lydian
  };
  int newNoteInOctave = scales[scaleId][noteDegree-1];
  return octaveStart + newNoteInOctave; //nb: this can output midi note -1 or 128
}

Nb: this is an algo for changing the scale of an already well performed melody, not for forcing okay sounding results out of someone playing random notes (in which case you'd probably want to make sure every white key generates a different scale degree, which means that in Bb major, playing B would generate Bb instead of the C that the algo above will give you).

[Dartelec]

MadBrain, I find our solution very nice and elegant! Thanks! I will convert that to UVIscript and try in my Falcon arpeggio thingy!

[Musicologo]

I've done quite a lot of similar stuff, and I'd say that your first step is to formalize tonality if you want to use tonality as a basis for your reasoning. Mad Brain pointed you in the right direction.

You'll have to define what tonality is, what is a scale, what is a chord... (and which ones make sense and not, etc...)...

First you need to build your context net, only then you can handle your objects. Take a look at Symbolic composer definitions and hierarchies and that might give you more clues or this paper by rohrmeier "Towards a generative syntax of tonal harmony":
http://www.tandfonline.com/doi/abs/10.1 ... 011.573676

[Dartelec]

Here is the MadBrain's code in Uviscript (Lua). Thanks again!
There was minor typo in the original c++ pseudocode: 4 instead of 3 in natural minor.

Thanks also Musicologo for interesting suggestion;) However now I stay with this simple functionality to enhance Falcon arpeggiator.

Code: Select all

scales = {}	
scales[1] =  {0, 2, 4, 5, 7, 9, 11} -- major
scales[2] =  {0, 2, 3, 5, 7, 8, 10} -- minor natural
scales[3] =  {0, 2, 3, 5, 7, 9, 11} -- minor melodic ascending
scales[4] =  {0, 2, 3, 5, 7, 8, 11} -- minor harmonic
scales[5] =  {0, 2, 4, 5, 7, 9, 10} -- mixolydian
scales[6] =  {0, 2, 3, 5, 7, 9, 10} -- dorian
scales[7] =  {0, 1, 3, 5, 7, 8, 10} -- phrygian
scales[8] =  {0, 2, 4, 6, 7, 9, 11} -- lydian
scaleDegrees = {1,2,2,3,3,4,4,5,6,6,7,7}

function fitToScale(midiNote,scaleRoot,scaleId)
	local octaveStart= (scaleRoot % 12) - 12;  
	--	print(octaveStart)
	while (midiNote - octaveStart) >= 12 do
		octaveStart = octaveStart + 12
		end
	--  print(octaveStart)		
	local noteInOctave = midiNote - octaveStart
	local noteDegree = scaleDegrees[noteInOctave + 1]
	local newNoteInOctave = scales[scaleId][noteDegree];
	
	return(octaveStart + newNoteInOctave)
	end

--Ascending integers 0 to 10 to C Major	
for k=0,10 do
	mynote =  fitToScale(60 + k,0,1)
	print(mynote)
	end
-- results: 60 62 62 64 64 65 65 67 69 69 71

--Ascending integers 0 to 10 to D natural minor	
for k=0,10 do
	mynote =  fitToScale(60 + k,2,2)
	print(mynote)
	end
-- results: 60 60 62 64 64 65 65 67 67 69 70