RE: Fret Diagram markup

[Carl D. Sorensen]

> -----Original Message-----
> From: Heikki Johannes Junes [mailto:address@hidden 
> I agree that the that it is good the maintain the information 
> about the strings. So, that part is resolved ;)
> 
> As usual, I should be more precise on what was confusing me 
> (before starting to inventing something optional). In 
> LilyPond the note properties are postfixed, and the order of 
> the postfixed syntax snippets does not matter. The example 
> above is otherwise well expressed -- it contains all the 
> information needed, but the order of the '-3' parts in 
> '5-3-3' does matter, which is confusing. On the other hand, 
> if '5-3-3' would be written as in TabStaff Context, 'd\5-3', 
> there would not be such confusion. As well, if the '5-3-3' 
> string above would be '3\5-3', then it would be exactly in 
> line with the syntax in TabStaff Context. 
> 
I like your input on this.  I like the idea of a shorthand notation that
clearly indicates the function of each part of the notation, such that
the order can become irrelevant.

Before I jump in to make such a parser (which would eventually be
replaced by the standard LilyPond parser once a FretDiagram context is
created), I'd like to think carefully about the differences.  In
Tablature, the note, string, and finger are given, and the fret is
deduced from string tunings.  I suppose we could do the same in
FretDiagram, but right now there isn't a context to get hold of
StringTunings.  So I can't determine fret automatically yet.

So I suppose we could do as you propose, and have the note in Tablature
be replaced by the fret in FretDiagrams.  That seems reasonable.  Under
this scenario, things become position independent, because we have the
following:
No prefix => fret
\ prefix => string
- prefix => fingering
-( and -) => start and end of barre

> (Sorry about giving a bad link to the syntax 
> which did not contain strings in the previous mail.

It's interesting that the manual on Tablatures contains no information
about fingering indications.  That's probably something that should be
fixed.


> If the string syntax above will be obsolete at some point, then also
our differences in 
> opinions do not matter anymore. As an anecdote I could say that "We
should hurry 
> to disagree -- our discussion will soon become obsolete!"

OK, then I'll disagree as quickly as possible! :-)

BTW, I went ahead and implemented your last proposal, just to see how
things worked.  It certainly made the definition strings shorter, but at
the same time they were less descriptive. I think I like having the
definition string solely for content, and using props for all formatting
instructions.

Thanks again for your input.

Carl