> -----Original Message----- > From: Heikki Johannes Junes [mailto:[EMAIL PROTECTED] > 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 _______________________________________________ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
