Sub-beat chord durations

[phatmann]

Many songs have passing chords that have a duration of an eighth-note. For example, Elton John's "Don't Let the Sun Go Down On Me". For ChordMark to support that, we would need a way to notate smaller units than a beat in the lyrics and the chords. Has this been considered?

[phatmann]

[phatmann]

Glad you like it! What's the next step? Should I make a PR, at least for the docs?

[no-chris]

Let's sleep with it for a while and experiment with a few transcriptions

C.. G.. Am. {Am Am/G} F..
When I _find myself in _times of trouble, _Mother _Ma_ry _comes to me
C.. G.. F. {C/E Dm7} C..
_Speaking words of _wisdom, let it _be

=>

       |C             G                 |Am.   (Am Am/G). F.. |
When I find myself in times of trouble, Mother Ma  ry     comes to me
|C                G              |F. (C/E Dm7). C.. |
Speaking words of wisdom, let it be

=>

|C   G   |Am.   (Am Am/G).   F..   |
|C   G   |F.    (C/E Dm7).   C..   |

[no-chris]

C.. G/B.. Am.. <F..
_ No _woman no cr_y
C.. (F C/E) (Dm7 C) C.. G..
_ No _wo_man _no_cry 

=>

|C    G/B       |Am   <F |
   No woman no cry
|C..    (F C/E). (Dm7 C).  |C   G  |
     No wo man   no   cry

=>

|C     G/B                |Am   <F  |
|C..   (F C/E). (Dm7 C).  |C    G   |

[phatmann]

Looks cool so far. My comments:

• Since chord symbols can have parentheses in them, don't we need a different delimiter?
• Since groups are always one beat, perhaps the period after the group is not needed.
• To solve both issues, how about a colon as delimiter, for both editing and rendering. The period is "built in" 😄

C.. :F C/E:

[phatmann]

Any thoughts on this?

[no-chris]

Sorry I missed that message somehow!

• Parentheses: yes, possibly we need another symbol. I'd like to explore rendering options maybe with slightly different colors or even nothing, but I like the readability of the parentheses vs the brackets/square brackets
• I like the consistency but I agree, that needs to be experimented a bit
• tbh I find this one a bit confusing to read 😁

[phatmann]

@no-chris Any decisions about the sub-beat chord format?

[no-chris]

I think we have the basics, now it's a matter of implementing it and fine tuning the syntax!

[no-chris]

This has been implemented in #587

It is part of ChordMark 0.13.0 beta version: https://github.com/no-chris/chord-mark/releases/tag/v0.13.0-beta.0
The beta version of Chord Chart Studio using this is available here: https://deploy-preview-610--chord-chart-studio.netlify.app/app

[phatmann]

Hi Chris. I am super excited to see this in action, but when I try the sub-beat chords the rendering is not working. Maybe the code did not deploy?

[no-chris]

https://deploy-preview-610--chord-chart-studio.netlify.app/app

with:

#i
C.. G.. 
Am. {Am Am/G} FM7. F6.
C.. G.. 
F. {C/E Dm7} C..

#v
C.. G..
When I _find myself in _times of trouble
Am. {Am Am/G} FM7. F6.
_ Mother _Ma_ry _comes to _me
%%
_Speaking words of _wisdom
F. {C/E Dm7} C..
Let it _be _ _ _

C.. G..
And _in my hour of _darkness
Am. {Am Am/G} FM7. F6.
She is _standing _right _in _front of _me
%%
_Speaking words of _wisdom
F. {C/E Dm7} C. G.
Let it _be _ _ _

#c
Am.. G.. 
Let it _be, let it _be
F.. C..
Let it _be, let it _be
C.. G.. 
_ Whisper words of _wisdom
F. {C/E Dm7} C..
Let it _be

#b x2
F. {C/E Dm7} C. {Bb F/A}
G. F. C.. 

[phatmann]

Rendering is indeed working:

So great to see this in action. A few questions:

• Can we get the first chord in the sub-beat group to align with the syllable?
• Do we actually need to render the braces? Since all the other chords have a period next to them, the absence of a period for the subgroup chords may be a sufficient clue.
• Taking this thinking further, if the user inputs "Am. Am Am/G FM7. F6.", the system could recognize that Am/G and FM7 each get eighth-note values without the braces.

[no-chris]

Thanks for the feedback!

Can we get the first chord in the sub-beat group to align with the syllable?

Duh, I was afraid someone would ask for that 😱 I guess we could yes, I did it for the the bar separator, it was painful enough, but I guess replicating it for sub-beats should be easier now that the hard work is done.

Do we actually need to render the braces? Since all the other chords have a period next to them, the absence of a period for the subgroup chords may be a sufficient clue.

That's easy enough to experiment, we can just disable the rendering of the braces with printSubBeatDelimiters: false. It is live if you refresh the deploy preview. I like the clarity provided by the braces, though.

Taking this thinking further, if the user inputs "Am. Am Am/G FM7. F6.", the system could recognize that Am/G and FM7 each get eighth-note values without the braces.

Nice! I'll keep this idea as a nice to have feature, as it would require rewriting the parsing algorithm, and since sub-beat duration chords are not that common in the end, I think the extra work of writing the braces is acceptable for now.

[phatmann]

Ah, a preference is a perfect solution. I like the way it looks with no braces.

