🐛 BUG: Need a way to flip back and forth between chordpro and "chords over words"

[isaiahdahl]

Background & Motivation

We need to be able to flip between editing chordpro, and editing 'chords over words' which is basically just a text chord sheet as the library has it written.

When I implement a version of this in the editor, the behavior isn't what I'd expect. It doesn't go back and fourth nicely.

The ChordSheetParser doesn't do a good job of going back to the same chordpro that generated it.

Steps To Recreate:

1. yarn dev
2. Flip the chart to mode Chords Over Words
3. Flip back

Proposed Solution

I think that all this means is that we need to do some work on the ChordSheetParser so that it's going to generate the same chordpro that generates a text chord sheet. Which may be hard.

[isaiahdahl]

@martijnversluis Also curious for you're thoughts on this. Need to serve from the get-codemirror-working branch to recreate.

[martijnversluis]

Hmm, that's quite a question. So far there wouldn't be any way to keep meta data inside a "regular" chord sheet. There can be a few ways to solve this:

• come up with some syntax to store meta data in a regular chord sheet. It could be formatted as commented chord pro directives (// {t: Title}) or ini-file syntax
• store the meta data in memory and keep it synchronised with the chordpro if the current view mode is chordpro
• display the metadata in a separate section of the editor, and keep it in sync with the chordpro if any

What do you think?

[isaiahdahl]

So there's two parts to this for me, and possibly the meta data should be it's own task because it has some other business rules to meet. Metadata aside there still is some inconsistency with how the chordpro goes back and forth.

Metadata

As I said this could maybe go into it's own task but be linked here because I totally get how it doesn't really make sense to store meta data in a plain chord sheet.

---

^ though as I write this I had the idea about markdown style metadata where --- separates the meta from the rest of the document

title: What A Beautiful Name
artist: hillsong worship
key: D
---
Verse 1
D                                              G       Bm        A
  You were the Word at the beginning, one with God the Lord Most High
Bm                   A/C#       D               G         Bm      A
   Your hidden glory in   cre - ation, now re - vealed in You our Christ

Thoughts?

---

Ok But that aside. The other business objective we need to figure out that's metadata related is having a way to display the chart in the editor with the metadata "locked" so to speak. So very similar outcome to what you were saying about some other way to store the metadata and keep it in sync while editing in different modes and changing keys & capos etc.

This would obviously be something the editor could turn on or off depending on how it's initialized. But when we sell someone chordpro, and allow them to edit it, we don't want them being able to change certain directives, like the title and artists and copyright line. Obviously the key & capo would change, but we would prefer them to use the dropdowns in editor context over changing the metadata.

So I would think that the editor component is going to have some sort of prop for initialChordpro and then some equivalent to a lockMetadata prop. Then on load of the editor it's going to take the chordpro and 'sanitize' it (which would also naturally apply all the cleaning up of enharmonics and suffix's )and return chordpro into the editor that reflects the value of that prop. Same idea here could apply to other props like whether we want enharmonicsNormalizing or suffixNormalizing etc.

So then we need somewhere to keep that metadata, edit the chart as COW or ChordPro and still have access to all the metadata.

ChordSheet Parsing

I was still noticing the chordpro not go back and forth properly when I was using no metadata. Chords only lines was the first thing that I noticed it not doing right but even just the placement of the chord over the sylable wasn't exactly where it was before.

I'm going to have a dig through our current one and see how close it works. But I'm pretty sure it's pretty spot on going back and forth between modes.

So I think the questions here are.

1. Is the implementation (roughly) of how I'm currently switching between modes the best way to handle this switching of editing modes with the knowledge of what needs to happen with the metadata.
2. Do we want to store metadata in a chordsheet like markdown?
3. How are we gonna store metadata.

• what about some way that you more interact with the song object and store that in the editor state, and then you can update that object with either chordPro or chordSheet, and then maybe there's an option on the formatter that just won't return the metadata.

Anyway, big brain dump of thoughts here. Hope you're well!

[isaiahdahl]

Update:

ChordSheet Parsing

I found out about the preserveWhitespace on the chord sheet parser. Because it defaults to true it was looking very broken, but when I set it to false it looks a lot better, but there are still some inconsistencies. Pushed a commit to master with the preserveWhitespace set to false.

I think I'll write some tests to articulate what I'm thinking it should look like and then have you review from there.

[isaiahdahl]

@martijnversluis I created relevent issues in the chordsheetjs library.

• 💡 RFC: Optimize chord lyric spacing. Trailing Chords & chord placement ( ie: lyrics lyric[Dsus] ) ChordSheetJS#214
• 💡 RFC: ChordSheetParser to parse Sections headings as comments ChordSheetJS#217
• 💡 RFC: Pass metadata as it's own param to a parser, allow it to be hidden in formatters. ChordSheetJS#215
• 💡 RFC: Parse Metadata in a text chordsheet ChordSheetJS#219

---

P.S. I figured it's best to manage issues that are specific to the chordsheetjs library in that repo instead of this repo once they become specific enough. Even though issues can start from a sort of "bigger scope" issue like this one.