Hi,
I have been using Earmaster 5.0 for about 2 months now, and I really love it. My progress has been slow, but verifiable (I can listen to simple melodies on a CD and play them "by ear"--before I was able to hear these melodies and sing them back vocally, but had a hard time playing them on an instrument).
While I am very happy to have the software and find it very useful, there are 2 important items that I think need to be addressed in the next version. These 2 issues, if corrected, will really improve the ability of the user to be prepared for hearing and identifying any piece of music.
(ISSUE #1) MOST important Issue that needs to be improved:
This applies to "Interval Comparison" and "Interval Identification"
When I do either of these 2 areas in Earmaster, and select either "Ascending" or "Descending" there is a problem. Basically, the program is supposed to play one note, and then a second note, and the user is supposed to identify the interval (or, in "Interval Comparison" the user should identify which interval is LARGER).
The problem is that the first note is sustained so long that it can still be heard AS the second note is sounded. In other words, the first note SHOULD be played more "staccato" but it is not, and the user can hear the first note STILL being played as the second note is being played.
So even though the program says it is giving "Ascending" or "Descending" intervals, it is as if the user is hearing the interval "Harmonically". This is a problem, because it can be VERY EASY to identify certain intervals (such as the Minor 2nd interval) when they are played together ("Harmonically"), and it is more challenging when you have to hear that same interval with the notes played totally separately.
Usually, when you listen to a melody on any music CD, whether it is jazz, classical, or rock, the notes of the melody will NOT overlap each other. In other words, the first note will STOP sounding, before the second note STARTS sounding. So your ear has to be ABLE to identify intervals based on sequential playing of the notes, it cannot depend on hearing both notes together, that is a form of musical "cheating" in a way.
So Earmaster needs to correct this so that when "Ascending" or "Descending" is selected, the first note is not audible by the time the second note starts playing. As it currently is, the user is "cheating" by being able to hear the first note sustain while the second note begins. This will not help them when they listen to any piece of real music, when the notes of the melody do NOT overlap each other (except in rare cases).
Real music usually doesn't let you hear the notes of a melody sustain as the next note is played, so the user must be able to train in a manner that simulates how real melodies are played.
(ISSUE #2) Very important issue that needs to be improved (but more advanced than the first issue mentioned above)
This applies to "Chord Progression Identification"
While the program is able to test the user by playing various "popular" chord progressions, and even lets the user submit their own chord progressions, there is one weakness.
The program does NOT allow the user to be tested on a totally "Random" chord progression. In many forms of pop or rock music, chords shift outside of the key, with no theoretical basis. Also, by allowing a "Random" option for the creation of a chord progression, you really make sure the user is able to hear ANY possible sequence of chords, which will make the user better able to identify any music harmony that they hear.
And I think that is the goal of Earmaster, to be able to prepare the user to hear and correctly identify any musical harmony (or melody or rhythm) that the user listens to.
To be even more specific, I think the program should have 2 options for testing the user on "Random" chord progressions. The first option would allow the user to list the EXACT chords to be used, and then the program would randomly play a sequence that uses ONLY the chords that have been given by the user. So if the user just lists 2 chords, the program will just randomly create a progression using ONLY those 2 chords (this would be the most easy way to use this option. Of course the user could select more than 2 chords. The user would just list the EXACT names of the chords (both their root note and type of chord), and the program would randomly select from that list to make a chord progression.
The second option would let the user set the Type of chords available (major, minor, Maj7, etc.), and then have the program play them in ANY order, beginning on ANY of the 12 notes. So the minimum number of chords for this option would be 12 (one TYPE of chord, which would be created for EACH of the 12 root notes). However many TYPES of chords are given by the user, the program generates a chord of each TYPE, for each of the 12 root notes. So this list would be a multiple of 12--if the user only gave one TYPE of chord, there would be 12 chords to work from, and if the user gave 4 TYPES of chords, there would be 48 chords to work from (one for each of the 4 TYPES and for each of the 12 root notes).
To make this clear, you would have 2 types of "Random" chord progressions: the first type would take a fixed LIST of chords given by the user, and the program would play them randomly, one after the other, beginning on any of the given chords, and continuing randomly. This would be a good test to make sure the user could hear any chord, no matter WHERE the chord is in the progression. So the user would specify the chords to be used (C, Dm, Em, F, G7, etc.), as many as you like. You could select the 7 chords that arise in any given diatonic key, or fewer chords, or more chords. The program would then take that EXACT list of chords, and randomly mix them up and play them to the user. The user would have no idea which chord is coming next, just that there are a certain number of possible options to choose from (however many chords were specified by the user). You could give as many chords, of as many chord types, as you want, but the program would use only those chords that you gave. So if you gave just the 4 chords of C, Cm, Fmaj7 and Emin7, the program could only play those 4 chords, in any order it chooses, and the user would have 4 multiple choice "buttons" to choose from, to select each of the 4 different chords the user has given. This would help the user recognize a certain selection of chords, no matter WHERE they are in the progression. It would be a fairly EASY test to ensure the user can hear a certain number of chords, and identify them accurately in a progression. You could list as few or as many chords as you wish to be tested on, so this could start off very easy (using a list of just 2 chords, such as Cmaj7 and Emin7) and get harder.
This first type of "Random" chord progression is a great way to drill the user on a certain number of predefined chords, where the user decides how few or many chords (and what types they are) to be tested on.
The second type of "Random" chord progression would be a more difficult test: the user would specify the TYPE of chords allowed (Maj7, sus2, etc.), and the program would play a random progression using ONLY those types of chords, but based on ANY of the 12 notes of the chromatic scale. So in this type of "Random" Progression, there are AT LEAST 12 possible options of chords. For example, if you say the only TYPE of chord allowed is the Maj7, chord, the program will play a Random sequence of the 12 Maj7 chords, one Maj7 chord based on each of the 12 notes of the Chromatic scale. The user would know that each chord is a Maj7 chord, but would have to select which of the 12 root notes it is based upon. There would need to be many multiple choice "buttons" for the user to choose--in the case where there is only one TYPE of chord, there would need to be 12 buttons, one for each root note of the chromatic scale. If there were 3 TYPES of chords (Maj7, min7, and sus2), then there would have to be 36 "buttons" to choose from (each of the 3 types could be based on any of the 12 root notes).
As you can tell, this second type of "Random" chord progression could be very difficult, as there are MANY options of chords for the program to play. For example, if the user puts in 3 TYPES of chords (such as Maj7, Sus2, and min7), there will be 36 total chords for the program to choose from (each of the 3 TYPES of chords can have the root note of the chord being any one of the 12 notes of the chromatic scale). This would be a very DIFFICULT test of being able to recognize ANY chord, no matter where it occurs in a chord progression.
This second type of "Random" chord progression is a great way to test for a large number of chords. IN Jazz or classical music, I know there are many cases where the chord changes are not within a certain key.
One other note: For either of these 2 types of "Random" chord progressions, the user should have an option for the program to either be able to re-use chords from the list, or to not use any chord more than once in the progression. In other words, the program should give the option of whether the same exact chord can be re-used in the progression, or if each chord in the progression should be unique, and not repeated at any time in the same chord progression.
I hope I have explained these topics clearly. I think that issue #1 (Interval Comparison and Interval Identification) is the most important, and the easiest to fix--just shorten the duration of the first note so that it is not still audible by the time the second note is played.
Issue #2 (Chord Progression Identification) is a bit more complex, but I think it is also necessary to really prepare the user to identify any possible piece of music that they might hear.
Just like "Melodic Identification" allows for a "Randomly" created melody, there should also be a way to have the program create a "Random" chord progression, whether the user gives a fixed number of chords to work with, or gives the various TYPES of chords (and the program uses those TYPES based on any of the 12 chromatic notes as the root note of each chord). This will really prepare the user for any chord progression that they might hear in a piece of music, and make Earmaster even more useful than it already is. Thanks!
Two Important Suggestions for Improvement (of Earmaster 5.0)
Moderator: Quentin
Thanks Quentin, I hope that Earmaster can incorporate these changes, and that the suggestions have been of use.
I have been using the program since mid-December (almost 3 months now) for about 10-20 minutes per day, about 6 days per week (I take a day off per week, so I don't get "burned out" on it).
I am able to sing just about any melody I hear, even some fast melodies, like by John Coltrane. I am also able to pick out basic melodies on my guitar, which I could NEVER do (except for maybe children's songs, such as "Mary Had a Little Lamb")
Just yesterday, I picked out the first few measures of "Giant Steps" (by Coltrane) on guitar! I was able to get the main melody, in maybe 5 minutes. What is awesome is that the melody is not limited to one "scale" or "key", it has some chromatic tones, and the second time the melody is stated, it is transposed!
Once Coltrane started improvising (after the first few measures, which just stated the melody), I was totally lost, being only BARELY able to sing his improvisation (and probably missing many of the notes, due to speed!).
So I have a FAR way to go, but it is awesome that stuff that 3 months ago was TOTALLY impossible for me, even if I spent an hour just using "trial and error" on guitar (which is FRUSTRATING!), I am now able to do in just a few minutes, without much strain.
Anyway, as far as the 2 issues I mentioned, I am sure they will greatly help anyone develop their ear, faster.
And while I do not know much about the Earmaster software, it seems that these 2 ideas will not need a re-writing of the basic functionality of the software.
Issue #1 can be solved just by limiting the length of the tones, so that they do not overlap each other.
Issue #2 can be solved by allowing the user to select "Random" and letting the program "Randomly" play chords, of the types allowed by the user. So it is basically just giving the user some more options when they do "Exercise Settings", which should not be too great of a challenge.
Hope these 2 changes are made to the next version, and thanks again for the software!
I have been using the program since mid-December (almost 3 months now) for about 10-20 minutes per day, about 6 days per week (I take a day off per week, so I don't get "burned out" on it).
I am able to sing just about any melody I hear, even some fast melodies, like by John Coltrane. I am also able to pick out basic melodies on my guitar, which I could NEVER do (except for maybe children's songs, such as "Mary Had a Little Lamb")
Just yesterday, I picked out the first few measures of "Giant Steps" (by Coltrane) on guitar! I was able to get the main melody, in maybe 5 minutes. What is awesome is that the melody is not limited to one "scale" or "key", it has some chromatic tones, and the second time the melody is stated, it is transposed!
Once Coltrane started improvising (after the first few measures, which just stated the melody), I was totally lost, being only BARELY able to sing his improvisation (and probably missing many of the notes, due to speed!).
So I have a FAR way to go, but it is awesome that stuff that 3 months ago was TOTALLY impossible for me, even if I spent an hour just using "trial and error" on guitar (which is FRUSTRATING!), I am now able to do in just a few minutes, without much strain.
Anyway, as far as the 2 issues I mentioned, I am sure they will greatly help anyone develop their ear, faster.
And while I do not know much about the Earmaster software, it seems that these 2 ideas will not need a re-writing of the basic functionality of the software.
Issue #1 can be solved just by limiting the length of the tones, so that they do not overlap each other.
Issue #2 can be solved by allowing the user to select "Random" and letting the program "Randomly" play chords, of the types allowed by the user. So it is basically just giving the user some more options when they do "Exercise Settings", which should not be too great of a challenge.
Hope these 2 changes are made to the next version, and thanks again for the software!
It's indeed like you say. It's just a question of integrating these options in a functional way.
You should see the list of planned improvements we have made....it's huge!
And more are to come.
V.6 won't come before a couple of years though, so there's plenty of time to sort out what will be best to integrate to it.
You should see the list of planned improvements we have made....it's huge!
And more are to come.
V.6 won't come before a couple of years though, so there's plenty of time to sort out what will be best to integrate to it.
- Because in Music, We're All Ears... -
I just noticed that you said these improvements might not be able to be put into Earmaster until Version 6.
Does that mean that these improvements CANNOT be added to the Mac version of Earmaster (scheduled to come out by the end of 2008)?
I am hoping that these 2 suggestions will be added to the Mac version, as I do not think they are that difficult to incorporate into the program. Also, I am very sure that EVERYONE will benefit from these 2 changes, ESPECIALLY the first suggestion, to make it so that the tones do NOT overlap each other.
Does that mean that these improvements CANNOT be added to the Mac version of Earmaster (scheduled to come out by the end of 2008)?
I am hoping that these 2 suggestions will be added to the Mac version, as I do not think they are that difficult to incorporate into the program. Also, I am very sure that EVERYONE will benefit from these 2 changes, ESPECIALLY the first suggestion, to make it so that the tones do NOT overlap each other.