Re: [tablatures] Re: Ancient tablatures

[ Thread Index | Date Index | More lilynet.net/tablatures Archives ] 

Carl Sorensen schrieb:


On 10/6/09 12:22 PM, "Marc Hohl" <marc@xxxxxxxxxx> wrote:


Laura Conrad schrieb:

"Marc" == Marc Hohl <marc@xxxxxxxxxx> writes:

    Marc> I am not at all familiar with these old tablatures, but they
    Marc> look just amazing, so simply for typographic and aesthetical
    Marc> reasons, these should be made possible with lilypond.

Actually, there are good musical reasons, too.  In the 16th and maybe
most of the 17th, and in some places longer than that, the
dominant instrument which could play many notes at a time was the
lute, or various other plucked string instruments which could read the
same tablature.

I assumed that these tablatures are still used, but in fact I did see them,
but never had to /decrypt/ them for myself.

So this means that lots of the kinds of music which would later be
published with keyboard accompaniment, which lilypond transcribes very
well, was published with lute tablature.

So my edition of all the part songs of John Dowland
<http://serpentpublications.org/wordpress/?page_id=22=4
<http://serpentpublications.org/wordpress/?page_id=22&id=4> > (which
many people think of as lute songs, but most of them are really
accompanied madrigals) is really incomplete, because I've
only transcribed the vocal lines, and in general not the lute
tablature.

For a lot of them, the lute tablature is very little different from
just a transcription of the vocal lines, but in others there's a lot
of decoration. 
I've made some efforts to transcribe the tablature, but what I want
ideally is to transcribe what's there, in an input form that doesnt'
require me to translate the tablature into notes, and then use that
transcription plus the tuning of the strings to produce both a
tablature that looks like the one in the facsimile and standard
notation that a modern keyboard player could deal with.

That's an interesting point - I think Dana Emery posted to the
users list that writing tablature as normal notation and letting lilypond
do the translation into tablature is at least not always the best way.

For me, it is most of the time, but I can think of situations where
Iit may not, and the lute tablatures are a great example where the coding
should work "the other way 'round".

Lute players should note that I'm aware that tablature has different
information from notation: specifically that the beginning time of the
note is specified, but not the length of the note.  However, I believe
that good keyboard players are just as capable as lute players of
making the decision about where to end the note; they just aren't as
capable as players of 6-course fretted instruments of playing
tablature for 6-course fretted instruments.

Hm, then let's try to nail it down: how would you like to input
tablature? As I can see in the literature I have about lute music,
getting lilypond to produce the desired output is possible (yes, it will
be a lot of work, but ... ) But I find the input structure more
interesting, because even a new kind of input format can probably be
provided by lilypond (don't speak about the time to implement that),
or we can use some converters which translate the lute tablature
into lilypond syntax, which again translates this into a nicely
formatted tablature.


You're free to start with the input if you like, but I think the best
approach is to start with the output.  Ultimately, to work in the LilyPond
framework, there are going to have to be events.  It's possible that the
events may be lute-tab-note events, but that doesn't seem likely to me.  I
expect that they will be note events, evaluated in a lute-tab-voice context.

There could be a lute-mode developed for input, but I wouldn't start there.

If you start with the output, based on given LilyPond structures, you can
create useful lute tablatures with the current input.  Then, either the user
can use the non-optimal input, or a simple translator can be developed that
takes the optimal input and converts it to valid LilyPond input.  Such an
easy converter wouldn't needed to be integrated with LilyPond and might be
an easy way to get a prototype mode working.

The output seems to me to be quite consistent with the LilyPond
infrastructure.  There are note indications placed on a staff, along with
some fingering indications as well.  There are aslo some marks placed over
the staff that depend on the duration of the note, IIUC.  And there are some
marks placed under the staff.  All of these capabilities are in the current
LilyPond output set.  So getting the output mode to work should be
relatively straightforward.

If you start with the input mode, then until both the input mode and the
output mode are fixed, there's no possibility of getting such a tablature.

If you look at the history of fret diagrams, you'll see that fret diagrams
as markups were instituted a long time (I think about 6 years, IIRC) before
fret diagrams as output from chordmode input.  That's 6 years of useful
output that would be unavailable if I had started with the input (my natural
tendency) instead of starting with the output (Han-Wen's recommendation).

Again, I'm not a boss here, laying down the law of how somebody needs to
implement lute tablature.  I'm giving my experience (and passing along
Han-Wen's recommendation) of the quickest way to get a new feature into the
output.

Hello Carl,

I was somehow expecting that you would object to my provocative question.

I never intended to start with the new input mode, although it would be
helpful to have at least an idea of how it would look like (kind of a "holistic" approach). 

No, my intention was the simple fact that I (stimulated through Dana Emerys
proposals in the archives) started to think about an alternative way of coding tablature (in terms of an input structure). At first glance, it seemed simple, but it isn't. The most satisfying solution that I've come across is probably some kind of a two-dimensional structure, but there are still unsolved issues concerning the length of the notes etc. So my motivation was simply curiosity - perhaps someone has digged deeper 
and has already developed a input structure perfectly adapted to tablature.
So in conclusion, I fully agree with you, when such a task is started, there should be to focus on the output, and this is a goal that seems to be reachable within a decent amount of time. 

Marc

HTH,

Carl



_______________________________________________
lilypond-user mailing list
lilypond-user@xxxxxxx
http://lists.gnu.org/mailman/listinfo/lilypond-user

Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/