| Author |
Message |
bachus

Joined: Feb 29, 2004 Posts: 2906 Location: Up in that tree over there.
Audio files: 5
|
Posted: Sun Jan 10, 2010 6:33 am Post subject:
Accidentals and embedding domain knowledge Subject description: in the representation of a Key |
 |
|
Accidentals and embedding domain knowledge in the representation of a Key.
I have constructed a mapping between midi values in the context of a given mode and key and the first order significance of the accidentals, sharps and flats, that may be applied to the scale degrees of the key.
The C# code below is an untested (un-executed) first draft. Here it is shown as a method of some class. It will be abstracted out very differently when fully defined. As is it should give a good idea of what I mean first order significance.
To be useful a symbol such as, Symbol.AppliedDominantLeadingTone, must be embedded in other code, such as chord progression generators. And we would expect this symbol to be semantically linked to one or more flavors of tonality.
This is another reason that Modes were not made extensible. I have yet to decide on how I am going to handle high level extensibility that will allow such things as dynamically loadable/definable objects. But clearly one would like to be able to add new modes and modal "flavors" with out resorting to the low level extensibility feature i.e. writing and compiling (the OpenSource) C#
Any thoughts on any of this?
Edit:
I should explain that _sharpAttribute/_flatAttribute means a ScaleDegree raised or lowered by a semitone. Depending on the key the actual accidental might be a double sharp or double flat. _________________ The question is not whether they can talk or reason, but whether they can suffer. -- Jeremy Bentham |
|
|
Back to top
|
|
 |
plagal
Joined: Dec 28, 2007 Posts: 18 Location: South Carolina
|
Posted: Sun Jan 10, 2010 10:50 pm Post subject:
|
 |
|
I may not be understanding, and I'm not much into the C language, but are you basically mapping the midi values to the 12 tone values (1..12) they belong to, and also the sharps or flats needed to represent scales and modes, which has scale numbering (1..7) which is like every-other for 12 tone numbering(1..12), hence the need to figure out the sharps or flats - if we stick to 12 tone numbering, its no problem.
Scale modes are basically these numbers floating to any scale degree, and can be used to harmonize the scale with chords - like Bm or Bm7 comes from the 2nd (dorian) mode of C Major scale. If any major scale has the formula 1 2 3 4 5 6 7, we can convert that to the 12 tone format: 1 3 5 6 8 10 12. So now we can do some math on it without dealing with sharps and flats. To get dorian out of that, 3 becomes 1, and 1 becomes 11, and so on… a simple algorithm should cover all the modes. The same thing can be done for chords formulas. This way we ultimately can generate lists of chords given a selected scale from just a data base of chord and scale formulas, for example, or get midi values out of chords and scales.
To use letter notation(sharps vs flats) in these lists, instead of numbers, is the problem. You can an array of strings that are indexed 1..12. Two arrays are needed: one that lists the sharps(C‘,‘C#’,…), and the other the flats(’C’,’Db’,….). But knowing when to use which is a problem that only gets bigger as you get into the altered scales (some even have both sharps and flats). Some programs just use sharps as the defalt notation, with flats as the other option. If there was a means of calculating the ‘sharp verses flat’ notation problem, I‘d like to know myself. What does your data base consist of? Will your project arrange midi values without much user intervention? |
|
|
Back to top
|
|
 |
bachus

Joined: Feb 29, 2004 Posts: 2906 Location: Up in that tree over there.
Audio files: 5
|
Posted: Mon Jan 11, 2010 6:50 am Post subject:
|
 |
|
| plagal wrote: | | What does your data base consist of? Will your project arrange midi values without much user intervention? |
I am not sure what you mean by "arrange midi values." My system is notation centric rather than midi centric. It is to create music as score, But the pitch object class includes the midi value and makes use of it. Sharps and flats in the various flavors of tonality are generally used by composers to indicate key center and harmonic function. The reverse process, deriving key and sharps and flats from midi, seems to have become part of modern functional analysis.
Here is an interesting approach. Though personally I don't have a lot of enthusiasm for heavily statistical approaches to music for either analysis or generation I wouldn't deny that it has some utility. But I find current functional analysis too reductive for my needs and plan to pursue the creation of a multidimensional model of key center and harmonic function.
The code above creates a table that suggests how an accidental in the context of the major mode should fit into a particular flavor of tonality and as such cannot be used for analysis unless one knows before hand that the music is in, or should be in, that particular flavor. _________________ The question is not whether they can talk or reason, but whether they can suffer. -- Jeremy Bentham |
|
|
Back to top
|
|
 |
|