On Thu, Dec 11, 2008, "Carl D. Sorensen" <c_soren...@byu.edu> 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'.
> 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.
> 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).
> 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.
> 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.
> 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 {𝅥, {𝅥 𝅮} , {𝅥 𝅯} ,
..}
or maybe an explicitly keyed list as in
\flagGlyphList {breve= {𝅥} , sbreve= {𝅥 𝅮} , ...}
[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.
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.
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 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.
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.
Enough of religious matters and personal issues.
--
Dana Emery
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
