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:[EMAIL PROTECTED] > Sent: Sunday, February 01, 2004 6:38 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: A small step for guitar chord diagrams: syntax > > > On Sun, 01 Feb 2004 23:37:30 +0100 José Luis Cruz > <[EMAIL PROTECTED]> 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 _______________________________________________ lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
