Extend available chord types and change chord initialization

[zeagler]

The framework is in place to easily add many more chord types. To make it simpler we can combine the existing methods add${chordtype}Chords and take in the equation to create each chord type.

• [x] combine current chord array builder methods - addMajorChords, addMinorChords, addDominantChords
• [x] take in the equation as a variable, eg if we add Major chords somehow we pass note, note + 3, note + 7

EDIT: all of this is changing, a la @tstone95. don't make chord changes without his okay. When adding a chord type you must complete each of these items:

• setUpGUI.java > loadSpinners: add the line chordHandler.addChords(${chordEquation}); to the if statement when all chord checkboxes are selected
• setUpGUI.java > loadSpinners: add an if clause to create just that chord type if all are not checked
• fragment_options.xml: create a checkbox for the chord type
• chords.xml: append the chord name to the string array
• OptionsFragment.java: add a checkBox declaration, a boolean function returning isChecked, a setChecked method, checkbox listener, assignViews/updateEnables/Options entries
• (uncharted territory (for me, ask @tstone95)) If the chord uses four or more sliders enable the necessary sliders, otherwise only use slider 1-3.

Chord Types To Add:

• [x] Augmented triad
• [x] Diminished triad
• [x] Diminished seventh
• [x] Minor seventh
• [x] Minor major seventh
• [x] Major seventh
• [x] Augmented seventh
• [x] Augmented major seventh

IF we add more sliders

• Dominant ninth

[zeagler]

@tstone95 I saw in your log that you were working on part 1. Did you make any progress? I was going to look at this part over the next few days, but if your almost there I'll do something else.

[tstone95]

I am currently in the middle of setting everything up for use with multiple chords. The old system had a lot of hard coded references to the three chords we used to have (my fault), so there is a surprising amount to change. I should be finished this weekend, but a lot will be different. I will probably commit to my own branch before updating the main branch.

[zeagler]

Not your fault at all, I made the blueprints of the "current system" back in September as a proof of concept. I didn't expect it to be the base of the app...

Thank though, I'll move on to soundHandler related issues.

[tstone95]

The system is all in place to be able to add more chords very easily. Currently the changes are on my branch only.

Here is basically how it works:

• There is an enum in the Chord class where you add what Chord types you want. For each you just specify some labels and the offsets between notes in the chord.
• The types will be automatically accounted for in the options and score pages.

[zeagler]

I'm looking through your previous commit and I have a few questions and comments. I see you're rewriting a lot but I can't tell what your doing. The playback, pitch bending, and slider allocation will probably need to be reverted. (Unless you have a reason for the way your doing it)

Comments:

1. Don't use fractions to decide pitch bending. There is is no framework for which that will produce a correct tone (or note for that matter) and trying to create it is going to be a big headache. (for you. I won't do any support with fractions)
2. You only needed to give chordHandler an array of ints, it will sort out the sliders, the pitch bend, and the inversions for you.
3. To that end don't use "spellings" of chords. They are unnecessary (and not even a real music thing), we just want the proper chord.

Questions: Is there any reason we need a Note class? As far as we care they are only constant integers. We don't even care about their names, aside from naming a chord by the root note. Is there a reason you're trying to rebuild the pitch bending feature? We have a 100% working implementation of pitch bending that works independent of chord type. Did you remove some of my changes earlier today or were they lost in the merge?

[tstone95]

Perhaps I don't fully understand pitch bending. Here is how I have been interpreting it from what I have read about Midi files online: The purpose of pitch bending is to get intermediate pitches between notes; to accomplish this, we want the option for our sliders to have intermediate positions between notes. I added support for these positions (Currently hard-coded in the options class; you can change the constant (DEFAULT_SLIDER_DIVISIONS_PER_NOTE) to see how it works in the app).
So to get the intermediate pitch, we can use the fractional distance of the slider between two notes to calculate the pitch bend (for the Midi file). This is what is implemented now, with the Note class. The Note class keeps track of what note the slider is positioned on. It has the nearest note (as an integer) as well as the fractional distance to that note (to account for intermediate slider positions). In the soundHandler class you can see how I was getting the pitch bend from the Note. As far as I could tell it was valid, but if you want to hear it, set the value of that constant above to something larger than 1 (10 is good). I think the bulk of the changes I made (besides adding more chords) was making the sliders able to have intermediate note positions.

I did not realize that 'spellings' were not what we wanted but that is easy to fix.

I updated the pitch bend feature to accommodate the intermediate slider positions. Unless if I misunderstood the old version we couldn't move the sliders between notes.

[zeagler]

We do have the means of moving sliders in between notes. See cc0e92f for the latest working commit. It doesn't use fractions, it gives each note a range and absolute position. ie C = 1->8, actual C = 4, then computes the pitch on the range given the distance from the actual note. If the progress is 1 we are bent 3 steps down.

Your understanding of pitch bending is correct, we want to get out of tune notes. However using fractions introduces confusion (it actually wouldn't be a headache). An in-tune pitch bend is 8192, a whole note up/down is +/- 4096. Keeping that in mind: a working equation, the one we are using now looks like:

note = progress/intervals + offset;
pitch = 8192 + (4096/intervals * (progress%intervals - correctNote%intervals));

if 4096 is a different note, this equation will give us equal distance pitches between every note on any interval we give it. Fractions can accomplish a similar end, but there is no need to complicate it further.

The spelling of a chord is a way to visualize moving the notes. The chord spelling should always be equal to the proper spelling regardless of inversion or pitch changes. If inversions are requested they should be dealt with in chordHandler when the chord is selected.

[tstone95]

The system for adding more chords is back in place, we just need to add the different types.

[zeagler]

+1 again on new modular system.