Re: major feature request (tablature)

[Carl D. Sorensen]

On 12/6/08 2:46 PM, "Danalute" <address@hidden> wrote:

> 
> Carl D. Sorensen wrote:
>> 
>> I can't speak for the whole development team, but I suspect that nobody on
>> the team is going to run out and implement ...
>> 
> 
> I am willing to do my part; I think it is reasonable for me to hope to have
> your good advice and counsel.

But of course.  You will find that the LilyPond development community is
perfectly willing to provide support to those who want to add to LilyPond.

> 
> 
> Carl D. Sorensen wrote:
>> 
>> I would recommend that you first focus on the printed results.
>> 
> 
> chicken and egg problem; having parsed data that causes no output is not an
> issue I would hope.
> 
> What I see as input would be a stream of {flagdur, {fretglyph-list}} which
> is interpreted in the context of associative arrays mapping flag and fret
> input glyphs to display glyphs from a specified font and assoicated musical
> semantics.
> 
> Sorry, I begin with goals then work up data structures and move on to
> algorythms and code.
> 

But LilyPond already has an extensive code and data structures base.  To use
data structures or code that are not compatible with the LilyPond paradigm
is not wise.

And there is a LilyPond semantic for input; the farther away you get from
the standard LilyPond way of doing things, the harder you make it for users
to learn and retain the new functionality.  You want to add to LilyPond,
rather than starting from scratch.  So learning how things are done in
LilyPond and using existing LilyPond code where possible to achieve your
aims is IMO the best way to make this happen.

> 
> Carl D. Sorensen wrote:
>> 
>> LilyPond currently has support for frets and strings, so the raw material
>> necessary to define these glyphs and courses is available.  That's good
>> news.
>> 
> 
> Bass course handling is perhaps a bit peculiar, as the glyphlist might be
> ordered arbitrarily and the midi sequance can also be arbitrary.
> 

I'm not sure what that means.  I assumed that each bass course has a defined
pitch, and so the midi associated with that course is defined.  But you
certainly know better than I.


> 
> Carl D. Sorensen wrote:
>> 
>> 
>> Based on your words, I can't construct the written music.  A scan of such
>> notation, or a link to such notation on the web, would help tremendously.
>> 
> 
> Excellent lengthy articles 'Tablature', 'Notation' in _Groves New Dictionary
> of Music and Musicians_, 26vv (music librarys, some local librarys; online
> if one has paid Oxford for access).
> 
> Try the Wiki articles on Notation and Tablature.
> 
> See
> http://wa4.images.onesite.com/vokaria.onesite.com/large/lachrimaeclipped.jpg?v
> =156150
> this  hand-written EPSF for a mixed staff using PS.  This is french
> tablature, flags above, top row of fretglyphs is highest pitched course on
> instrument, letters designate fret from sequence
> (a,b,c,d,e,f,g,h,j,k,l,m,n,o,p...) where a = open.  Most fretted instruments
> had short necks and dont exhaust that sequence, the cittern and some
> oriental lutes (eg saz) have 18 or more fret positions (saz is sometimes
> fretless)

I see nothing in this tablature that can't be done in LilyPond.  I also see
that this tablature is much more beautiful than the current LilyPond
tablature, and can see why you want to improve the LilyPond output.  Thanks
for sharing the vision.

> 
> Compare that to  http://phys.uri.edu/~nigh/tab-in-lily2.pdf this lilypond
> tab ; not bad for modern guitar tab, but also not at all the same.  Note
> that this latter has four voices, 1 and 3 have flag stems originating from
> the fretglyph, too close.  voices 2 and 4 have an offset seperating the
> fretglyphs, this improves legibility, but is extra work and not intuitive
> (issue for docs).

Adding the extra offset from the glyphs automatically should be a relatively
easy thing to do in LilyPond, and might make an excellent way for you to get
started on creating the features you want.  Looking at this output, I
suspect that the glyphs have been offset to put them in the spaces of the
tab, rather than on the lines (which is what the most common popular music
modern guitar tablature does -- see e.g.
<http://www.harmony-central.com/Guitar/tab-notation.txt>).  Then, because
the glyphs have been offset, the stem-down stems have extra space, and the
stem-up stems have much less space.  But I could be wrong on that.
> 
> Carl D. Sorensen wrote:
>> 
>> 
>> it would seem to me to be more robust to enter fret, course, and
>> duration.  But, as I mentioned earlier, input syntax should be determined
>> and coded only *after* the output is in place.
>> 
> 
> Carl, sounds as if you have had issues on this sequence in the past.
>
Every time a new developer comes in with a proposal to add a feature to
LilyPond, Han-Wen makes this same suggestion -- focus on output first,
then determine how to modify the parser.  Of course, if you want to do it
another way, you're welcome to do so.

> 
> I dont want to spend lots of effort arguing the point, I just want to point
> out that without data entry it will be cumbersome to enter test data to
> excercise the printing engine.

The input data set needed to exercise the printing engine is probably
a relatively small data set.  Although it may be cumbersome to enter as
standard LilyPond (pitch-duration-string) you only have to do it once, and
can use it repeatedly to test the printing engine until the output meets
your needs.

> 
> What is needed as input data is obvious and proven; I see absolutely no
> reason not to design and code it, working with a temporary fork of the
> parser.

You might consider that if you run into difficulty, if you're using the
standard parser, any of us can help solve your problems in
generating the desired output.  If you use a custom parser, none of us
will have it available, and we may be unwilling to download your fork of the
parser and build it in order to provide you help.  At the very least, if
we do so, it will take a lot of our time.  It would be way more convenient
for those who might be asked to help you to be able to run a file through
their own LilyPond.  This might be a reason to start with the current
parser.

If you leave the parser alone and write Scheme code to
implement your printing engine changes, we can test your changes on our
standard LilyPond installations by just including the Scheme code in
.ly files.  And then, once things are debugged, they can be added to
the LilyPond installation directly.

> 
> 
> Carl D. Sorensen wrote:
>> 
>> Let me be the first to
>> welcome you to the development team.  We'd love to help you as you work
>> to improve LilyPond's tablature support.
>> 
> 
> Thanks, it will be a matter of weeks before I can leap in to the center of
> the pond; for now I am limited to a 4Mb flash drive used at the library
> while it is open to dig into source code and docs, in a couple weeks I hope
> to have mac g3 up and running to code and compile.

I'll look forward to seeing how you choose to move forward on this.   I
think it will increase LilyPond's appeal as the premier music engraving
software.

Carl