When a single note is inserted, show its name

[waldyrious]

Maybe using different notation, to distinguish from the basic chord with that root. It may be worth to do some research on how other apps handle this.

[PedroGomes]

On the chord field? Wont that confuse the user?

[waldyrious]

Hence the suggestion to display it differently, e.g. in parenthesis or brackets, or something like that. Do you think that could work?

[PedroGomes]

I have working solution for this... Thing is, with the Musiq.js API we have, when we get the note and use the notation method, it outputs

<F♯3>

Dunno exactly what the 3 refers to The code that outputs it is MUSIQ.sharpNames[a.relPos()] + (!a.relative ? a.octave() : "" So it was something related to the octave, but I don't have the knowledge at this time to decipher this. I will look at this a little more later to see what does this means. Anyway, do we go with F3, etc etc ?

[waldyrious]

The 3 is probably the octave, i.e. the distance along the fretboard. I need to brush up on the theory again to get this 100% clear, though. The note itself is simply F or F#, so I would actually say we could omit the 3, especially since a chord can also be placed in many locations in the fretboard, and yet we don't distinguish them when presenting the chord name.

Would <F> look good to you?

[PedroGomes]

Yeah, ofc it looks good without the 3.

Question is do we truncate the string or can we change the original notation method/make our own. I will check this.

And, maybe not the best place but, down the road, do you want to gather this knowledge and do a proper lib instead of relaying on two different ones for similar things?

[waldyrious]

Question is do we truncate the string or can we change the original notation method/make our own.

Sorry, I don't fully get what you mean here. How do/could these two options look like, given the F3/F#3 example you gave above?

down the road, do you want to gather this knowledge and do a proper lib instead of relaying on two different ones for similar things?

Definitely. It may be best not to start from scratch, depending on the state of other libs. I'm planning on completing the comparison table and then looking at the implementation (i.e. algorithmic vs. hardcoded, etc.); if none of them matches what we need/want, we can roll our own; otherwise, it may be better to contribute upstream.

[PedroGomes]

Without touching the musiq,js lib the method we have, AFAIS, to show the note is the notation() method. This method will always output the octave or whatever that is. So, we either 1) take the output and cut the last character 2) Go to the lib and create a new method that does not append the last number.

I think I will go with 2 to save computation resources. This little tweaks and hacks is why I would prefer to have a new lib, not from scratch obviously, the musiq.js lib seems to have some good implementation with relative note position that we can study and take part of. And I dunno if we can contribute upstream to projects that seem dead for 2 years now, but let discuss that in another topic/issue

[waldyrious]

Sounds fair. As for collaborating with the projects, I can take up the task of contacting the lib authors and assess whether it's viable for us to contribute upstream. I'll open a separate issue for this.

[PedroGomes]

There was no need to add a new method... it was already there, I dunno how I missed it the first time.

[waldyrious]

@PedroGomes next time add "(fixes #33)" to the PR title, to get the issue automatically closed once the PR is merged :)