Re: major feature request (tablature)
On Thu, Dec 11, 2008 at 10:53:21PM -, dem...@suffolk.lib.ny.us wrote: > On Thu, Dec 11, 2008, "Carl D. Sorensen" said: > > > 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. ... > > 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. ... > 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. Undersatnd, and I really mean this sincerely. Carl is bending over backwards to help you. He's also far more polite than other developers. His comments are aimed at *saving you wasted effort*. As far as I can tell, your patches would not be accepted for merging into lilypond. Surely you would rather discover this *now*, instead of after 20 hours of work learning scheme and whatnot? > > 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. In my mind, any useful discussion ends here. I'm not saying that your ideas are bad, but they differ so radically from the rest of lilypond that I cannot imagine them being accepted into our source tree. Please listen to Carl's concerns, and try typesetting some pieces. That will give you a much better idea of how lilypond works -- after doing this, you will probably realize that Carl was right and it would be better to pursue your ideas in a different program. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: major feature request (tablature)
On 12/11/08 3:53 PM, "dem...@suffolk.lib.ny.us"
wrote:
> On Thu, Dec 11, 2008, "Carl D. Sorensen" 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 f
Re: major feature request (tablature)
dem...@suffolk.lib.ny.us wrote: 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. I think I'm starting to see the misunderstanding here (it takes a while sometimes :)). I'm guessing most of us who use Lilypond think in terms of pitches on staves, and it's counter-intuitive to think in terms of fingers on frets, irrespective (in data-entry terms) of the pitches involved. I don't know that I'd call it abusive, but it's definitely onerous to have to translate from tab to staff notation just to get back to tab output. Would it not be possible to enter Tab data in a way similar to fretboard markups, where the string and fret are indicated thus: 6-x;5-x;4-o;3-2;2-3;1-1 In this way the person transcribing would not have to translate from tab to pitch and back again (definitely error-prone). There's still the matter of rhythm, of course, but I see Dana's point about having to enter the data in terms of pitch instead of in terms of finger placement. This sort of input would (I suppose) assume that no staff output was desired and it wouldn't need to figure out what pitches are being entered, or have to create MIDI output, etc. Just some thoughts... Jon -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: major feature request (tablature)
On Thu, Dec 11, 2008, "Carl D. Sorensen" 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 {𝅥, {𝅥 𝅮} , {𝅥
Re: major feature request (tablature)
On 12/10/08 5:45 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> German tabs origins are, like all the forms, obscured by time.
>
> It is reputed to have been invented by Conrad Pauman, mid fifteenth
> century, as a way to record music for short-necked lutes having 5 courses.
> The notation was extended for lutes having 6 or more courses and more
> frets, and we have lots of printed music and ms; but as each publisher and
> scribe extended the notation in a personal manner there are variants.
>
> An edition of M Waissel's music printed by J Eichorn in 1573 (Frankfurt an
> der oder) shows the fretboard of a 6 course lute with one form of
> extension. Note, the fingerboard is viewed from above; intersection of nut
> and highest pitched string is labeled 5.
>
> 5 e k p v 9 -e -k
> 4 d j o t 7 -d -j
> 3 c h n s z -c -h
> 2 b g m r y -b -g
> 1 a f l q x -a -f
> A B C D E G H -J
>
> another printer (Heckel) and his inheritee (Jobin) uses the following for
> 6th course
>
> -1 -a -f -l -q -x -aa -ff -ll
>
>
> From the first piece in the Waissel edition, "Pass e Mezo" (first row is
> flags, giving duration)
>
> 1 2 2 1 11 2 2 2 2 2 2 1 2 2 2 2 2 2 ...
>
> 5 n 4 5 5 | 5 g 5 o d 4 n | 4 2 o o d 4 n | ...
> d d 4 | d 2 | c c 2 | ...
> n n h | n | D D | ...
> J J A | J | | ...
>
>
> which might be entered
>
> // 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}
> ...
Dana,
It might be entered this way, but proabably not in LilyPond. This syntax is
so different from LilyPond that it bears not even a shred of resemblance.
You're welcome to do whatever you want, but it seems to me to be totally
unwise to develop a syntax so foreign to LilyPond.
The ideal (in my opinion) would be to put tablature information right in
with the music input, so the exact same music expression can be passed to
the tablature and the staff (that's how LilyPond currently does it). While
it may be a little bit more awkward for the person doing the transcription,
it greatly facilitates mixing tablature with staff notation.
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.
If you do have interest in doing the mixing, then it seems to me that you
should start with the existing LilyPond input structures. You've expressed
ways that the software could work, but the ways you've expressed don't match
up with the ways that LilyPond works.
I have a question, and it's meant to be sincere, not flippant. Have you
ever set a piece using LilyPond? If not, before you talk about making
changes I think it's important that you spend at least a little bit of time
setting some music to see how LilyPond works.
>
> While an entirely ascii based input encoding is feasible and protean, the
> variety of german systems makes it desireable to allow the user to define
> the entry glyphs (which will sometimes be ligatures).
The entry glyphs do not have to be the display glyphs! We don't enter
half-note heads for music, so why should we enter display ligatures for
tabulature.
>
> Historical fonts are not always easy to read, typedesigners based their
> fonts on the handwriting in use by the presumed readership. Civilte for
> french and english tablature, Blackletter for german were common choices.
> The results were good for historical readers, less so today when most folk
> are accustomed to Roman; this challenges the user entering data from an
> historical source.
>
> Such a user can take advantage of a font similar to her source (I make a
> few based on historical tablature fonts) when entering data, especially
> for blackletter, in which case the encoding of the ligatured glyphs might
> need to be specifyable; easy to do, an ordered list of the glyphs gets
> typed at the same time as the input; no need to specify font.
LilyPond *is* strictly an ASCII/UTF-8 based input format. There is *no*
facility for changing fonts used for input. The font used for input is
determined by the editor used for creating the file, which is *not* a
LilyPond editor, in most cases. The only LilyPond editors provided with
LilyPond are very rudimentary text editors, and it's recommended that you
get a better editor to use.
You seem to have most of your wishes for the new tablature capabilities tied
to an advanced input. If that's the case, maybe you ought to be thinking
about two separate stages. One would be a graphical front end that you
could use to enter tablatures any way you like. Its job would be to collect
input in a form that you like it, and convert it to a LilyPond input
ASCII/UTF-8 file. The second would be a modification to LilyPond that wo
Re: major feature request (tablature)
German tabs origins are, like all the forms, obscured by time.
It is reputed to have been invented by Conrad Pauman, mid fifteenth
century, as a way to record music for short-necked lutes having 5 courses.
The notation was extended for lutes having 6 or more courses and more
frets, and we have lots of printed music and ms; but as each publisher and
scribe extended the notation in a personal manner there are variants.
An edition of M Waissel's music printed by J Eichorn in 1573 (Frankfurt an
der oder) shows the fretboard of a 6 course lute with one form of
extension. Note, the fingerboard is viewed from above; intersection of nut
and highest pitched string is labeled 5.
5 e k p v 9 -e -k
4 d j o t 7 -d -j
3 c h n s z -c -h
2 b g m r y -b -g
1 a f l q x -a -f
A B C D E G H -J
another printer (Heckel) and his inheritee (Jobin) uses the following for
6th course
-1 -a -f -l -q -x -aa -ff -ll
>From the first piece in the Waissel edition, "Pass e Mezo" (first row is
flags, giving duration)
1 2 2 1 11 2 2 2 2 2 2 1 2 2 2 2 2 2 ...
5 n 4 5 5 | 5 g 5 o d 4 n | 4 2 o o d 4 n | ...
d d 4 | d 2 | c c 2 | ...
n n h | n | D D | ...
J J A | J | | ...
which might be entered
// 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}
...
While an entirely ascii based input encoding is feasible and protean, the
variety of german systems makes it desireable to allow the user to define
the entry glyphs (which will sometimes be ligatures).
Historical fonts are not always easy to read, typedesigners based their
fonts on the handwriting in use by the presumed readership. Civilte for
french and english tablature, Blackletter for german were common choices.
The results were good for historical readers, less so today when most folk
are accustomed to Roman; this challenges the user entering data from an
historical source.
Such a user can take advantage of a font similar to her source (I make a
few based on historical tablature fonts) when entering data, especially
for blackletter, in which case the encoding of the ligatured glyphs might
need to be specifyable; easy to do, an ordered list of the glyphs gets
typed at the same time as the input; no need to specify font.
I have a list of some more variant glyph lists for 6th and more course
german tab; couldnt find it in a short search at home, hope this is enough
for now.
--
Dana Emery
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: major feature request (tablature)
2008/12/10 Werner LEMBERG <[EMAIL PROTECTED]>: >> > Since you put 'scheme' in single quotes, I suspect you don't know >> > about Scheme programming. Scheme is a Lisp-like programming >> > language. >> >> ()()((()))()()((( >> >> I hope not, that kinda stuff leaves me with a headache, thank the >> gods for programming editors with () balancing. > > Much more important is proper indenting. Very true. Also, Scheme code is _not_ read by looking at the parentheses. Instead, you read it by looking at the indention (which tells you at which 'level' of the code you are). You'll realize that pretty soon you entirely forget about the parentheses. > Scheme's parentheses are > rather easy to handle if you write code like this during development: > > (foo >(bla > ... > bla >) > ) > > and fold it later to > > (foo >(bla > ... > bla)) In fact, I personally find it just as easy to write/read the latter form directly, again because it is the _indentation_ which tells me how a particular piece of code is related to the rest. BTW, you can quickly become addicted to the way you start thinking when programming in Scheme. It's offers you a wholly new paradigm which breaks down a couple of walls you have built yourself up by programming in other languages. I highly recommend giving it a try (especially if you're an experienced programmer). There are excellent tutorials and books out there (although unfortunately I don't have any web addresses at hand). Coming from the Lisp side, I can highly recommend Paul Graham's books "ANSI Common Lisp" and "On Lisp" which IMHO are fluent to read and didactically excellent. But as I said, there are plentiful other resources. Also, keep in mind that Scheme is only a Lisp dialect which means that a couple of things behave differently, so in your case it's probably good to dive into Scheme directly. Good luck and especially: have fun! Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: major feature request (tablature)
On 12/9/08 9:51 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> On Tue, Dec 9, 2008, "Carl D. Sorensen" <[EMAIL PROTECTED]> said:
>> On 12/9/08 4:37 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
>
>> 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
). 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.
>
> n, 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 (altho
Re: major feature request (tablature)
> > Since you put 'scheme' in single quotes, I suspect you don't know > > about Scheme programming. Scheme is a Lisp-like programming > > language. > > ()()((()))()()((( > > I hope not, that kinda stuff leaves me with a headache, thank the > gods for programming editors with () balancing. Much more important is proper indenting. Scheme's parentheses are rather easy to handle if you write code like this during development: (foo (bla ... bla ) ) and fold it later to (foo (bla ... bla)) Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: major feature request (tablature)
On Tue, Dec 9, 2008, "Carl D. Sorensen" <[EMAIL PROTECTED]> said:
> On 12/9/08 4:37 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> 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.
> Code and data structures should be compatible with existing LilyPond code
> and data structures.
compatible, yes, equivalent, I think not; but I have to take a peek at
what you have, and that should be pretty soon, the untar utility is
downloading now.
Maybe I could have gotten more smaller stuff, but the tarball is what I
saw, it came down in minutes and is there, so no biggie.
>> 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.
>> 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.
> 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.
n, that makes german tab unpossible.
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.
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}
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).
> The first thing you will do is add the Scheme code to the LilyPond input
> file. Eventually, once it's debugged, it can be added to the LilyPond
> distribution.
>
> Since you put 'scheme' in single quotes, I suspect you don't know about
> Scheme programming. Scheme is a Lisp-like programming language.
()()((()))()()(((
I hope not, that kinda stuff leaves me with a headache, thank the gods for
programming editors with () balancing.
--
Dana Emery
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: major feature request (tablature)
On 12/9/08 4:37 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
>> 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.
You're confusing users with developers. Code and data structures are
developer-only items.
Input is the user item.
Input can be defined to be practically anything.
Code and data structures should be compatible with existing LilyPond code
and data structures.
>
> 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.
>
> 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...).
You don't need to pull a tar ball! Each of the docs is available as a PDF
or a single page HTML. You can download them directly to your USB drive.
>
>> (which is what the most common popular music
>
> say it, Mel Bay editions :-). I have a couple for banjo.
>
Actually, the largest collection of tabs I find nowadays for popular music
are created in ASCII format on the internet.
>> 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.
Won't every note you want to put on a tab have a pitch, a duration, a string
(or course), and a fret number?
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.
LilyPond has the built in functionality to have the input file contain a
pitch, a duration, and a string indication.
This means that with current LilyPond input and computation functionality,
you can obtain a string, fret, and duration to be used to place on a
tablature staff. No programming is needed at all to obtain the critical
data necessary for your output algorithm. This simplifies your work; you
simply need to focus on how your algorithm will take the fundamental data
(string, fret, duration, and optional finger) and place it on the tablature
staff.
It doesn't matter if the Klingon astroZither has 37 strings of various
pitches, with 15 of them being used only open. LilyPond can create an entry
for each note played on any of the strings. No special input needed
(although it may be desirable, and perhaps should be done later for
convenience). You can be in complete control of the output without adding
any new input features.
>
>> 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?
>
The first thing you will do is add the Scheme code to the LilyPond input
file. Eventually, once it's debugged, it can be added to the LilyPond
distribution.
Since you put 'scheme' in single quotes, I suspect you don't know about
Scheme programming. Scheme is a Lisp-like programming language. A
particular dialect of Scheme, Guile, serves as the LilyPond application
extension language. If you don't know how to program in Scheme, you'll need
to get up to speed on this in order to work with LilyPond. The book I
learned Scheme from (back in 1985) was Structure and Interpretation of
Computer Programs, which is available on line at
. You can also check
out the Guile Reference Manual at
.
>> 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.
I guess I don't need to make it clear to all.
The input format is text based (which I consider to be a great plus).
The untweaked output is superior to any other notation program I've used.
The source is open, so I can add any feature I want.
For me, it's the best available. YMMV.
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: major feature request (tablature)
> 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
Re: major feature request (tablature)
On 12/6/08 2:46 PM, "Danalute" <[EMAIL PROTECTED]> 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.
). 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 wa
Re: major feature request (tablature)
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.
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.
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.
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)
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).
Carl D. Sorensen wrote:
>
>
> We already have the table of open course pitches in LilyPond, it's called
> StringTunings.
>
Good, that should handle stoped courses nicely. Unfortunately the
convention for indicating non-stoped bass courses may require an extension
to it. More on that anon.
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.
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.
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.
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.
--
View this message in context:
http://www.nabble.com/major-feature-request-%28tablature%29-tp20864614p20874953.html
Sent from the Gnu - Lilypond - Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: major feature request (tablature)
On 12/5/08 6:47 PM, "Danalute" <[EMAIL PROTECTED]> wrote: > > > > Reinhold Kainhofer wrote: >> >> > Reinhold Kainhofer wrote: >> >> >> Unfortunately, you don't give any concrete problems with the TabStaff of >> LilyPond. Can you elaborate a little bit on what is not acceptable and >> what >> could be improved? >> > > I wanted to keep that message short, I was asking if the members of this > development team would welcome this issue, at least for discussion, if not > eventual implementation. > I can't speak for the whole development team, but I suspect that nobody on the team is going to run out and implement your desired tablatures (That's the bad news). The good news is that I believe you'll get lots of support if you decide to jump in and become part of the development team to improve tablature. At least that was my experience when I wanted to get fret diagrams added to LilyPond. > There are issues with both the printed results and the grammer for > inputting. I would recommend that you first focus on the printed results. The input syntax can be developed through the use of a new mode (say tabmode, to go along with chordmode and lyricmode), but tabmode by itself does no good. First, focus on getting the output you need. Then, once the output is done you can add the input mode. > > Please do not assume this list is exhaustive. > > For background, many historical plucked instruments had multiple strings > arranged in courses, some used single strings, many a mixture of both > (citterns often had tripple and guadrupple strung middle courses). For > those of you who are unfamiliar with historical tablature, I will begin > with a breif overview. > > Tablature abstracts music by telling you where to place your fingers to make > the notes of it. For a plucked insturment, a list of glyphs may be used to > label nut&fret/string intersections (german), or a shorter list of glyphs > may be used to lable the nut and frets, and course is implied by which line > or space the glyph is placed on (french, italian). Some instruments are > incompletely fretted (diatonic citterns). Some instruments have numerous > bass courses, some of which are not stopped but only sounded open. > 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. > Rows of fret glyphs surmounted by a row of flags make a matrix which defines > chords and gives minimal duration between them. Duration of individual fret > glyphs beyond the flag indications is a matter of players choice. It should > be noted that most of these plucked instruments have limited sustain, more > percussive than sustained, so this limitation in the notation is usually not > an issue for the music. 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. > > German tablature labels each fret/course intersection uniquely emplying an > extended alphabet which is used non-intuitively. Rows of fretglyphs present > strands of musical polyphony. Horizontal lines are sometimes printed to > visually seperate the rows, but have no musical significance. > > French and Italian tablature labels the frets, and presents rows of > fret-glyphs for the notes on each course; with chords aligned vertically. > Italian tab present the first course on the lowest row, french places the > first course in the higest row (just under the flags). Lines are printed > between or thru the glyphs depending on the source. > > Historical tablature always seperates the rythmic flags, in many cases they > are used sparsely (omited when duplicating previous value). Flags are > presented in their own row above the staff, vertically aligned with the fret > glyph(s) they begin. The tablature editions of Otaviano Petrucci have a > unique way, flags float one space above the fretglyphs, rising fast, but > falling slow - avoiding collision with the fretglyphs below them, but also > leading the eye horizontally. > > Present scheme of entry requires (pitch/duration) pairs, this works well for > mensural staff notation and is natural for the musician and composer both in > entry and editing, perfect for \staff. > > Not for \tabstaff tho, the player of a plucked instrument who is using and > editing tablature is thinking of where his fingers are, not what the notes > will be; for \tabstaff it is most natural to think in terms of the fret and > course, not the pitch, and what is thought should be wat is entered, the > computer can and should deal with the conversion (and only as it needs to). > As mentioned above, special input can be done, but should probably be the last part of the package. As LilyPond currently supports fret, course, and finger, it is currently possible to enter music for tablature output. > Freted plucked instruments provide multiple ways to play most of the notes > po
Re: major feature request (tablature)
Reinhold Kainhofer wrote: > > > You mean one tab staff and one mensural staff above each other? What's the > problem with LilyPond? Maybe I'm misunderstanding you here, because you > can > have a tab staff and a mensural staff in a staff group in LilyPond. > I understand I can mix stave types, that was not my point. My point is that tabstaff is needed, but isnt up to the task. Reinhold Kainhofer wrote: > > > Unfortunately, you don't give any concrete problems with the TabStaff of > LilyPond. Can you elaborate a little bit on what is not acceptable and > what > could be improved? > I wanted to keep that message short, I was asking if the members of this development team would welcome this issue, at least for discussion, if not eventual implementation. There are issues with both the printed results and the grammer for inputting. Please do not assume this list is exhaustive. For background, many historical plucked instruments had multiple strings arranged in courses, some used single strings, many a mixture of both (citterns often had tripple and guadrupple strung middle courses). For those of you who are unfamiliar with historical tablature, I will begin with a breif overview. Tablature abstracts music by telling you where to place your fingers to make the notes of it. For a plucked insturment, a list of glyphs may be used to label nut&fret/string intersections (german), or a shorter list of glyphs may be used to lable the nut and frets, and course is implied by which line or space the glyph is placed on (french, italian). Some instruments are incompletely fretted (diatonic citterns). Some instruments have numerous bass courses, some of which are not stopped but only sounded open. Rows of fret glyphs surmounted by a row of flags make a matrix which defines chords and gives minimal duration between them. Duration of individual fret glyphs beyond the flag indications is a matter of players choice. It should be noted that most of these plucked instruments have limited sustain, more percussive than sustained, so this limitation in the notation is usually not an issue for the music. German tablature labels each fret/course intersection uniquely emplying an extended alphabet which is used non-intuitively. Rows of fretglyphs present strands of musical polyphony. Horizontal lines are sometimes printed to visually seperate the rows, but have no musical significance. French and Italian tablature labels the frets, and presents rows of fret-glyphs for the notes on each course; with chords aligned vertically. Italian tab present the first course on the lowest row, french places the first course in the higest row (just under the flags). Lines are printed between or thru the glyphs depending on the source. Historical tablature always seperates the rythmic flags, in many cases they are used sparsely (omited when duplicating previous value). Flags are presented in their own row above the staff, vertically aligned with the fret glyph(s) they begin. The tablature editions of Otaviano Petrucci have a unique way, flags float one space above the fretglyphs, rising fast, but falling slow - avoiding collision with the fretglyphs below them, but also leading the eye horizontally. Present scheme of entry requires (pitch/duration) pairs, this works well for mensural staff notation and is natural for the musician and composer both in entry and editing, perfect for \staff. Not for \tabstaff tho, the player of a plucked instrument who is using and editing tablature is thinking of where his fingers are, not what the notes will be; for \tabstaff it is most natural to think in terms of the fret and course, not the pitch, and what is thought should be wat is entered, the computer can and should deal with the conversion (and only as it needs to). Freted plucked instruments provide multiple ways to play most of the notes possible on them. fret/course pair data is unambiguous are should be what is recorded. A table of open course pitches and simple calculations allows lookup of the pitch for each glyph when its musical semantics are required. This table could be specified as a parameter to the \tabstaff tag as a list of the glyphs for each course (for german), or (for french and italian) as a list for courses i-n. Barogue lutes often had several extra bass course which are are only played open (not stopped). These are commonly treated as if they were stops on the lowest fingered bass course, and need a seperate list of fret glyph with its pitch (not always tuned chromatically). As the flag and fretglyphs are presented seperately, so should they be entered. Musical semantics can (and should be) be derived from stored information. -- View this message in context: http://www.nabble.com/major-feature-request-%28tablature%29-tp20864614p20865774.html Sent from the Gnu - Lilypond - Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list
Re: major feature request (tablature)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Samstag, 6. Dezember 2008 00:38:21 schrieb Danalute: > Tablature is the one I would address. > \tabstaff is not acceptible as it stands; several issues have been recently > noted on the Lute mailling list, [...] > I began to implement support for mensural staff notation, and in doing that > I may have gained a viewpoint which will allow me to help us to get past > the obstacles that make \tabstaff as it is now (2.10.x)unacceptible to many > would-be users. Unfortunately, you don't give any concrete problems with the TabStaff of LilyPond. Can you elaborate a little bit on what is not acceptable and what could be improved? > Users have a need for open scores with mixed staves, both tab and mensural. > Voice and plucked instrument for example, mixed-consort such as flute, > lute, cittern, bandora, treble viol, bass viol is another. How nice it > would be if lilypond could handle that. You mean one tab staff and one mensural staff above each other? What's the problem with LilyPond? Maybe I'm misunderstanding you here, because you can have a tab staff and a mensural staff in a staff group in LilyPond. Cheers, Reinhold - -- - -- Reinhold Kainhofer, Vienna University of Technology, Austria email: [EMAIL PROTECTED], http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJOcJWTqjEwhXvPN0RAhw2AKDQe0RJ8/0ntvGfD1J/T7oLscGROACeI9Xz WOdVPF1IGepAB/3Zu84P0Gw= =jW79 -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
major feature request (tablature)
I know this was brought up some years ago, and shotdown as basically going against the grain, but I think it can be done, done well, and integrated with benefit to all. No problem with engraved music, but it isnt all that is needed. The orchestra pit is far from the only place where music has a marketplace; but it is orchestral score scribal practice that Lilypond seems to have taken as its total focus; there are other practices which this ignores. Tablature is the one I would address. \tabstaff is not acceptible as it stands; several issues have been recently noted on the Lute mailling list, but I think the main one is that it may draw too heavily on the present \staff concepts. I know (having done) that it is possible to encode a GUI-based C++ tablature program which is parameter-defined and can handle french, italian, german major forms as well as all the variations on them (polish, neapolitan, spanish, guitar...) for arbitrary plucked instruments. Given suitable fonts (of which I have made several) it is possible to publish replicas of historical editions; it is even possible to transliterate freely from one form to another (eg, entering german from an historical facsimile, proofing visually and aurally, then transliterating to the user prefered form, perhaps french). Sadly, bugs and apples greed conspire to prevent me from finishing that and releasing it, too much work for this one programmer. I began to implement support for mensural staff notation, and in doing that I may have gained a viewpoint which will allow me to help us to get past the obstacles that make \tabstaff as it is now (2.10.x)unacceptible to many would-be users. Users have a need for open scores with mixed staves, both tab and mensural. Voice and plucked instrument for example, mixed-consort such as flute, lute, cittern, bandora, treble viol, bass viol is another. How nice it would be if lilypond could handle that. Finale, Sibelius, Lilypond all say they can do it, but all have drawbacks; and it really should be possible for us to do better. -- View this message in context: http://www.nabble.com/major-feature-request-%28tablature%29-tp20864614p20864614.html Sent from the Gnu - Lilypond - Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
