[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tablatures] Re: Ancient tablatures

From: Carl Sorensen
Subject: Re: [tablatures] Re: Ancient tablatures
Date: Tue, 6 Oct 2009 15:20:41 -0600

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

> Laura Conrad schrieb:
>>>>>>> "Marc" == Marc Hohl <address@hidden> 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
>> <
>> <> > (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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]