I believe the reason I don't like the rendered braces is that they are very "busy" compared with the minimalist vibe of the rendered content. Perhaps a different delimiter would be cleaner? It seems that only "paired" (i.e. different start and end characters) delimiters are clear enough to avoid ambiguity in an environment with flexible spacing. Some ideas for rendering:

⟨ Am Am/G ⟩
‹ Am Am/ G ›
❲ Am Am/G ❳
⊂ Am Am/G ⊃
⊢ Am Am/G ⊣
⋋ Am Am/G ⋌
⫭ Am Am/G ⫬
⟪ Am Am/G ⟫
⁌ Am Am/G ⁍
⨫ Am Am/G ⨬
⨽ Am Am/G ⨼
⧼ Am Am/G ⧽

[no-chris]

I agree with the "minimalist vibe".
I like
⟨ Am Am/G ⟩
‹ Am Am/ G ›
But I still have in mind the syncope notation (Nashville style) for a later improvement.

I like plain square brackets actually, I feel they are more in line with the rest of the rendering

(Note that I've managed to fix the delimiter position 😅 #597

[no-chris]

Although on a second though square brackets do not really stand out from the bar separator |...

[phatmann]

With the delimiter position correct and brackets it looks much nicer. However, I thought we decided not to use brackets as input since they are sometimes used in chord symbols; am I wrong? In any case I agree that brackets probably do look too much like bars.

[phatmann]

At least ‹Am Am/ G› does not look like bars 😄

[no-chris]

Parenthesis are used in chord symbols, not square brackets

[no-chris]

reading the discussion above I realise I created this confusion indeed.
I'll blame it on my limited english vocabulary with regard to punctuation symbols 😅 (braces, brackets, parenthesis, square brackets, etc. 🤯)

[phatmann]

Ok, so square brackets [] are available for input as sub-beat delimiters. It probably makes sense to use them instead of braces then.

As for what we render, I still agree with you that square brackets look too much like bars. But the input character can be different than output character.

[no-chris]

I've updated the deploy preview with square brackets both for parsing & rendering and adapted the styling so they would stand out more from bar separators. Let me know what you think

#i
C.. G..
Am. [Am Am/G] FM7. F6.
C.. G..
F. [C/E Dm7] C..

#v
C.. G..
When I _find myself in _times of trouble
Am. [Am Am/G] FM7. F6.
_ Mother _Ma_ry _comes to _me
%%
_Speaking words of _wisdom
F. [C/E Dm7] C..
Let it _be _ _ _
C.. G..
And _in my hour of _darkness
Am. [Am Am/G] FM7. F6.
She is _standing _right _in _front of _me
%%
_Speaking words of _wisdom
F. [C/E Dm7] C. G.
Let it _be _ _ _

#c
Am.. G..
Let it _be, let it _be
F.. C..
Let it _be, let it _be
C.. G..
_Whisper words of _wisdom
F. [C/E Dm7] C..
Let it _be _ _ _

#b x2
F. [C/E Dm7] C. [Bb F/A]
G. F. C..

[phatmann]

You made the brackets stand out from the bars, so that is good. But it is becoming clear to me that using delimiters for sub-beats and then postfix punctuation for beats is too dissonant. I like the idea of delimited groups in principal, but in practice it is messing up your minimalist ethos.

So, let's go back to one of our original ideas: the comma.

Am. Am, Am/G, FM7. F6.
_ Mother _Ma_ry _comes to _me

The parser sees two chords in a row with commas, so it knows they are eighth notes.

This renders as:

Am.    Am,  Am/G, FM7.      F6.
Mother Ma   ry    comes to  me

That is clean and simple, for input and output.

For the pathological case of an eighth note pair next to a triplet, we could still allow optional grouping via tick marks.

A. Am, Am/G, G. `C, F, C,`
_This is an _eighth _note _pair followed by _a _trip_let

A.          Am,    Am/G, G.              `C, F,   C,`
This is an  eighth note  pair followed by a  trip let

My original issue with the comma is that it is hard to distinguish from a period when rendered. However, as an input character it seems perfect, with the proper tail of an eighth note!

[no-chris]

Thanks for all your feedback! You never seem to run out of ideas 😄

I think I like the delimiter option better, for the following reasons:

• I find it easier to follow when sightreading, because you get an instant view of how many chords are in the beats. Whereas if you have to identify all the next chords that have a coma and then do the math, I think this is less straightforward to do, especially since the comma and the dot are not that easy to differentiate
• 8th notes are often used over 2 beats for transitions, and then we already need to fallback to the edge case handling

C.. [F C/E] [Dm7 C] C.. G..
_ No _wo_man _no_cry 

• I'm not found of the idea of having 2 ways to render the same thing, as in your example (one with backticks, one without)

[no-chris]

So here are both options:

Personally I still feel the square brackets are a better option.

It would probably help to have more opinions, even though not many people get lost around here.
Since I'm ChordMark's most active user I might want to leave it to my taste for now 😁
But once more people voice their opinions I would gladly align with what the majority is asking

[no-chris]

In any case, ChordMark also accept custom post-processing filters, so it would be very easy for a client code to configure it

[phatmann]

I suppose we just need to standardize on the input characters, and brackets are just fine. It makes sense for your reference implementation to render the same characters in the output, but other implementations have more freedom.

[no-chris]

ChordMark's API has quite a few configuration options - as well as the underlying ChordSymbol library - so yes, other implementations have a lot of flexibility

[no-chris]

And thanks again for all the feedback and challenges, I think we have significantly improved the original implementation.