Re: major feature request (tablature)

[Carl D. Sorensen]

On 12/9/08 9:51 PM, "address@hidden" <address@hidden>
wrote:

> On Tue, Dec 9, 2008, "Carl D. Sorensen" <address@hidden> said:
>> On 12/9/08 4:37 PM, "address@hidden" <address@hidden>
> 
>> 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.
> 

I hope you're not thinking about a separate input mode for each form of
tablature.  I suppose you could be, but that seems like a nightmare to me.

> 
>>> 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.
> 

But this is still an *output* issue, not an input issue.  Let the single row
of german tab glyphs do a drunken walk over the whole fretboard.  Each glyph
has a meaning of (string+fret), does it not?  And therefore if you have a
(string+fret) data structure (which LilyPond does), you have the information
necessary to recreate the drunken walk.

If your objective is to have the user type the tablature in directly (i.e.
some form of representing the exact output), then that's essentially the
equivalent of a graphical input for music, which LilyPond explicitly avoids.
LilyPond wants to have the input represent the minimum information necessary
to uniquely specify the content of the music (see
<http://lilypond.org/web/about/automated-engraving/input-format>).  In my
mind, that is (string, fret or pitch, [finger], duration).  Everything else
related to the output (german, french, italian, or modern style; sets of
flags to use, desired fonts, etc.) are not characteristics of the music
itself, but characteristics of the desired engraving, and are hence entered
separately from the music.


>>> 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.
>

LilyPond supports both right hand and left hand fingerings.
 
>> 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.

Why?  

You need to understand that when I say string, I mean string on the
instrument, not line on a tab staff.

But, if you don't want to use the automatic fret calculation, you don't need
to.

> 
> 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.

Sort of.  Music is parsed from the input into events.  The events are passed
to engravers which produce the output.

The fundamental events for a tablature are notes.  Notes have a pitch and
duration (which are used to create MIDI) and can have associated strings (on
the instrument, not lines on the tab), frets (on the instrument, not on the
tab), left hand fingers, and right hand fingers.

The tabStaff engraver will take the note data (pitch, durations, [string],
[fret], [LH finger], [RH finger]) and calculate what grobs (graphic objects;
glyphs occur in fonts, grobs can include glyphs but are more general) are to
be placed where.  It can be written (although it currently isn't) to know
the different kinds of tablature and make the appropriate choices depending
on the selected tablature.
> 
> 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}
> 

I suspect (although I'm not the one who makes the rules) that you're going
to have a hard time getting some patch that takes inputGlyphs [rather than
the fundamental (pitch, string, fret, fingerings, durations)] as input
implemented in LilyPond, because it goes contrary to the fundamental
LilyPond philosophy.  But you're certainly welcome to have at it, and
there's nothing stopping you from forking LilyPond if your proposed changes
aren't accepted.

And there are no "fonts" associated with input glyphs.  LilyPond input is
UTF-8 or ASCII.  Input is strictly printing text characters.

> 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).

I doubt that you'll be able to recreate your application in LilyPond.  But
if you learn the LilyPond semantics, I expect that you'll be able to
generate beautiful tabs with LilyPond.

Anyway, good luck!

Carl