Guitar Tutor Design
I like to play guitar and like any musician I would like to play it much better. My music theory is reasonably good so last year I did a jazz course and picked up a bit of experience playing on stage. I'm not so good at improvisation yet and so I have decided to create a tool that will help me improve . It seems like a good idea for an OO project and so here it is.
Scenarios
Chord Chart Practice.
- The user loads a chord chart for the song they want to practice.
- The user presses the start button. After a short pause the program will count in two full bars then an indicator will start to scroll along the chart to mark progress in time with the tempo.
- The user plays notes on the instrument. These notes and their duration are recorded on the chord chart . Notes are coloured one colour for correct and another for incorrect.
- The chart is repeated X (default 3) times or until the user presses the start button a second time.
Chord charts can be of the form ABA, ABAC, ABB, etc. with repeats.
The first obvoius change is that Bar needs to be abstract with concrete classes for the first, last and intervening bars as well as a bar for the start of a repeated section and the end of a repeated section.
Chords can be of the form: Major, (Major7, Major6, Major6-9, MAJOR7#11), Dominant7, (Dominant9 Dominant13), Sus(b7), minor (minor7, minor9, minor11, minor13), Diminant#5/#9, Dominant#5/b9, Half-diminished, Diminished, augmented Major7, augmented7 and minor major7 to name a few. Not sure how to represent these yet. Maybe an enum, maybe a class hierarchy.
To implement the timing for the indicator to move across the chart a Metronome class must be introduced that will be watched by the Chart class. The Metronome class will have the Tempo and the TimeSignature to work out the Beat from. The Observer pattern might solve this timing problem.
Initially the chart will just be a simple text file but eventually the files will be in MusicXML and maybe other formats will be useful. The Strategy pattern would leave the program in a state that is easily extended in this direction.
Class responsibilities
Class Name | Class Responsabilities | Super Class | Collaborations | Notes |
Chart |
|
Bar, Tempo, TimeSignature | ||
Instrument |
|
Chart, Metronome | Is the note passed to the chart for insertion when it it begins creation or after the end has been detected? | |
Main |
|
Chart, Instrument | ||
Metronome |
|
TimeSignature, Tempo | Watches system clock.
The metronome is polled by Instrument when notes are created and observed by Chart so the chart is notified for each beat. Maybe a good candidate for a separate thread. | |
Tempo |
|
|||
Bar |
|
Note, TimeSignature, Bar | Abstract class. | |
Pitch |
|
There are only a handful of tones (12, 21 with aliases) and humans can only hear ten octaves.,
These two components may be represented flyweight or Enum idiom | ||
Scale |
|
There are only a handful of scale types. | ||
Note |
|
Pitch | The word note is used in Pitch making it a bit ambiguous so a new term must be found for in Pitch | |
Chord |
|
"Scale,the note component of Pitch(maybe Tone?) | Only using 7th, Major7th, Minor7th, Half diminished and Diminished chords this implementation | |
Time Signature |
| |||
Tie |
| |||
StartRepeatBar |
|
Bar | ||
EndRepeatBar |
or
|
Bar | ||
FirstBar |
|
Bar | TimeSignature | |
LastBar |
or
|
Bar | ||
NormalBar | Bar | Illnustrates the confliction tensions between Avoid concrete base classes and Eliminate irrelevant classes or maybe it is avoiding inheritance for implementation
| ||
LastBarEndRepeat |
or
or
|
Bar Maybe this should inherit from LastBar or EndRepeat or both | Maybe Multiple Inheritance is not always a bad thing looks like I have to break the Once and only once principle some might say Don't repeat yourself. I have a friend who once said Duplicate code smell. There is a solution I'm sure | |
FirstBarStartRepeat |
|
Bar Maybe it should extend FirstBar or EndRepeat or ideally both. | TimeSignature | See note for LastBarEndRepeat |
CRC Cards are COOL!
Further Problems:
- What should be done about isomorphic chords, scales, notes
- Can repeat be extracted to somewhere else? maybe the decorator pattern.
- Maybe the note type should be represented in a class hierarchy. What happens then with notes that are too big to fit into the remaining portion of a bar? What happens if the notes are added on creation rather than completion?
- should there only be one of each type of Note, Chord, TimeSignature? Flyweight
- How do I associate the chord changes with the right beat in the bar?
- What am I going to do about triplets?( do I need to do anything right now?)
- Is my use of enums adequate or is it just going to create unnecisary conditional hierarchies?
- Introducing the concept of a curser will help solve the problem of keeping track of drawing coordinates for positioning each bar.
- How am I going to implement the GUI here? I guess model view controller might be a good place to start looking.