ChordType Overhaul

[maksutovic]

trafficstars

Expand ChordType with Comprehensive Chord Extensions and Shorthand Syntax

Overview

This PR significantly expands the ChordType enum by adding nearly all available and theoretical chord extensions. While there may be some esoteric chords yet to include, this enhancement greatly increases Tonic's ability to create and identify chords.

Please note: These changes are breaking. Be sure to update your code accordingly when upgrading your Tonic package.

Changes

Extensive Chord Extensions Added

• New Chord Types: Almost all known and theoretical chord types have been added to ChordType.
• Improved Functionality: This expansion allows for more accurate and diverse chord creation and identification within Tonic.

Adoption of Shorthand Syntax

Due to the unwieldy length of some chord names in the previous long-form naming convention (e.g., .dominantThirteenthFlatNineSharp11FlatFive), we've adopted a shorthand syntax familiar to musicians and readers of chord charts and lead sheets.

Naming Conventions

• Major ➔ maj
• Minor ➔ min
• Dominant ➔ dom
• Diminished ➔ dim
• Digits Instead of Spelled-Out Numbers: We now use numerical digits for chord extensions to optimize readability and manage complex types.

Example

• Previous long-form: .dominantThirteenthFlatNineSharp11FlatFive
• New shorthand: .dom13_flat9_sharp11_flat5

Breaking Changes

• Naming Convention Update: The shift from long-form to shorthand chord type names means existing code using ChordType will need to be updated to match the new naming convention.
• Action Required: Review and update your codebase to replace old chord type names with the new shorthand equivalents.

Testing

Given the substantial increase in available chords, we recognize the need for more extensive and deliberate testing.

• Contributions Welcome: We encourage contributions to expand the test suite to cover the new chord types.
• Testing Focus: Ensuring the correctness and reliability of chord creation and identification with the new chord types.

Acknowledgments

Huge thanks to @aure for his continuous support, brilliance, and enthusiasm.

[Matt54]

Ayyyyyyeeee thanks for this contribution! I only had time to quickly scan this for the moment but two things I noticed:

1. I think you got an extra file that snuck into this - Sources/Tonic/Chord.swift.orig

2. I don't think we should declare Codable on any of our structs or enums unless we need the conformance inside of our package. The reason is that, for example, in this case where you've simply changed the name of the enum cases on ChordType you've broken any past saves which used this. The consumer of the package can't override this (I guess they would need to make a wrapper struct for it to overcome the decoding problem - Chordable is in this boat as an application that uses ChordType within saved presets). I'm definitely open to hear the other side of this point. Maybe this is the Swift way of doing things - I know I've been seeing new warnings in Xcode 16 about conformances like these. But the way I see it is that because we don't depend on any particular encoding/decoding within our package we shouldn't enforce a strict way of doing so.

[aure]

This is obviously a great PR, but I won't accept until I make the tests pass (even if they will be incomplete).

[Matt54]

@maksutovic @aure since we're taking a look at this PR I just wanted to keep applying pressure on Codable here.

The raw value of our ChordType is a String. If you were to change the name of a ChordType enum case in the future then you would break the decoding of any encoding of that case that you have previously made.

IMO if we are set on introducing Codable conformances, we should use some stable raw value when we do it - such as explicitly assigning each case to a specific integer value.