Re: major feature request (tablature)

[Carl D. Sorensen]

On 12/11/08 3:53 PM, "address@hidden" <address@hidden>
wrote:

> On Thu, Dec 11, 2008, "Carl D. Sorensen" <address@hidden> said:
> 
> 
>>> // preface, 4 row german tab, glyphs detailed...
>>> // hidden time signature common (often ommited, but used)
>>> // ? hidden key signature c (tab lacks key sigs)
>>> 
>>>   {1 {5,d,n,J}}
>>>   {2 {n}}
>>>   {2 {4}}
>>>   {5 {d,n,J}}
>>>   {5 {4,h,A}}
>>>   {thinbar}
>>>   ...
> 
>> This syntax is
> 
> my meta language.  Not intended for direct implementation, just for
> thinking about the content and general form.  Please note the use of
> 'might'.
> 

Sure, and I can see this as a great input syntax for tablature.  It doesn't
match well with LilyPond.  So the best solution I can see is to write a
translator (like xml2ly) to translate your desired tab input into LilyPond
input. It could even take direct ASCII tab and convert it.  That would be a
very useful tool.

>> The ideal (in my opinion) would be to put tablature information right in
>> with the music input
> 
> huh?  the tablature _IS_ the music information.  No way we should be
> asking the user to do any translation from tab glyphs to pitch.  Too many
> errors, too much time, and, what the hell is the computer for anyway?
> 
> , so the exact same music expression can be passed to
>> the tablature and the staff (that's how LilyPond currently does it).
> 
> IMNSHO it is most unfortunate that Ly is now abusing its users that way.
> 
>> it may be a little bit more awkward for the person doing the transcription,
> 
> a LITTLE? it is abusive to the person doing the data entry to have to
> enter the same information redundantly in different forms.
> 

You misunderstand me.  By making it the exact same information, you don't
enter it twice.  Just once.

>> it greatly facilitates mixing tablature with staff notation.
> 
> if it is that badly needed internally than it can be calculated and used
> internally. 
> 
>> If you have no interest in doing the mixing, then it would seem to me that
>> you'd be better off just writing your own tablature program.
> 
> Please recall that I have already done that.  It doesnt do staff notation
> (yet).
> 

Great!  Since you have a tablature program, that takes care of the input,
and knows how to convert it to output, but not with staff notation, I'd
expect it to be able to transfer the information to LilyPond input notation.
Then it would be quite straightforward to generate the output.

On the other hand, I expect it would be a huge job to rewrite the LilyPond
parser to match your input syntax -- but you are welcome to try.

>> I have a question, and it's meant to be sincere, not flippant.
>> Have you ever set a piece using LilyPond?
> 
> The short answer is no.  But, Liliypond tablature has been discussed on
> the lUTE list, and one member has taken a simple example thru a couple
> iterations to produce that which I cited here last week (and further); he
> posted excerpts from its input encoding; no, I havent studied them in
> depth or gone to the docs yet.  I will do, but not right this instant, I
> know they will be extensive.  Understand, I have a life beyond this
> project, including a jobhunt.
> 
> Turnabout is fair, Do you play from tab, have you ever transcribed from
> staff to tab, or the reverse?  I find transcription in either direction
> needs writen translation aids and is highly error-prone; and that opinion
> is shared by many on the LUTE list, including experienced musicologists
> and professional players.
> 

I have played from tab.  I have not transcribed either way.  I mostly use
staff.  I have used LilyPond to generate tab.

>> The entry glyphs do not have to be the display glyphs!
> 
> true, and that is not what I said was desirable.
> First of all, the display glyphs might well be totally different from the
> entry glyphs; some users will want a transliterated version.
> 
> Data entry includes proofreading.  Accuracy is greatly improved when
> glyphs on the screen resemble those of the source.  I would expect someone
> entering greek text to be more facile with a greek font on the screen
> rather than a roman one, no?
> 
> A common difficulty in reading from civilte-based sources (commonly used
> by french and english printers) is confusion between 'c', 'e', and 'r'.
> 'b', 'k' and 'h' are also easily confused.  Blackletter fonts are used for
> german tab and are almost totally unfamiliar to many modern readers.
> Historical tablature was printed with specially cut fonts, the glyphs are
> taken from handschrift examples, with slight modifications, in some cases
> vertically squashed, in others, ligatured as in AA, or overstriken,
> underlined, overcurved.  Glyphs for 'et' and 'con' are used.  A specialty
> font could be used on screen during input, but its encoding will not
> always be supported by unicode (eg, have found 'et', but not 'con').
> 
> It the user is to be suffered to us arbitrarily encoded fonts for a visual
> editing session, it is humane for us to provide a means for her to tell us
> the encoding of those symbols she has typed; not a hugely difficult task
> for us to use those lists to interpret the input stream I think, be
> surprised if it isnt already supported.
> 
>> We don't enter half-note heads for music
> 
> no, you dont, (I defer the temptation to suggest you could to another
> time).  Judging only by a few examples of guitar-tab, I have seen a
> numeric description of the duration as in 1,2,4,16...  what for Longa or
> Maxima? (I know, uncommon outside of scholarly editions); similar to my
> enumeration of flag tails (itself limited to b,sb,m,sm,f,sf; all that is
> seen in historical tab editions and ms), only slightly less intuitive.

1*2, 1*4

> 
>> LilyPond *is* strictly an ASCII/UTF-8 based input format.  There is *no*
>> facility for changing fonts used for input.
> 
> DEFENSIVE!!!!  you completely misunderstand me.
> 
> Not asking for a visual front end.
> Not asking for cognizance of input fonts.
> 
> Allowing the user to type in whatever font they please leaves the problem
> of how to interpret the codes produced.  A tagged list provides us with
> the keys to map that.
> 
> something like this (ordered by position-implicit key)
> 
>  \flagGlyphList {&#x1D165, {&#x1D165 &#x1D16E} , {&#x1D165 &#x1D16F} ,
> ..}
> 
> or maybe an explicitly keyed list as in
> 
>  \flagGlyphList {breve= {&#x1D165} , sbreve= {&#x1D165 &#x1D16E} , ...}
> 
> [unicode 5.1 musical symbols; combining stem and flags.]
> 
>> I'm not sure what you expect me or others to be doing with these ...
> 
> Understand the problem, acclimate to asciitab; no more than that.  The
> differing use of rows in german vs other forms of tab is confusing absent
> examples.

OK, I got that.  Thanks for the explanation.

> 
> Most european musicians depend on modern editions and never go to original
> sources or facsimiles.  Imagine that fret diagram printed at the front of
> the waissel editino, the compositor uses a font he has in a small size,
> perhaps a fraktur.  For the edition, a different font, perhaps a
> schwabacher is chosen because it is available in more quantity in the
> appropriate size.  the german reader in 1573 has no trouble correlating
> the symbols.  Todays reader, unfamiliar with any form of blackletter needs
> all the help we can give them to deal with the microfilm of the now rare
> book.
> 
> So, no need on input to get involved with the font itself, but useful to
> have a glyph mapping table.
> 
>> I'm trying to give you suggestions
>> to help you mesh with LilyPond, but none of them seem to be sinking in.
> 
> Frankly?  You seem to be madly digging the tranches deeper and piling the
> dirt higher on the walls.  The barbarians dont want to burn your city,
> they heard there was a good time to be had inside.

I'm sorry you feel that way.  I'm trying to show you a map of the city.
There's a lot of the city there, and you'll be much more successful if you
use the streets rather than trying to climb over the fences and walls.

> 
> Whatever encouragement you have offered is rather dampened by the constant
> entrenchment and what I perceive as misunderstanding; I will admit exists
> on both sides, we each have our own jargon.
> 
> Understand, and I really mean this sincerely.  I have no intention of
> doing harm.  It will be some time before I can locate and digest whatever
> overview is provided and go on to digest the rest of the docs and code,
> Scheme will take longer yet.
> 

I'm sorry if I implied you were trying to do harm.  I have no such feelings
about your activities.  You're certainly welcome to ignore me.  I really
*am* trying to help you by pointing out what seems to me (who is somewhat
familiar with LilyPond internals) the shortest way to get to your
destination.  

> I came here initially in hopes of finding a mature human-readible encoding
> system; something akin to the apparantly abandoned Guido/Salieri project.
> 
> There is a need for a public archive of the worlds music, including that
> now best read in tablature.  Some of us on the Lute mailing list are
> discussing ways to get that going.  Major elements of the project are the
> encoding itself, as well as software to read it out, transliterate it,
> etc.  Fancy publication is not the goal, and because we are pluckers, our
> part would seem to be tablature rather than staff; let others deal with
> their own (until we are done with ours, then...)
> 
> You ask about my own program, well in there lies a sad tale.
> 
> It may never get polished enough for release, Apple is determined to shift
> the sands and leave me behind. Not gonna rewrite 300,000 lines of C++ with
> carbonized glue into C# with Cocoa based glue; IMHO C# has an ugly syntax
> that should have been allowed to die.die.die with NeXT.

Can you extract the key algorithms for input and make a text-based format
that will do what you want (including the glyph substitution you desire)?
If you could do that, and export a LilyPond format (all done by computer, of
course), then LilyPond could create the tabs from that format.  And I'm
quite sure that any of the tabs can be supported by LilyPond.

> 
> Maybe there will be a groundswell of similarly disinclined developers to
> convince Apple that support of C++ addicts is worth the effort of finding
> a way to support C++ access to Cocoa.  Sadly, I see no protest from
> developers, and fear the loss of usenet has fragmented discussion forums
> to the point that it simply wont get rolling.
No matter how big the groundswell, I can't see Apple providing the support.


Let me try to be as clear as possible on how I am trying to offer help.

LilyPond is a program that aims to do one thing well -- engrave music.  It
does not try to be a convenient input tool.  It just tries to engrave music
beautifully and succeeds quite well, in my opinion.

LilyPond is built under the Unix philosophy of modular programs (see
<http://www.faqs.org/docs/artu> and look under I.1. Philosophy).  This means
that LilyPond doesn't do any nice input handling at all -- and that is by
design.  The Unix way to handle creating a nice tablature input interface is
to write a tablature input program with a well-defined output that will mesh
with LilyPond's input.

It _might_ be possible to put a complicated (for the parser) input structure
on top of the current LilyPond program, but I think it would be (a) much
more time-consuming than writing it separately, and (b) much less stable
than a program that focuses on input.

I admit that at first I didn't understand what you were after.  I think I do
now, thanks to your willingness to keep talking with me, even when I seem
obstinate.

Given the lay of the land, I think the best way to move forward and achieve
the goal of capturing the world's music in some way that it's reproducible
is to have a two-pronged approach.

1) Develop a best-in-class user input system for tablature.   This would
take tablature in whatever form, in a way that is convenient for users.  Its
output would be the core information that is necessary for display on a
staff and in any variety of tab:  pitch (necessary for staff), string, fret,
fingering, and duration.  This probably should not be part of LilyPond.  It
doesn't share the core functionality of engraving.  LilyPond's input
structure is not user-friendly for tab.  And making it so would be an
enormous job.  But making it stand-alone would probably be a much smaller
job.

2) Develop a world-class tablature output for LilyPond.  It can take the
pitch, string, fret, finger, and duration, and create the desired output in
any form of tablature, with the desired glyphs in the desired location.
LilyPond has an excellent infrastructure for supporting this, and I think it
would be only a moderate amount of work to make this happen.

3) Develop some way of connecting the output of 1) to the input of 2).
Standard Unix pipes could do the trick.

The set of 1) and 2) would then provide the desired functionality in a
stable way that requires the minimal amount of effort.

I hope this helps.

Thanks for listening,

Carl