Closed CookieComputing closed 4 years ago
I think there may need to be a change with regards to how we represent Notes, because the 0..16
plan actually has a flaw in that it forces us to make the assumption that a note will be sharp or flat if it's an accidental, but is that really the case? We lose all notions of what some of the more extreme keys represent (e.g. Cb
key), and this makes it a bit more frustrating to program against. Perhaps instead it would be smarter to take a leaf from how mingus
does it, and keep track of the note string itself.
Reopening #4 to address problems with the current design that are too rigid to elegantly solve the problem.
Stale issue after the Note
class has been redesigned, closing.
One challenge that the current design of notes related to #4 is how we could represent notes in a specific key. For example, if I were to take the perfect fifth of
Ab
, we would naturally expectEb
, but because of the implementation details from #4, we would actually getD#
! This doesn't quite make sense with respect to a key.This might need to call for another refactoring of the note class to accommodate for this issue since it's definitely a blocker. Alternatively, if we can come up with a sound design that avoids this problem, then there may be no need to change the note class.