Only "proper" chord types in mir_eval.chord.QUALITIES
#397
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Following the discussion in #396 and thanks to @bmcfee insightful comments, this PR simply removes some chord qualities in
mir_eval.chord.QUALITIESthat are "unreachable" by the regexp in the same file.I.e., even though there the aforementioned
QUALITITESdictionary includes keys for theb9,#9,#11andb13chord qualities, these are "unreachable" from the regexp. This is for a good reason, since (agreeing with @bmcfee) writingC:#9is a bit odd - denoting it asC:7(#9)seems to be more proper.Even though this PR doesn't fix any error per se, it resolves an edge-case error that occurs if, for instance, someone wants to iterate through
mir_eval.chord.QUALITIESto get all possible chord qualities inmir_eval. Indeed, trying tomir_eval.chord.encode(C:#9)produces and error, but this error is expected to appear if, for some reason, someone tries to iterate through all qualities.This PR simply removes the four qualities that result in this errors in this edge case. Disclaimer: I haven't tested whether this change breaks some other functionality, but I believe it shouldn't, since any other such functionality would ultimately have to be related with the regexp that properly checks for nicely-formed qualities.
Thank you @bmcfee for the help and the clarifications!