beaunouvelle / swiftyguitarchords Goto Github PK

Adding a new property for isMajor, isMinor, etc, to the Suffix enum.
These could then be used for filtering based on grouped attributes.
i.e. maj, maj7 etc, could be grouped together under isMajor.

Devs could then create NEW filters for chord search.

Support for Solfege perhaps?
Not a necessity, but could be a nice option for folks who are more used to scales pronounced in this way.

I understand that in MOST languages with musical terms they tend to still use the Arabic numbers and major/minor style of writing.

If I'm wrong on this, please let me know and add examples in the comments.

Add a new function that fetches the latest chord list from this repository. This can be optionally called by consumers of the library.

Fetching and caching the latest chord list could be helpful for apps that don't update dependencies as often and allows library maintainers to fix issues with incorrect chords or add new ones quickly.

Add support for a number of different tunings.

Would this require a new chord database for each, or could we recalculate each chord at runtime?

Hi BeauNouvelle,
This is a great resource! I'm going to use it in one of my apps for learning chords. What did you use to populate the json file for the chords?
Regards Gerard

Currently the drawing system is coded for 6 strings, but I think it would make this library far more useful if it could also support Ukulele chords too!

See #12 for discussion on this.

Currently the library uses the RawValue of the Key and Suffix properties on a chord for the name drawn above the chord diagram.

The library now supports other naming variants, so it makes sense to give developers the option to choose from these variants.

This will need to remain backwards compatible. I suggest adding this to the parameters of the current drawing functions, hardcode (and deprecate) the proxy functions to pass in RawValue, and create a new public function that accepts a new enum for these titles.

Another option is to allow developers to add any text they like to the chord names. Discussion?

At the moment all chords are kept within a single file. This requires all of them to be initialized at once, and searching through this list can be slow on older hardware.

Ideally the data would be categorized into separate areas, or perhaps managed in an actual database.
Until then, we can split the data into sections as follows:

Instrument > Key > Suffix

The reason for why this wasn't done before is that some users of the library may want to search based on a suffix, rather than the instrument. This definitely needs to be considered.