bragefuglseth / fretboard Goto Github PK

The D chord is currently shown as a barre chord in the second fret. While this is expected behavior with the current codebase, it would be nice if it was displayed like most people actually play it.

The Bm chord is not displayed as people actually play it. Fixing this probably requires reordering the chord data.

Make it possible to search for chord names directly from the GNOME activities overview.

While the visual nature of Fretboard brings some limitations to how conveniently it can be used with screen readers, I believe that the current screen reader support isn't good enough nonetheless. The guitar neck spin button should at least have its value read aloud upon changing it. This would make the app accessible to those who can visually parse the chord pattern, but are unable to read the fret position.

GNOME 45 comes with Libadwaita 1.4 and a bunch of new, cool widgets! Of particular interest to Fretboard is:

• Toolbar View
• Navigation View

The migration should go relatively smoothly once we have updated the dependencies.

It would be handy to have a way to keep a list of chords to easily jump back to them.

(I would have opened a PR, but I couldn’t figure out how chords were sorted and where to add this new one)

Chord name
Emadd9

Current representation
None

Suggested representation

The chord data is currently stored in a monolithic JSON file (src/chords.json). This works fine, and I'm not planning on changing it, but it's impossible to manually edit the file. I have a Rust project stored locally that I use to inject changes into it, and it would be nice if this was turned into a little CLI for managing the chord data more conveniently.

The fret balls are not showing up

Steps to reproduce the behavior:
Just open up the software and try to see a chord

Expected behavior
The chord must have indication to where to press on guitar arm

Screenshots

Desktop (please complete the following information):

• OS: Linux Mint
• Version 21.1

Let's utilize the new fallback algorithm to make it easier to contribute chords to the database!

Here are the things needed to accomplish this:

• Database mode
• A system for mentioning when a chord should be added
• Guidelines for doing so with the database mode

Database Mode

A special mode the app can be started in that lets you add new chords to the database. Plot a chord into the diagram, let the algorithm identify it, and press a button to add it to the internal representation of the chord database. Save the database to a file again directly from the app, commit and open a PR. Easy peasy!

In addition to this, we should have a label appear in the app when the algorithm is used: "This chord is not in the database. Should it be?" The "Should it be" is a hyperlink to a section in the README here on GitHub that instructs on how to use the database mode in simple terms.

It’s impossible to draw chords that span more than four contiguous frets, even though they are not so uncommon. E.g. Every breath you take by The Police is well known for it’s add9 chords that require a 5 frets stretch.

Showing notes on the dots would not only help with learning, but also make it clearer that one is where they think they are on the fretboard.

Searching for different chords yields inconsistent positions for close chords.

Compare

to

The two should use the same starting fret as they are actually quite close. 1 makes more sense than 2 as starting fret to me.

Describe the bug
The bookmarks button has a border around it when toggled in high contrast mode.

To Reproduce
Steps to reproduce the behavior:

1. Enable high contrast mode
2. Bookmark a chord

Expected behavior
The button should stay flat and have its state indicated by the icon.

Screenshots

Pinging existing translators: @Gert-dev @phaerrax @ikibastus1

Fretboard is shaping up for the release of version 3.0 in 3 days, and it has recently gotten some string changes. It would be good if you could have a look at these. I can do a 3.1 release with the remaining translations if you don't have time for it right now, so don't stress.

Something to note is that the "Open" string that was a verb before is now an adjective. I've updated the comment to clarify that.

Translations are now managed on Weblate, which I hope will make it easier and more straightforward to contribute.

Thanks for your contributions!

It should be a dark brown, not... that

Describe the bug
Use the v on the right to move up the neck and hover over a fret position. A note will appear on the tooltip. This note is incorrect for the new position, it still shows the note for the “1” position.

To Reproduce
Steps to reproduce the behavior:

1. Hover over 5th string 3rd fret. Tooltip says C, which is correct.
2. Hit v till position is “3”.
3. Hover over 5th string 3rd fret. Tooltip still says C, when it should say D.

Running Fretboard 6.1 as from Flathub on Fedora.

The current codebase is really messy in places, both style-wise and structurally. I'll have to do some cleanup to make issues like #23 and #16 more realistically solvable. This would hopefully also attract more contributors in the future, lifting the maintenance burden a little.

Describe the bug
The horizontal alignment of the fretboard in relation to the chord input field breaks if the Large Text accessibility option in the gnome settings is selected.

To Reproduce
Steps to reproduce the behavior:

1. Open the Activities overview and start typing Accessibility.
2. Click on Accessibility to open the panel.
3. In the Seeing section, switch the Large Text switch to on.

Expected behavior
Same alignment as with the normal text size.

Screenshots

Have a way to view more ways to play the currently viewed chord. Not a blocker for the initial release, but should be added at some point.

The current chord that’s identified when this is done is technically correct, but not what I’d expect :)

Chord name
*add9

Current representation
As an example, for G#add9 it's 43x344.

Suggested representation (optional)
As in #10

This applies to multiple add9 chords. I need to set up some infrastructure to manage the chord data before solving it properly.

When editing the chord diagram directly, things switch up all the time, often resulting in an empty chord. Changing the chord diagram should not trigger any things changing it again at all.

Describe the bug
The chord:

is reported as Esus4#5. Technically correct (I=E, III=suspended, IV=A, V=sharp=B#=C).

I doubt anybody would transcribe the chord as that unless it's coming from a specific context (like a line cliché). Most likely it would be transcribed as "Am/E" or even just plain "Am".

I can try to fix it, but I guess the problem is not trivial and while the specific case can be easily patched, there are probably other such cases and/or any generic fix could impact how other chords are reported.

I'd love to see ukuleles, 4,5,6 string basses, 12-string guitars etc. to be supported!

A♯ and B♭ are the same chord, assuming you don't have a microtonal guitar. Both are understood as input, but only A♯ is shown when you select x13331 on the fretboard.

It might be nice to show equivalent names for the same chord.

In my experience it is quite rare to see it spelled as A♯, because an A♯ major chord is A♯-C𝄪-E♯. It can happen depending on the key you're in but in isolation… I'd call it B♭. Ditto D♯ / E♭.

Describe the bug

Only the symbols # and b are accepted as input, or displayed, in the chord entry, not ♯ nor ♭.

To Reproduce
Steps to reproduce the behaviour:

1. Click the ‘Chord Name’ entry
2. Type B♭

Expected behaviour

The chord x13331 is displayed.

Screenshots

Additional context

You can type ♭ with Compose # b and ♯ with Compose # #. No rational human would do this rather than just b or #, you might think, but it was one of the first things I tried.

Aesthetically I think B♭ and A♯ look nicer than Bb and A#.

If it were me, I would:

1. Accept these characters as input
2. Normalise any entered chord to use the correct symbol
3. For extra credit, accept 𝄪 or ## for double-sharp and 𝄫 or bb for double-flat.

Fretboard supports some common shortcuts already, but it lacks shortcuts for bookmarking, viewing variants and focusing the entry. These should be added.

No one looks at a guitar that way. Any tabulature out there displays it with the head of the guitar on the left as one would be looking at the guitar whilst playing.

The high contrast mode support needs some love. The toggle button outlines need to be removed, which is probably doable with CSS.

Better contrast between the fretboard backdrop and the window would also be nice. This requires doubling the amount of assets, unless the SVGs can be programatically recolored.

The entry should probably have a raised background, it’s confusing when unselected in its current state.

Probably out of scope, but would be cool to have a mode where the app shows you a chord and the person has to guess which one is it, to train memory of the chords.

Currently, the way chord diagrams are shown appeals to right handed players. As a left-handed player, this is confusing and it would be really nice to be able look at the chords as reversed.

Describe the bug
I'm packaging Fretboard for the archlinux-proaudio binary repo project (see osam-cologne/archlinux-proaudio#427) and noticed the build is not reproducible, even though both meson and rust are supposed to support reproducible builds. I'm wondering what's causing the diff in the resulting binaries.

To Reproduce
Steps to reproduce the behavior:

1. build the project twice using meson on the same build environment with SOURCE_DATE_EPOCH as a fixed value
2. check output checksums
3. run diffoscope to compare the individual results

Expected behavior
The resulting binaries should be identical

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Arch Linux

Additional context

• https://wiki.archlinux.org/title/Reproducible_builds

I’m used to reading chord diagrams rotated 90° counter-clockwise relative to how they are displayed in fretboard now.
Since that made it much easier for me to rad them quickly, I would suggest adding an option to rotate the diagrams (permanently).

I thought the Flatpak manifest handled this, but it has to be done in the app code.

First of all, thank you for this little helper - very much appreciated. :)

One feature that came to my mind was having a "show random chord" function, e.g., at app launch or triggered by a button/shortcut.

This would motivate (me) to learn new chords.