search

newlandsvalley / chord-editor

UI for generating simple chord diagrams for guitar, bass and piano
MIT License
9 stars 3 forks source link

Note names on fretboard #11

Open jgarte opened 2 years ago

jgarte commented 2 years ago

Might be cool to have note names rendered when you click on the fret or do you think it would be bloat?

Some perl inspiration:

https://github.com/mizlan/guitar-scale-chart#readme

newlandsvalley commented 2 years ago

It would be useful for a user to see the note names associated with a fret, but I have a couple of problems with doing this:

How about considering doing this when the mouse hovers over a fret/string or nut/string intersection and removing it when the mouse is moved away? Would this be possible?

newlandsvalley commented 2 years ago

But on further reflection, maybe having a MouseOver action in Page will be computationally too expensive.

jgarte commented 2 years ago

I was thinking more of something roughly like this where the note name information is in the svg dots themselves:

chorddiagram3_changed

instead of having solid color dots with no note information:

chorddiagram4_changed

Do you still think that the former picture above with the note information will make the UI look cluttered and make it a difficult user experience when clicking?

One possible approach would be to support both types and make the various fret dot styles a type or value that the developer can assemble when using parts from the chord-editor component library.

That way, developers can choose to use the note name dots or the solid dots or a third type with interval information:

guitarchord2_modified

or a fourth with fingering information:

guitarchord1_modified

newlandsvalley commented 2 years ago

Oh, i see. I have no objection to your first picture, particularly if we allow the user to toggle between black dots and dots with the note name. We can also make the whole display larger if we like if we needed more space inside the dots to write the note name clearly.

I have problems with the third type. It seems to me we would need to ask the user to supply the fingering or the interval information.

I realise that you are looking at this as a (possibly extensible) library but I still see it predominantly as an application to generate chord shape diagrams with a fixed UI. If you want more of a toolkit approach, it seems that we'd have to detach the UI controls from the update of the diagram. i.e. I think we'd probably have somehow to put the diagram inside its own Halogen component and presumably fit it with a set of actions for the different types of labelling that you propose. I'd have to give this more thought.

newlandsvalley commented 2 years ago

And as for note names, I think we will have to devise a strategy for which enharmonic to use (e.g. F# or G♭). We could work it out from the root I suppose, but we don't have it.

jgarte commented 2 years ago

And as for note names, I think we will have to devise a strategy for which enharmonic to use (e.g. F# or G♭).

What if clicking the fret toggles between the sharp or flat enharmonic equivalent fret dot? If the note is natural then there is no toggle. Although, I can see music theorists cringing at the assumptions of this proposal. Just a first idea ;()

jgarte commented 2 years ago

I have problems with the third type. It seems to me we would need to ask the user to supply the fingering or the interval information.

Maybe we can have the user toggle between the 4 fingering possibilities here but I can see how that might get annoying... Tooltip drop down with the 4 number choices to select from? We can also not implement the third type if it makes things too complicated ;()

jgarte commented 2 years ago

I realise that you are looking at this as a (possibly extensible) library but I still see it predominantly as an application to generate chord shape diagrams with a fixed UI. If you want more of a toolkit approach, it seems that we'd have to detach the UI controls from the update of the diagram. i.e. I think we'd probably have somehow to put the diagram inside its own Halogen component and presumably fit it with a set of actions for the different types of labelling that you propose. I'd have to give this more thought.

No rush on that idea. I was mostly thinking out loud. We can keep the next stuff to work on really simple. It was mostly an idea I had but I haven't really worked out what it means concretely or if it is even practical.

newlandsvalley commented 2 years ago

What if clicking the fret toggles between the sharp or flat enharmonic equivalent fret dot? If the note is natural then there is no toggle. Although, I can see music theorists cringing at the assumptions of this proposal. Just a first idea ;()

Yeah we'd have to think this through. At the moment, clicking once adds a black dot, clicking again removes it - so there would be different UI behaviour between black dot mode and named-note mode. Also, I'm concerned anyway that there is nothing to guide the user on how the UI works - they just have to click away and see what happens. I like the simplicity of things as they stand but this won't last if we over-complicate it.

newlandsvalley commented 2 years ago

Maybe we can have the user toggle between the 4 fingering possibilities here but I can see how that might get annoying... Tooltip drop down with the 4 number choices to select from? We can also not implement the third type if it makes things too complicated ;()

I must say that I'm not a huge fan of showing the fingering anyway. I've seen people play Am on the guitar quite happily but they swap their second and third fingers. I tend to use my thumb on the bass string when playing a D chord...... And it's beginning to sound messy to me.

jgarte commented 2 years ago

I must say that I'm not a huge fan of showing the fingering anyway.

I also rarely follow the fingerings in chord charts and use my own fingering preference.

What do you think of the first option with the notes names on the fret dots? Should we try to pursue implementing that feature?

newlandsvalley commented 2 years ago

I'd be very happy to experiment with this if we can find a way to solve the enharmonic equivalence issue without over-complicating the UI or making it less intuitive. The best that I can think of at the moment is a dropdown with black dots (the default), note names with sharp enharmonics and note names with flat enharmonics. Not very impressive, I know.

Another option might be to split the chord name input box int a root and the rest (not sure what we would call this). So for example, C#M7 would have a root of C# which would be taken from a dropdown (default C) . We could then work out which enharmonic to use. Not really sure how we'd handle minor chords - we'd need to convert these to the relative major before working out the enharmonic,

newlandsvalley commented 2 years ago

I'm also interested to know how you plan to label the barré (if at all).

jgarte commented 2 years ago

I'd be very happy to experiment with this if we can find a way to solve the enharmonic equivalence issue without over-complicating the UI or making it less intuitive. The best that I can think of at the moment is a dropdown with black dots (the default), note names with sharp enharmonics and note names with flat enharmonics. Not very impressive, I know.

I'm not super excited about that one. I think I prefer the simplicity/elegance we have in the UI currently to that idea but maybe I just have to see it ;()

Another option might be to split the chord name input box int a root and the rest (not sure what we would call this). So for example, C#M7 would have a root of C# which would be taken from a dropdown (default C) . We could then work out which enharmonic to use. Not really sure how we'd handle minor chords - we'd need to convert these to the relative major before working out the enharmonic,

I'll have to think about this one more to visualize it better. I'll respond again later.