More on chord diagrams

[Carl D. Sorensen]

Heikki and Jose Luis,

I've created a markup facility for chord diagrams 
(http://mail.gnu.org/archive/html/lilypond-devel/2004-04/msg00125.html), but so 
far no engraver or context.  I thought I was close to finished, until I looked 
more closely at your requests.

> -----Original Message-----
> From: Heikki Johannes Junes [mailto:address@hidden
> Sent: Sunday, February 01, 2004 6:38 PM
> To: address@hidden
> Cc: address@hidden
> Subject: Re: A small step for guitar chord diagrams: syntax
> 
> 
> On Sun, 01 Feb 2004 23:37:30 +0100 José Luis Cruz
> <address@hidden> wrote:
> 
> >
> > \property Score.TabDiagram \override #'number-frets = #5
> 
> This look analogous to Tablatures, in which fret number is customable.
> 
> > \property Score.TabDiagram \override #'no-string-symbol = #'"x"
> 
> Optionally, `x´ could be also omitted.
>  
> > This is my wishlist:
> > 
> > - Being able to change the size of the diagram.

This is currently available

> > - Text of diagram is a markup.

This could be done by stacking the text with the diagram -- there is no Chord 
name currently associated with the diagram.


> 
> Text and diagram should scale together, I guess.
> 
> > - Setting the glyph i want for dots. (numbers, little black
> dots, or
> > big ones)

No interface for this feature.  Numbers are not presently available, but you 
can change the radius of the dots in the scheme code.  It would not be 
difficult to make the dot radius a parameter for the markup.



> > - Under each string, you can write the text/character you want.
> > (fingering, note, grade, etc)
> 

Not implemented right now.



> > So apart from normal chords, which are the ones that 80%?
> users will
> > use ever, the rest of us will be able to create our dreamed diagrams
> > like:
> > 
> > 
> >  A arpeggio
> > 
> > x         o
> > -----------
> > |_|_|_|_|_|
> > |_|_o_O_o_|
> > |_|_|_|_|_|
> > |_o_|_|_|_|
> > O | | | | |
> > 1 3 5 1 3 5
> 
> Seems like here `x´ does not mean here a mute string ... that
> means customable string both below and above... and `O´ is 
> different than `o´ ...
> 
> The sixth string needs string both below and above: 
>   e,\6^\markup{"x"}_1
> where "x" overrides the empty string above the string.
> 
> Also, the centered circle could be markup, something like
>   e,\6^\markup{"x"}-\markup{\bigger \filledcircle}_1
> 
> >   A Dorian arpeggio on 1 pos.
> > 
> >   |---|---|---|---|---| 
> >   |   |   5   |   |  13   IV
> >   |---|---|---|---|---|
> >   |  b3   |   |  11   |
> >   |---|---|---|---|---|
> >   |   |   |   9   |   |
> >   |---|---|---|---|---|
> >  (1)  |  b7   |   |   |
> >   |---|---|---|---|---|
> 
> I agree that roman numbering is better to show the fret
> number. Also, if `IV´ or similar is shown, the top line 
> should be thin, not bold. ( 1BTW, this look much like 
> Tablature turned 90 degree clockwise. ) You're right, there 
> no reason to restrict the number of fret positions on a string.
> 
> The above chord diagram could typed as:
> 
> <
>   b,\6-\markup{ "(1)" }
>   d\5-\markup{ "b3" }
>   fis\4-5 a\4-\markup{ "b7" }
>   cis'\3-9
>   e'\2-\markup{ 11 }
>   gis\1-\markup{ 13 }
> >
> 
> >   C-M7(b9) ->> C-M7(#9)
> > 
> >   X                   X
> >   =====================
> >   |---|---|---|---|---|
> >   |   |   o   |   |   |
> >   |---|---|---|---|---|
> >   |   |   |   |  b9   |
> >   |---|---|---|---|---|
> >   |   O   |   |   |   |
> >   |---|---|---|---|---|
> >   |   |   |   o  (#9) |
> >   |---|---|---|---|---|
> > 
> >       C  Eb   B  Db/D#
> > 
> > José Luis
> 
> For this, syntax could be:
> 
> <
>   c\5_\markup{ "C" }
>   es\4_\markup{ Eb }
>   b\3_\markup{ B }
>   cis\2-\markup{ b9 } dis\2-\markup{ (#9) }_\markup{Db/D#}
> >:\markup{ C-M7(b9) ->> C-M7(#9) }
> 
> This is already rather complete set of features.
> 
> I will summary all the features which could be present:
> - a new context: \context TabDiagram { ... }

Should the name of the context be TabDiagram, FretDiagram, ChordDiagram, or 
something else?  (I probably prefer FretDiagram, but I've been working with it 
as ChordDiagram).

> - customable numbers and tunings of strings (like Tablatures
> rotated -90 deg)

Shoult the customizable tuning be shown on the diagram, or is it simply a way 
to allow lilypond to calculate the fret position of the note, given the string? 
 If the tuning is shown, how should it appear?
 
> - default markups above each string (overridable): 
>     `x´ - above unused string
>     `o´ - above open string (open circle symbol)
> - string positions are grouped into a chord:    < ... >
>     - string position is given as note, e.g.    a,\5
>     - there is centered markup below note, e.g. a,\6_1
>                                                 a,\6_\markup{ "A" }
>     - the filled symbol can be overriden, e.g.  a,\6-\markup{
> \bigger "o" }

Fingerings in this scheme can be indicated in at least two different ways: as a 
number below a string or as a number in a circle at the fret position on the 
string.  Should the fingering be given as a separate event for the note (as is 
supported elsewhere in lilypond) and then have a setting for the way the 
fingering is displayed (no display, number in filled circle, number in empty 
circle, number below string)?  Or should the finger be indicated just by a 
markup, as is proposed here?

>     - overridable symbol above thestring, e.g.  a,\6^\markup{"x"}
>     - there may be many string positions, e.g.  cis\2 dis\2
>     - always the minimum fret position is found (except the
> free string `o´),

I guess the context finds free strings by a note placed on the desired string 
that would require an open fret.  And I assume that the context finds mute 
strings by strings that have no notes on them?  Or would it be better to 
require a space note for the fret that will have an x (e.g. < s,\6...>?
 
>       and the fret number is printed right to the diagram if
> it is greater
>       than one, as roman number

Actually, I believe that the fret number should be printed only if the 
_maximum_ fret number is greater than the number of frets in the diagram.  
Thus, a traditional A chord, which uses only the 2nd fret, will have a base 
fret of 1, rather than of 2.  Similarly, the traditional D chord, which uses 
the 2nd and 3rd frets, should also have a base fret of 1.

> - after the chord there may be a duration,      < ... >4

I suppose that the duration is used to synchronize chord diagrams with music 
and lyrics.  For me, I'd prefer to just use the chord diagram as a markup to 
either a note or a chord name.  If I went that way, I don't have to keep track 
of all the durations of the chord -- I just put in a markup when I want it.  
The downside of the markup approach (for the programmer) is that I have to make 
a parser for the markup string.


> - above the diagram there is a chord markup:    < e,\6 a,\5:/E ... >

Do you anticipate that the chord markup is exactly the same string that is used 
in the ChordNames context? 

> - and that markup could also be overriden       < e,\6 
> a,\5:\markup{ ... } ... >

There is at least one feature missing from this list: the symbol for barre 
chords.  Any others you can think of?

> 
> I am not capable to program this, but I hope that the
> specification of syntax given above could give somebody a 
> good kick start.

I'm not sure yet that I am capable of programming this, but I guess I'll 
continue to plug along.

> 
> Greetings,
> 
>   Heikki Junes
> 

It seems that if we proceed with a syntax similar to this, there are potential 
clashes with other contexts.  For example, I would expect that ideally the 
music expression which generates a fret diagram would be processed by at least 
three contexts.

In the Staff context, the expression would create the notes on the staff, and 
as it currently stands, I would assume that the markups proposed in this syntax 
would be attached to the notes on the staff, which is not a desired outcome.  
Thus, the Staff engraver would need to know that the markups were intended for 
the FretDiagram context, not the Staff context.

Second, the ChordName context would need to create the markup to be used by 
default at the top of the fret diagram, but it couldn't actually put it out to 
the paper, because it needs to be above the diagram, and may be overridden by 
some other markup (and it is further proposed that the markup could have 
multiple chords, which the ChordName context should presumably parse).

Finally, the FretDiagram context would take the expression, calculate the fret, 
string, and finger positions based on the Note and String events, merge in the 
markups, and print out a nicely formatted leadsheet.

Now, under this scenario, how would the Staff context know to ignore the 
markups intended for the FretDiagram context?

And if we aren't (potentially) running the notes through multiple contexts, why 
not just make fret diagrams as markups to chords?

Thanks for your input,

Carl Sorensen