moodymudskipper
commented
3 years ago In fact à lot of this was already done with the package tabr, it could be leveraged so we don't reinvent the wheel and pay respect to the great work that was done.
We might also consider a FR or PR to tabr if we have good alternate notation ideas.
https://github.com/leonawicz/tabr
tabr has the concept of tidy data frame too, but at the note level. I argued above that it is more interesting to have it at the bar level, but why not have both, we could have a utility to unnest (and renest) our bar strings into data frames for more elaborate data manipulation.
It's awkward to give them separately.
They could be given together in the following way but it's still cumbersome :
I think we could have a special format
So the above would be :
This would be readable in the data frame and make music much easier to transcribe.
We might provide alternate ways, for instance I like to count steps from a reference, so I'd write a guitar E chord like :
it would determine the mode from the key and reference, we'd use things like "5+" or "5-" to specify notes outside of the scale. This would look less good when notes are taken under the reference but still not too bad.
And bonus feature, if we could transcribe guitar tabs that would be nice, we could copy them from online sources, tweak them to make rythm unambiguous and feed them to the function.
we could also use tab notation so we could type E major in standard tuning using :
any tuning could be supported and tabs become very easy to transcribe with minimal theory knowledge
We do lose the clearly coded quantitative durations, but I don't believe we would have operated directly on them through mutate calls etc, so instead of 2 weird hard to read columns we get a clear one, and conversion to "[A5 C#5]o B5" or to currently format is always unambiguous.