Fretboard diagram upgrade:

• Sep 7, 2015 - 22:18

I was looking at this post which gave me some ideas:

First off, the palette menu doesn't have many guitar chords, so we should include the most common chords in the palettes:
Open Chords: C D E G A Dm Em Am
Barre Chords: F B Bm F#m

Did I miss any that are important? I don't play barre chords much, myself.

Second: There is a minor glitch in the placement algorithm or whatever it's called. With most elements, you can hold shift and press left or right and the element will move along the staff, anchoring itself to whichever note it sits above. (Example, crescendos and diminuendos behave this way). I believe the chord symbols should, too!

I also have an idea of how to implement the fretboard diagrams to playback:

Interpret chords symbols like so:
g-chord.jpg
Note that the letters under the chord chart identify the names of the strings, not the note being played. The bass clef shows the actual notes the strings play (although we guitarists don't think of it that way, most of the time)

Musescore wouldn't have to guess at a billion different ways to spell a G chord if it just translated the fretboard to the actual notes of the guitar (basically, interpret it as a side-ways tab). Placing a fretboard diagram over a rest or note would replace that rest or note with a chord of the same length (in my drawing, a whole note). Of course, this would have to have an option to turn on and off. Or maybe set it so that it only replaces rests and leaves notes alone.

The fretboard diagram would, like a tab, check the staff properties for string data. That way, a Ukulele chord symbol would play differently than a Mandolin chord symbol, as of course it should. This already works for tabs, but a more common way to write out chordal music is with chord charts and rhythm figures.

Finally, a couple expansions to this idea: have the diagram check the staff properties for transposition, setting the capo appropriately, or add a text property that alters transposition (Write out Capo 2) and transposition goes up 2 half-steps.
Add a feature to easily move barre chords up and down.


Comments

I'd be happy to make all the fretboard diagrams listed above myself. Then a dev can just drop them into a nightly.

Also, I don't want to be misinterpreted as to seem unhappy or ungrateful, I'm psyched that Musescore is great as it is and now that it does tabs my days of counting half steps from open note are over (although it served as great training for when I started playing bass). I use the tabs all the freakin' time and am really happy with them. My suggestion for the playback of fretboard diagrams is merely in order to present a practical solution to implementing them in playback, one that I hope doesn't include too much difficult new code. The last thing any of us want is for MS to have a ridiculous spaghetti code... Of course the NOTATION part is already there, and that's all we really need! I just wanted to start throwing ideas around.

Actually, most elements do *not* reattach to other notes as you move them, and in fact many people find it a major nuisance that the few exception do behave that way. It makes it hard to fine tune position of dynamics, for instance, using the mouse. So I usually recommend on use the keyboard. I think you might be confusing this with how the *endpoint* of *lines* can be moved. This is a common operation and needs to have an easy way of doing it.

It isn't clear why you'd often need to move a fret diagram to a different time position, though - that seems like it would be a pretty uncommon operation. But anyhow, as with many other elements, you can move one simply by Ctrl+X to cut, click the deisred new location, Ctrl_V to paste.

In reply to by Marc Sabatella

I do use the keyboard, and I think I specifically wrote "hold shift and press left or right... like a crescendo". I guess I meant endpoint though. That's what I was thinking of.

I guess I just expected all of the elements to behave the same way, thinking it was an error when they didn't. Well, glad that's cleared up!

In reply to by joseph.branden…

Right. If you think about it, the ability to change a line's endpoint is a very fundamental requirement, because otherwise, well, how you you control it? Depending on how you add lines - drag and drop used to be the only way, although as of 2.0.2 double click works too - you might likely have to change the majorit of the line endopiints because it won't be right at first. But changing the *start* point happens much more rarely - because basically it would only be needed if you made a mistake adding it in the first place. And other elements are much like this - one normally only needs to change the attachment point to correct a mistake. But fine tuning the position happens all the time. Hence, dragging does the latter, not the former - except, unfortunately in my opinion, for dynamics.

Do you still have an unanswered question? Please log in first to post your question.