> 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.
What is wise is to bow to the users expectations, not twist their mind.
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.
> 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.
YW, please notice that besides the form differences, there have been a
number of fonts used historically, I have made replicas using
Fontographer, and will be tweaking them to serve Ly use.
> 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
yes, I see where that could leave the stems mispositioned as they are.
The fellow doing that illo has gone on to correct the 1 and 3 lines flags.
Once I get the docs unrolled from their tar balls... (chicken n egg
problem, libraries dont have untar utillities n frown on installs on their
virus-free machines...).
> (which is what the most common popular music
say it, Mel Bay editions :-). I have a couple for banjo.
>>> it would seem to me to be more robust to enter fret, course, and
>>> duration.
right, I was distracted by thoughts of german tab (ugly stuff that).
> You might consider that if you run into difficulty, if you're using the
> standard parser
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.
> If you leave the parser alone and write Scheme code
a clue to where 'scheme' code is described would be welcome, unique to Ly?
elsewhere?; in the doc package I have?, somewhere online?
> 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.
priced right I think is the major claim to fame you can honestly make, its
got a ways to go before the other is clear to all.
--
Dana Emery
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
