On Tue, Dec 9, 2008, "Carl D. Sorensen" <[EMAIL PROTECTED]> said:
> On 12/9/08 4:37 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> You're confusing users with developers. Code and data structures are
> developer-only items.
yes, but the data structures my code needs are tablature-oriented, not
staff-oriented; for a straight printout I need pretty much what the user
entered. For a translation to staff, or to another tab form I need that
same data.
> Code and data structures should be compatible with existing LilyPond code
> and data structures.
compatible, yes, equivalent, I think not; but I have to take a peek at
what you have, and that should be pretty soon, the untar utility is
downloading now.
Maybe I could have gotten more smaller stuff, but the tarball is what I
saw, it came down in minutes and is there, so no biggie.
>> User of tablature is thinking of where to put the fingers, which is
>> a stream of
>>
>> { [flag], {fretlist} }
>>
>> for italian and french notations, with the fretlist ordered by course
>> and a stream of
>>
>> { [flag], {fretCoursePolyphony-row1, -row2, -row3, ... }
>>
>> for german, with course implied by the fretglyph encoding.
>
> Why isn't "where to put the fingers" a string, fret pair? That's what it
> seems to me. Then a duration would be added as well.
dur is given or implied by flag or most recent flag. It is handy to
seperate the optional glyph from its implicit duration, I do that in my
application, dont know if the like is done in Ly; cant see why it would
be, except perhaps for intermediate notes of a ligatured note in mensural
notation.
German tab is peculiar, unlike french and italian which use a short
alphabet to label the frets, german uses a much extended alphabet to label
all the intersections of fret and course. A single row of german tab
glyphs can do a drunken walk over the whole fretboard.
>> yes, i see that, and it could work well for 6-course lute tab and cittern
>> tab (4-6 course instrument); but there will be aspects of the notation
>> which simply wont have equivalent data, so maybe in stages.
>
> Won't every note you want to put on a tab have a pitch, a duration, a string
> (or course), and a fret number?
yes, but there is more than notes to be displayed. Fingering markup was
used historically, much the same way it is now, pedantically. RH marks
ims with one, two, three dots. LH marks with small letters or small
numerals so as to contrast with the fretglyphs.
> Right now, LilyPond has the built-in functionality to, given a pitch, a set
> of string tunings, and a desired string, automatically calculate a fret.
noooo, that makes german tab unpossible.
My assumption was that C++ was involved (as it is for me), the data
belonged to a tabStaff object, and it could interpret the glyphs as it
needed to. When asked for midi it would cycle thru the several rows
looking up the display glyphs to get {fret,course} for italian or french
it cycles thru the courses (rows) and looks in a shorter list of fret
labels.
german tab is nasty evil vile stuff to play from, transliterate, do pretty
much anything with except feed it to a computer (both the vast extended
alphabet and the fraktur fonts used by its printers offend every sense of
most players) "bad even for dwarfs"; but without support for it there is
no way to get it transliterated into users preference of italian or
french.
The row content in german tab is arbitrary, not limited to one course as
is french or italian or modern guitar; german mixes all the courses on
each of its display rows. Knowing where the glyph is on the instrument
doesnt tell which of the rows of german tab polyphony it belongs to,
leaving no way to display it. A mapping table associates each glyph to
the pertinent data of {course, fret} I think it is good to allow the user
to define seperate fonts and encodings for input glyphs and display
glyphs, that would be
inputGlyph associates to {outputGlyph, string, fret}
Yes, this implies that each tabStaff needs mapping tables (there would be
defaults, I use asciiTab defaults, not pretty, but sometimes what you want
for email or whatever).
> The first thing you will do is add the Scheme code to the LilyPond input
> file. Eventually, once it's debugged, it can be added to the LilyPond
> distribution.
>
> Since you put 'scheme' in single quotes, I suspect you don't know about
> Scheme programming. Scheme is a Lisp-like programming language.
((((()()((()))()()((())))))))
I hope not, that kinda stuff leaves me with a headache, thank the gods for
programming editors with () balancing.
--
Dana Emery
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
