It seems that Travis CI is failing to download the binary needed to test. This means that any tests via Travis will automatically fail. We should check back on this when it seems that people are encountering issues.

Some people have found issues, like this one. It seems that the build is failing for releases past 1.4.9.

We use a pattern like this:

    forAll(for {
      scale <- majorPentatonicScaleGen
      octave <- Gen.chooseNum(-10000, 10000)

This can be simplified to a generator, so we should consider adding one.

We need to have a note generator that generates letters and a single type of accidental for scales, keys, and chords.

Currently, we use this pattern:

val minorPentatonicScaleGen: Gen[MinorPentatonicScale] = for {
    letter <- NoteTest.noteLetterGen
    numOfAccidentals <- Gen.chooseNum(0, 1000)
    accidental <- NoteTest.accidentalGen
  } yield (...)

which can be refactored into a generator that does this for us

One interesting feature that can be added to this project is the separation of data and functionality. As this post explains, type classes are a great way to do that. Since this project is a hybrid of learning music theory while also incorporating Scala/FP related concepts, I think it would be a great idea to consider migrating some classes into type classes to understand the concept

One interesting thought I had about the intervals:

When we use MajorInterval(Note("C").get).third, we expect Note("C####").get. We obviously want to correct for this and make it an "E" if the user desires to do so. However, this raises an interesting question: When should we do that? And how do we define correctness? Say we're in the key of "C##" (extreme edge case, but possible). How should be approach negating such a term?

How should other intervals like MinorInterval be used as well? Currently, we see MinorInterval as Note("C###").get if we were to use the previous example, but would it make sense instead to base it off of the MajorInterval?

[x] Major keys
[ ] Minor keys
[ ] Code abstraction between major and minor keys

We will need to update the logic here to trim the time on the scales. To account for this, we will probably need to optimize various code components.

Related tasks:
#36
#35
#34

This might be a little too ambitious now, but we're approaching a point where the property-based testing of the project is accumulating on the testing end. This has a notable hit on testing time when we increase the sample sizes as in 33759c5, but is not too large of an issue just yet. However, as the project scales and substantially more property tests are added to the project, it may be worth looking into parallelization to reduce the time spent waiting for a single test to run.

Example of how to parallelize tests

One really cool feature I saw in mingus was the ability to "guess" a chord based on a list of tones. While this might something we implement as a huge feature later on, I wanted to jot it down so we have this issue tracked

All the work up until now has been focused on harmony, which while necessary, does not fully convey everything expected of music. We should add measures, beats, and rhythm when given the chance

Related #29

Some of our scale and key generators only have a natural letter generator, but this does not account for other valid keys/scales. We should fix this and verify that property checks still pass.

While triads have been added, we did not add seventh chords. Those should be added

Similar to #14, we should move this method out of the key itself and into a MajorScale and NaturalMinorScale class. This is currently in the key class to add additional sanity checks as properties of keys

The current seventh chords in the project only account for tertian seventh chords, which should capture many of the chords that we are concerned about for now.

One chord we could consider adding is the augmented augmented seventh chord, which is rarely used but is technically a chord.

There are a LOT of magic numbers floating around (particularly in property tests) that are just representing 1 and 2 for half and whole steps respectively. While somewhat understandable, it does ruin readability to a degree. We should add constants to ensure that these magic numbers are removed

Currently, the tests for the project are basically littered with Option.get() calls because we know that the creation of an object will work, but there's no other way to access the actual object. We should refactor these calls to use OptionValues, as well as clean up some of our generators

We should add modes to the project

Some functionality in the Key class may be more suited towards being in some sort of Scale class instead. For instance, we have triads(), which are often reserved for scales as opposed to keys. We should create scales and migrate this functionality

Migration Guide

Extension chords may be a little more complicated, but basic extension chords like 9th, 11th, and 13th chords may be possible

One pattern I come across this project is the following:

 def apply(tonic: String): Option[MajorPentatonicScale] =
    if (MajorScale(tonic).isDefined) Some(new MajorPentatonicScale(tonic))
    else None

This basically assumes that if I can build it with a major scale, then it must be valid. However, MajorScale must be constructed, which then constructs a MajorKey. This is a concern for latency, since this means we are constructing a key over and over, which can be an expensive operation if the key provided is outside of the circle of fifths.

We should change this so that we are just checking to see if it passes the key regex.

A cool thought I had:

What if we were able to use implicit conversions to make some code look more elegant?

E.g., suppose we have the following:

"A#".distance("B".toNote)

as opposed to something like this:

Note("A#").get.distance(Note("B").get)

I think this would make the code look clearer to readers. We would have to define operations on Option[Note] to also remove the unnecessary .get operation, as well as to make it clear that we are not co-ercing a Option[Note] to Note all the time