Baroque lute tablature

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Baroque lute tablature

Trevor D-2
Carl et al

I was inspired by the appearance of the Baroque lute tablature
produced by Fronimo and the interest shown in adding this capability
to LilyPond by several users, including Dana Emery, Laura Conrad,
Marc Hohl and others recently.  I've been considering how this
functionality might be added to LilyPond.  As a reminder, examples
of this tablature can be seen at
http://www.mateus-lutes.com/tablature/.

I've attached a pdf showing what can be achieved by modifying the
input stream to insert markups to render the durations above the
tab context and the bass courses below the tab context, but
otherwise
using just standard LilyPond input syntax, as shown below.  This is
the first two systems from the mateus-lutes site referenced above.

The Scheme for doing this is rather messy - it was just a lash-up
to see what was possible by applying a function to the input
stream -
but as this is not the way it should be implemented I'm not
attaching
it.

Here's what I've learned:

a) Most of the glyphs needed to output Baroque lute tablature
would need to be designed.  The glyphs used for the fret indications
and bass courses I 'borrowed' from the Fronimo site - these would
need
to be redesigned for LilyPond as the Fronimmo licence does not
permit
commercial use.  The glyphs used for the durations are taken from
the
standard LilyPond font set, but are not so beautiful as the Fronimo
durations; they could with advantage be redesigned but are OK for a
starter.  There are also a few more glyphs like the section
separator
and end-of-piece indicator that would need to be designed.

b) Markups above and below a standard tab seems quite satisfactory
to indicate durations and bass courses, and are easy to implement.

c) Right hand fingerings and string indications can be easily
rendered
in Baroque style, although the precise placement of the right hand
fingerings will need more control.

d) I haven't yet looked into adding the decorations (the comma, the
small curve and line under notes) mainly because I'm not sure what
they represent musically.

e) But the big lesson is that transcribing from tab to tab via
notemode is totally impractical.  I and many lutenists do not
know what pitch a particular fingering generates.  A tabmode entry
form will be essential.  This has some obvious difficulties,
the main one being the lack of information about how accidentals
should be represented when outputted in a standard staff.  Not
sure what to do about this.

OK, I've rambled on long enough.  What I want to know is whether
I should continue with this.  I'm confident we can produce
acceptable
output from standard notemode input, but I'm equally confident
this would be of little use to lutenists without tabmode input.
I'm also confident tabmode input can be provided without too much
difficulty for Baroque lute, using letters to represent frets, but
how should accidental indications be made, and would this be of any
use to other forms of fretted instruments?

So a few thoughts and comments from others would be very helpful.

Trevor

ps, here's the input I used for the attached file

notes = {
  % Usual string tuning for 13-course Baroque lute
  \set stringTunings = #'(17 14 9 5 2 -3 -5 -7 -8 -10 -12 -13 -15)
  \relative c'' {
    \time 3/4
    \key d \minor
    \partial 4.
    <a-\RF #1 >8 <g-1-\RF #5 > a |
    <f d-\RF #5 >4. <f-\RF #1 >8 < g-2 e-1 >4 |
    <a f f-3\5-\RF #5 >4_( <a f-\RF #1 > d8) <g,-1-\RF #5 > |
    <cis-4 a-3\4-\RF #5 >4 <a,\6>8 <g'-1-\RF #1 > <f> <e-1-\RF #1 >
|
    <d' a d,,>4 <e-2-\RF #2 >8
    \once \override Glissando #'(bound-details left Y) = #2.3
    \once \override Glissando #'(bound-details right Y) = #1.3
    \once \override Glissando #'extra-offset = #'(-0.5 . 0)
    <f-\RF #1 >16
    \glissando <e-2-\RF #1 > <f-\RF #2 >8 <d,-\RF #5 > |
    \break
    <a-\RF #5 >4 <c'-4-\RF #1 >8 <e,-2-\RF #5 > <f-3\5-\RF #5 >_(
<c'-4-\RF #1 >) |
    <bes-1 d, g,>4. <e,-2-\RF #1 >8 <a f f,>4 |
    <g-2-\RF #1 c,,>4 <f-2-\RF #2 >8 <e-1-\RF #1 >16 <f-\RF #2 >
<e-1-\RF #1 >8 <c-3> |
    <f d-\RF #5 >8 <g-2-\RF #1 > <a-\RF #2 > <c,-3> <bes-1>_(
<g'-2-\RF #1 >) |
    <a a,>8 <bes-1-\RF #1 > <c-4-\RF #2 > <f,-\RF #1 > <bes-1 g,>
<e,-2-\RF #1 > |
  }


lutetab-as-markup-16.pdf (215K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Baroque lute tablature

Laura Conrad-2
>>>>> "Trevor" == Trevor Daniels <[hidden email]> writes:

    Trevor> This has some obvious difficulties, the main one being the
    Trevor> lack of information about how accidentals should be
    Trevor> represented when outputted in a standard staff.  Not sure
    Trevor> what to do about this.

It seems to be the same problem as MIDI -- there isn't really a
concept of a key signature in tablature, so to translate tablature to
standard notation you need to know the key signature as well as the
raw notes.

    Trevor> OK, I've rambled on long enough.  What I want to know is
    Trevor> whether I should continue with this.  I'm confident we can
    Trevor> produce acceptable output from standard notemode input,
    Trevor> but I'm equally confident this would be of little use to
    Trevor> lutenists without tabmode input.

I agree.

    Trevor> I'm also confident tabmode input can be provided without
    Trevor> too much difficulty for Baroque lute, using letters to
    Trevor> represent frets, but how should accidental indications be
    Trevor> made,


People who use tablature more than I do can correct me, but I don't
think there is such a thing as an accidental in tablature.

So when you input the tablature, the user who is going to want to
translate the tab to standard notation is going to have to give a
tuning table, and they should also expect to give a key signature, and
maybe some other spellings.  But I really don't think it's as hard to
guess the spelling of an accidental from the key signature as most of
the people who write MIDI to standard notation programs try to
pretend.

In other words, I think a key signature of A minor should imply that
the note between G and A is spelled g# and not Ab, and maybe there
should be some input syntax to let users correct that assumption if
there's some strange excursion from A minor into Eb major, but really
for most baroque music, that doesn't happen.  And of course, if the
key is C major, the program probably does need some guidance about
whether it's Ab or G#.  

So we need not only a tuning table and a key signature but also a
spelling table for accidentals, which for non-major modes would
include a sharped seventh by default.  Dorian modes should probably
include a flat sixth by default.  That is, a piece with a D dorian key
signature is likely to slip into G minor, with Bb's all over the
place.

    Trevor> and would this be of any use to other forms of fretted
    Trevor> instruments?

Viol players historically used the same kind of tablature as lute
players.

--
Laura   (mailto:[hidden email])
(617) 661-8097 233 Broadway, Cambridge, MA 02139  
http://www.laymusic.org/ http://www.serpentpublications.org

Mom got to be quite a rabid fan, though...Everything I did was
sensational as far as she was concerned.  Now my father, as far as
*he* was concerned I never got a hit.  If I got a single, my mother
would scream, "Willie's hit a triple."  And Pop would say, "Ach, the
guy should have caught it."

Willie Kamm, quoted in "The Glory of their Times" by Lawrence S. Ritter



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Baroque lute tablature

Marc Hohl
In reply to this post by Trevor D-2
Trevor Daniels schrieb:

> Carl et al
>
> I was inspired by the appearance of the Baroque lute tablature
> produced by Fronimo and the interest shown in adding this capability
> to LilyPond by several users, including Dana Emery, Laura Conrad,
> Marc Hohl and others recently.  I've been considering how this
> functionality might be added to LilyPond.  As a reminder, examples
> of this tablature can be seen at http://www.mateus-lutes.com/tablature/.
>
> I've attached a pdf showing what can be achieved by modifying the
> input stream to insert markups to render the durations above the
> tab context and the bass courses below the tab context, but otherwise
> using just standard LilyPond input syntax, as shown below.  This is
> the first two systems from the mateus-lutes site referenced above.
Wow, I am very impressed! I had some preliminary ideas of implementing it,
but I was still far away from doing so ... great job!

>
> The Scheme for doing this is rather messy - it was just a lash-up
> to see what was possible by applying a function to the input stream -
> but as this is not the way it should be implemented I'm not attaching
> it.
>
> Here's what I've learned:
>
> a) Most of the glyphs needed to output Baroque lute tablature
> would need to be designed.  The glyphs used for the fret indications
> and bass courses I 'borrowed' from the Fronimo site - these would need
> to be redesigned for LilyPond as the Fronimmo licence does not permit
> commercial use.  The glyphs used for the durations are taken from the
> standard LilyPond font set, but are not so beautiful as the Fronimo
> durations; they could with advantage be redesigned but are OK for a
> starter.  There are also a few more glyphs like the section separator
> and end-of-piece indicator that would need to be designed.
Some years ago, I worked with metafont, so implementing this font seems
to be doable, but a complete list of the signs needed in this font would be
crucial (I am not the fastest guy on earth with respect to metafont, but
I would like to give it a try).

>
> b) Markups above and below a standard tab seems quite satisfactory
> to indicate durations and bass courses, and are easy to implement.
>
> c) Right hand fingerings and string indications can be easily rendered
> in Baroque style, although the precise placement of the right hand
> fingerings will need more control.
>
> d) I haven't yet looked into adding the decorations (the comma, the
> small curve and line under notes) mainly because I'm not sure what
> they represent musically.
>
> e) But the big lesson is that transcribing from tab to tab via
> notemode is totally impractical.  I and many lutenists do not
> know what pitch a particular fingering generates.  A tabmode entry
> form will be essential.  
There are two situations: when you need *only* tablature output,
you don't need to bother about the key signature, because it doesn't show
up in tablature. When you want lilypond to display normal notation
in addition to the tablature, you'll have to set the key signature for
yourself,
because (at least in my opinion) there is no algorithm which can cover all
situations in a satisfying way.

A tablature input mode is very useful for electric guitar, too. There are
many situations where only tablature is needed, so the double translation
(fret board to notation for lilypond input and lilypond's translation into
tablature again) is just not straightforward.
> This has some obvious difficulties,
> the main one being the lack of information about how accidentals
> should be represented when outputted in a standard staff.  Not
> sure what to do about this.
As Laura pointed out in her response, there are no accidentals in tablature
(this doesn't make sense in my opinion).

>
> OK, I've rambled on long enough.  What I want to know is whether
> I should continue with this.  
Yes, please!
> I'm confident we can produce acceptable
> output from standard notemode input, but I'm equally confident
> this would be of little use to lutenists without tabmode input.
> I'm also confident tabmode input can be provided without too much
> difficulty for Baroque lute, using letters to represent frets,
Would it be too difficult to expand the input format to fret numbers, so
a user has a choice to use lute letters or fret numbers? This would be
a big step forward for lilypond.

> but
> how should accidental indications be made, and would this be of any
> use to other forms of fretted instruments?
>
> So a few thoughts and comments from others would be very helpful.
>
> Trevor
>
> ps, here's the input I used for the attached file
>
> notes = {
>  % Usual string tuning for 13-course Baroque lute
>  \set stringTunings = #'(17 14 9 5 2 -3 -5 -7 -8 -10 -12 -13 -15)
>  \relative c'' {
>    \time 3/4
>    \key d \minor
>    \partial 4.
>    <a-\RF #1 >8 <g-1-\RF #5 > a |
>    <f d-\RF #5 >4. <f-\RF #1 >8 < g-2 e-1 >4 |
>    <a f f-3\5-\RF #5 >4_( <a f-\RF #1 > d8) <g,-1-\RF #5 > |
>    <cis-4 a-3\4-\RF #5 >4 <a,\6>8 <g'-1-\RF #1 > <f> <e-1-\RF #1 > |
>    <d' a d,,>4 <e-2-\RF #2 >8
>    \once \override Glissando #'(bound-details left Y) = #2.3
>    \once \override Glissando #'(bound-details right Y) = #1.3
>    \once \override Glissando #'extra-offset = #'(-0.5 . 0)
>    <f-\RF #1 >16
>    \glissando <e-2-\RF #1 > <f-\RF #2 >8 <d,-\RF #5 > |
>    \break
>    <a-\RF #5 >4 <c'-4-\RF #1 >8 <e,-2-\RF #5 > <f-3\5-\RF #5 >_(
> <c'-4-\RF #1 >) |
>    <bes-1 d, g,>4. <e,-2-\RF #1 >8 <a f f,>4 |
>    <g-2-\RF #1 c,,>4 <f-2-\RF #2 >8 <e-1-\RF #1 >16 <f-\RF #2 >
> <e-1-\RF #1 >8 <c-3> |
>    <f d-\RF #5 >8 <g-2-\RF #1 > <a-\RF #2 > <c,-3> <bes-1>_( <g'-2-\RF
> #1 >) |
>    <a a,>8 <bes-1-\RF #1 > <c-4-\RF #2 > <f,-\RF #1 > <bes-1 g,>
> <e,-2-\RF #1 > |
>  }
>



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Baroque lute tablature

Patrick Schmidt-3
In reply to this post by Trevor D-2

-------- Original-Nachricht --------
> Datum: Sun, 15 Nov 2009 16:11:06 -0000
> Von: "Trevor Daniels" <[hidden email]>
> An: [hidden email]
> Betreff: [tablatures] Baroque lute tablature

> Carl et al
>
> I was inspired by the appearance of the Baroque lute tablature
> produced by Fronimo and the interest shown in adding this capability
> to LilyPond by several users, including Dana Emery, Laura Conrad,
> Marc Hohl and others recently.  I've been considering how this
> functionality might be added to LilyPond.  As a reminder, examples
> of this tablature can be seen at
> http://www.mateus-lutes.com/tablature/.
>
> I've attached a pdf showing what can be achieved by modifying the
> input stream to insert markups to render the durations above the
> tab context and the bass courses below the tab context, but
> otherwise
> using just standard LilyPond input syntax, as shown below.  This is
> the first two systems from the mateus-lutes site referenced above.
Looks very impressive!

>
> The Scheme for doing this is rather messy - it was just a lash-up
> to see what was possible by applying a function to the input
> stream -
> but as this is not the way it should be implemented I'm not
> attaching
> it.
>
> Here's what I've learned:
>
> a) Most of the glyphs needed to output Baroque lute tablature
> would need to be designed.  The glyphs used for the fret indications
> and bass courses I 'borrowed' from the Fronimo site - these would
> need
> to be redesigned for LilyPond as the Fronimmo licence does not
> permit
> commercial use.  The glyphs used for the durations are taken from
> the
> standard LilyPond font set, but are not so beautiful as the Fronimo
> durations; they could with advantage be redesigned but are OK for a
> starter.  There are also a few more glyphs like the section
> separator
> and end-of-piece indicator that would need to be designed.
>
> b) Markups above and below a standard tab seems quite satisfactory
> to indicate durations and bass courses, and are easy to implement.
>
> c) Right hand fingerings and string indications can be easily
> rendered
> in Baroque style, although the precise placement of the right hand
> fingerings will need more control.
>
> d) I haven't yet looked into adding the decorations (the comma, the
> small curve and line under notes) mainly because I'm not sure what
> they represent musically.

comma:  means appogiatura from above (Pull off, "accent") if it appears to the right of a letter. I believe it can also take the form of ")" or "^"

small curve under notes: means appogiatura from below (Hammer on, Mersenne calls it "accent plaintif")

line *above* notes: means appogiatura from a semitone below ("half-fall")
>
> e) But the big lesson is that transcribing from tab to tab via
> notemode is totally impractical.  I and many lutenists do not
> know what pitch a particular fingering generates.  A tabmode entry
> form will be essential.  This has some obvious difficulties,
> the main one being the lack of information about how accidentals
> should be represented when outputted in a standard staff.  Not
> sure what to do about this.
I'm not sure if I understand the problem. Wouldn't it be rather clear how to represent accidentals if users were to add a \key-command in tabmode like \key d \minor and the tuning of the strings (in combination with some LilyPond-definitions for each key of the most probable accidentals that should be outputted in standard staff, e.g. in d minor: c sharp instead of d flat)?
>
> OK, I've rambled on long enough.  What I want to know is whether
> I should continue with this.
yes, please!
  I'm confident we can produce
> acceptable
> output from standard notemode input, but I'm equally confident
> this would be of little use to lutenists without tabmode input.
> I'm also confident tabmode input can be provided without too much
> difficulty for Baroque lute, using letters to represent frets, but
> how should accidental indications be made, and would this be of any
> use to other forms of fretted instruments?
>
I haven't seen any accidental indications in tablature so far, either.

> So a few thoughts and comments from others would be very helpful.
>
> Trevor
>
> ps, here's the input I used for the attached file
>
> notes = {
>   % Usual string tuning for 13-course Baroque lute
>   \set stringTunings = #'(17 14 9 5 2 -3 -5 -7 -8 -10 -12 -13 -15)
>   \relative c'' {
>     \time 3/4
>     \key d \minor
>     \partial 4.
>     <a-\RF #1 >8 <g-1-\RF #5 > a |
>     <f d-\RF #5 >4. <f-\RF #1 >8 < g-2 e-1 >4 |
>     <a f f-3\5-\RF #5 >4_( <a f-\RF #1 > d8) <g,-1-\RF #5 > |
>     <cis-4 a-3\4-\RF #5 >4 <a,\6>8 <g'-1-\RF #1 > <f> <e-1-\RF #1 >
> |
>     <d' a d,,>4 <e-2-\RF #2 >8
>     \once \override Glissando #'(bound-details left Y) = #2.3
>     \once \override Glissando #'(bound-details right Y) = #1.3
>     \once \override Glissando #'extra-offset = #'(-0.5 . 0)
>     <f-\RF #1 >16
>     \glissando <e-2-\RF #1 > <f-\RF #2 >8 <d,-\RF #5 > |
>     \break
>     <a-\RF #5 >4 <c'-4-\RF #1 >8 <e,-2-\RF #5 > <f-3\5-\RF #5 >_(
> <c'-4-\RF #1 >) |
>     <bes-1 d, g,>4. <e,-2-\RF #1 >8 <a f f,>4 |
>     <g-2-\RF #1 c,,>4 <f-2-\RF #2 >8 <e-1-\RF #1 >16 <f-\RF #2 >
> <e-1-\RF #1 >8 <c-3> |
>     <f d-\RF #5 >8 <g-2-\RF #1 > <a-\RF #2 > <c,-3> <bes-1>_(
> <g'-2-\RF #1 >) |
>     <a a,>8 <bes-1-\RF #1 > <c-4-\RF #2 > <f,-\RF #1 > <bes-1 g,>
> <e,-2-\RF #1 > |
>   }
>

--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Baroque lute tablature

Trevor D-2
In reply to this post by Laura Conrad-2

Laura Conrad wrote Sunday, November 15, 2009 5:01 PM


>>>>>> "Trevor" == Trevor Daniels <[hidden email]> writes:
>
>    Trevor> This has some obvious difficulties, the main one being
> the
>    Trevor> lack of information about how accidentals should be
>    Trevor> represented when outputted in a standard staff.  Not
> sure
>    Trevor> what to do about this.
>
> It seems to be the same problem as MIDI -- there isn't really a
> concept of a key signature in tablature, so to translate tablature
> to
> standard notation you need to know the key signature as well as
> the
> raw notes.

Yes, exactly.  Although, as you explain below, knowing
the key signature is not enough when the music modulates
through several keys.  Part of the problem with MIDI is
that the key signature is often not actually specified.

>    Trevor> I'm also confident tabmode input can be provided
> without
>    Trevor> too much difficulty for Baroque lute, using letters to
>    Trevor> represent frets, but how should accidental indications
> be
>    Trevor> made,
>
>
> People who use tablature more than I do can correct me, but I
> don't
> think there is such a thing as an accidental in tablature.
>
> So when you input the tablature, the user who is going to want to
> translate the tab to standard notation is going to have to give a
> tuning table, and they should also expect to give a key signature,
> and
> maybe some other spellings.  But I really don't think it's as hard
> to
> guess the spelling of an accidental from the key signature as most
> of
> the people who write MIDI to standard notation programs try to
> pretend.
>
> In other words, I think a key signature of A minor should imply
> that
> the note between G and A is spelled g# and not Ab, and maybe there
> should be some input syntax to let users correct that assumption
> if
> there's some strange excursion from A minor into Eb major, but
> really
> for most baroque music, that doesn't happen.

Bach??  But perhaps he didn't write much in tablature.

> And of course, if the
> key is C major, the program probably does need some guidance about
> whether it's Ab or G#.
>
> So we need not only a tuning table and a key signature but also a
> spelling table for accidentals, which for non-major modes would
> include a sharped seventh by default.  Dorian modes should
> probably
> include a flat sixth by default.  That is, a piece with a D dorian
> key
> signature is likely to slip into G minor, with Bb's all over the
> place.

Thanks Laura.  This is very helpful and seems to be the
way to go.  As we proceed we shall need to discuss the
precise form these tuning tables and spelling tables.

>    Trevor> and would this be of any use to other forms of fretted
>    Trevor> instruments?
>
> Viol players historically used the same kind of tablature as lute
> players.

I was thinking of a wider range of instruments.  If we make
each feature required for Baroque lute tablature individually
controllable and set up those required by a Baroque lute in
an init file they could also be used in other set-ups.  Features
like using numbers or letters for frets, style of right-hand
fingering, style of decorations, etc.  This seems to be the
way to go, rather than having a monolithic Baroque lute tab
state.

Trevor



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Baroque lute tablature

Trevor D-2
In reply to this post by Marc Hohl

Marc Hohl wrote Sunday, November 15, 2009 7:11 PM


> Trevor Daniels schrieb:
>>
>> a) Most of the glyphs needed to output Baroque lute tablature
>> would need to be designed.  The glyphs used for the fret
>> indications
>> and bass courses I 'borrowed' from the Fronimo site - these would
>> need
>> to be redesigned for LilyPond as the Fronimmo licence does not
>> permit
>> commercial use.  The glyphs used for the durations are taken from
>> the
>> standard LilyPond font set, but are not so beautiful as the
>> Fronimo
>> durations; they could with advantage be redesigned but are OK for
>> a
>> starter.  There are also a few more glyphs like the section
>> separator
>> and end-of-piece indicator that would need to be designed.
>>
> Some years ago, I worked with metafont, so implementing this font
> seems
> to be doable, but a complete list of the signs needed in this font
> would be
> crucial (I am not the fastest guy on earth with respect to
> metafont, but
> I would like to give it a try).

OK, great!  I'd no idea how to do this, so that would
be very helpful.  We need to flesh out quite a bit more
of the design before we get to this stage though.

>> e) But the big lesson is that transcribing from tab to tab via
>> notemode is totally impractical.  I and many lutenists do not
>> know what pitch a particular fingering generates.  A tabmode
>> entry
>> form will be essential.
>
> There are two situations: when you need *only* tablature output,
> you don't need to bother about the key signature, because it
> doesn't show
> up in tablature. When you want lilypond to display normal notation
> in addition to the tablature, you'll have to set the key signature
> for yourself,
> because (at least in my opinion) there is no algorithm which can
> cover all
> situations in a satisfying way.

Agreed it is difficult, but Laura has suggested a possible
approach.

> A tablature input mode is very useful for electric guitar, too.
> There are
> many situations where only tablature is needed, so the double
> translation
> (fret board to notation for lilypond input and lilypond's
> translation into
> tablature again) is just not straightforward.

Yes, that's exactly the problem.

>> This has some obvious difficulties,
>> the main one being the lack of information about how accidentals
>> should be represented when outputted in a standard staff.  Not
>> sure what to do about this.
>
> As Laura pointed out in her response, there are no accidentals in
> tablature
> (this doesn't make sense in my opinion).

The difficulty only arises if a standard staff form is
required too.

>> OK, I've rambled on long enough.  What I want to know is whether
>> I should continue with this.
>
> Yes, please!

OK, I'll continue.

>> I'm confident we can produce acceptable
>> output from standard notemode input, but I'm equally confident
>> this would be of little use to lutenists without tabmode input.
>> I'm also confident tabmode input can be provided without too much
>> difficulty for Baroque lute, using letters to represent frets,
>
> Would it be too difficult to expand the input format to fret
> numbers, so
> a user has a choice to use lute letters or fret numbers? This
> would be
> a big step forward for lilypond.

To be frank I don't know at this stage how easy this
would be.  I was able to use letters to represent fret
numbers rather than pitch without changing the lexer/parser,
but this was just a private hack to make it easier to enter
some test cases.  If we decide to implement a genuine
tabmode input form it should be certainly be possible, but
I don't know what the problems would be.

Trevor



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Baroque lute tablature

Trevor D-2
In reply to this post by Patrick Schmidt-3

Patrick Schmidt wrote Sunday, November 15, 2009 7:25 PM

>> Von: "Trevor Daniels" <[hidden email]>
>>
>> d) I haven't yet looked into adding the decorations (the comma,
>> the
>> small curve and line under notes) mainly because I'm not sure
>> what
>> they represent musically.
>
> comma:  means appogiatura from above (Pull off, "accent") if it
> appears to the right of a letter. I believe it can also take the
> form of ")" or "^"
>
> small curve under notes: means appogiatura from below (Hammer on,
> Mersenne calls it "accent plaintif")
>
> line *above* notes: means appogiatura from a semitone below
> ("half-fall")

Ah, thanks!  That makes more sense now.

>> e) But the big lesson is that transcribing from tab to tab via
>> notemode is totally impractical.  I and many lutenists do not
>> know what pitch a particular fingering generates.  A tabmode
>> entry
>> form will be essential.  This has some obvious difficulties,
>> the main one being the lack of information about how accidentals
>> should be represented when outputted in a standard staff.  Not
>> sure what to do about this.
>
> I'm not sure if I understand the problem. Wouldn't it be rather
> clear how to represent accidentals if users were to add a
> \key-command in tabmode like \key d \minor and the tuning of the
> strings (in combination with some LilyPond-definitions for each
> key of the most probable accidentals that should be outputted in
> standard staff, e.g. in d minor: c sharp instead of d flat)?

If the key is known a good guess can usually be made,
but not if the key modulates.

>> OK, I've rambled on long enough.  What I want to know is whether
>> I should continue with this.
>
> yes, please!

OK, I'll continue.  Next step is set out an implementation
plan.

Trevor



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Baroque lute tablature

Valentin Villenave
Administrator
On Mon, Nov 16, 2009 at 12:58 PM, Trevor Daniels <[hidden email]> wrote:
> OK, I'll continue.  Next step is set out an implementation
> plan.

BTW: Do you need something in the tracker or does #865 cover it?

Cheers,
Valentin


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Baroque lute tablature

Patrick Schmidt-3
In reply to this post by Trevor D-2

-------- Original-Nachricht --------
> Datum: Mon, 16 Nov 2009 11:58:09 -0000
> Von: "Trevor Daniels" <[hidden email]>
> An: "Patrick Schmidt" <[hidden email]>, [hidden email]
> Betreff: Re: [tablatures] Baroque lute tablature

>
> Patrick Schmidt wrote Sunday, November 15, 2009 7:25 PM
>
> >> Von: "Trevor Daniels" <[hidden email]>
> >>
> >> d) I haven't yet looked into adding the decorations (the comma,
> >> the
> >> small curve and line under notes) mainly because I'm not sure
> >> what
> >> they represent musically.
> >
> > comma:  means appogiatura from above (Pull off, "accent") if it
> > appears to the right of a letter. I believe it can also take the
> > form of ")" or "^"
> >
> > small curve under notes: means appogiatura from below (Hammer on,
> > Mersenne calls it "accent plaintif")
> >
> > line *above* notes: means appogiatura from a semitone below
> > ("half-fall")
>
> Ah, thanks!  That makes more sense now.
>
> >> e) But the big lesson is that transcribing from tab to tab via
> >> notemode is totally impractical.  I and many lutenists do not
> >> know what pitch a particular fingering generates.  A tabmode
> >> entry
> >> form will be essential.  This has some obvious difficulties,
> >> the main one being the lack of information about how accidentals
> >> should be represented when outputted in a standard staff.  Not
> >> sure what to do about this.
> >
> > I'm not sure if I understand the problem. Wouldn't it be rather
> > clear how to represent accidentals if users were to add a
> > \key-command in tabmode like \key d \minor and the tuning of the
> > strings (in combination with some LilyPond-definitions for each
> > key of the most probable accidentals that should be outputted in
> > standard staff, e.g. in d minor: c sharp instead of d flat)?
>
> If the key is known a good guess can usually be made,
> but not if the key modulates.
True, but I rather wanted to propose to implement a feature which makes it possible to change the tonality within tabmode without necessarily changing the key signature. That is to say a command like e.g. "\mode c\mixolydian" which you can use within a piece to take care of temporary modulations. The fret numbers would be interpreted in the new mode. But I haven't a clue whether this is feasible. To me this would be comparable to adjusting the playing position with e.g. "\set TabStaff.minimumFret = #7"  in traditional notation. Does that make sense?

>
> >> OK, I've rambled on long enough.  What I want to know is whether
> >> I should continue with this.
> >
> > yes, please!
>
> OK, I'll continue.  Next step is set out an implementation
> plan.
>
> Trevor
>
>

--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Baroque lute tablature

Carl Sorensen
In reply to this post by Trevor D-2
Trevor,

This is beautiful.  Thanks for getting started on this!


On 11/16/09 4:50 AM, "Trevor Daniels" <[hidden email]> wrote:

>
>
> Marc Hohl wrote Sunday, November 15, 2009 7:11 PM
>
>
>> Trevor Daniels schrieb:
>
>>> e) But the big lesson is that transcribing from tab to tab via
>>> notemode is totally impractical.  I and many lutenists do not
>>> know what pitch a particular fingering generates.  A tabmode
>>> entry
>>> form will be essential.
>>
>> There are two situations: when you need *only* tablature output,
>> you don't need to bother about the key signature, because it
>> doesn't show
>> up in tablature. When you want lilypond to display normal notation
>> in addition to the tablature, you'll have to set the key signature
>> for yourself,
>> because (at least in my opinion) there is no algorithm which can
>> cover all
>> situations in a satisfying way.
>
> Agreed it is difficult, but Laura has suggested a possible
> approach.

I realize it's early on this, but you may want to consider the possibility
of a "note indicator" on tabmode input.  This would override the standard
function for a particular tab entry, just like we currently have a string
indicator on notes in order to override the standard tab calculation.

>>> I'm confident we can produce acceptable
>>> output from standard notemode input, but I'm equally confident
>>> this would be of little use to lutenists without tabmode input.
>>> I'm also confident tabmode input can be provided without too much
>>> difficulty for Baroque lute, using letters to represent frets,
>>
>> Would it be too difficult to expand the input format to fret
>> numbers, so
>> a user has a choice to use lute letters or fret numbers? This
>> would be
>> a big step forward for lilypond.
>
> To be frank I don't know at this stage how easy this
> would be.  I was able to use letters to represent fret
> numbers rather than pitch without changing the lexer/parser,
> but this was just a private hack to make it easier to enter
> some test cases.  If we decide to implement a genuine
> tabmode input form it should be certainly be possible, but
> I don't know what the problems would be.

I don't know what the problems might be, either.  I think that allowing
numbers to be the start of a "note" may cause problems with shift/reduce
conflicts in the parser.  I'd expect it to be easier to start with the
implementation of letters for fret indications.

At any rate, I think it's fantastic that you've decided to get working on
this!  Thanks a million!

Carl



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Baroque lute tablature

Trevor D-2
In reply to this post by Valentin Villenave

Valentin Villenave wrote Monday, November 16, 2009 12:31 PM


> On Mon, Nov 16, 2009 at 12:58 PM, Trevor Daniels
> <[hidden email]> wrote:
>> OK, I'll continue. Next step is set out an implementation
>> plan.
>
> BTW: Do you need something in the tracker or does #865 cover it?

I think 865 covers it just fine.  I've added a brief comment.

> Valentin

Trevor




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Baroque lute tablature

Laura Conrad-2
In reply to this post by Patrick Schmidt-3
>>>>> "Patrick" == Patrick Schmidt <[hidden email]> writes:

    Patrick> True, but I rather wanted to propose to implement a
    Patrick> feature which makes it possible to change the tonality
    Patrick> within tabmode without necessarily changing the key
    Patrick> signature. That is to say a command like e.g. "\mode
    Patrick> c\mixolydian" which you can use within a piece to take
    Patrick> care of temporary modulations.


The way I see it, you say something like:

    \key c \major
    \accidentals des, ees, fis

And then when you've looked at the results you may see a Db that you
want to be a C#, so then before that note  you say:

     \accidentals cis

It might actually make more sense to have a tabstaff.accidentals
variable that can be overridden and reverted.

I think putting in key and mode specifications for the crazy Bach
modulations would be hard work, but noticing what accidentals are
misspelled is just a normal form of proofreading.

--
Laura   (mailto:[hidden email])
(617) 661-8097 233 Broadway, Cambridge, MA 02139  
http://www.laymusic.org/ http://www.serpentpublications.org

Just as there are no atheists in foxholes, there are no intellectuals
on stage.

Ian Bostridge, quoted in The Boston Globe, April 3, 2009


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Baroque lute tablature

Marc Hohl
In reply to this post by Trevor D-2
Trevor Daniels schrieb:

>
> Marc Hohl wrote Sunday, November 15, 2009 7:11 PM
>
>
>> Trevor Daniels schrieb:
>>>
>>> a) Most of the glyphs needed to output Baroque lute tablature
>>> would need to be designed.  The glyphs used for the fret indications
>>> and bass courses I 'borrowed' from the Fronimo site - these would need
>>> to be redesigned for LilyPond as the Fronimmo licence does not permit
>>> commercial use.  The glyphs used for the durations are taken from the
>>> standard LilyPond font set, but are not so beautiful as the Fronimo
>>> durations; they could with advantage be redesigned but are OK for a
>>> starter.  There are also a few more glyphs like the section separator
>>> and end-of-piece indicator that would need to be designed.
>>>
>> Some years ago, I worked with metafont, so implementing this font seems
>> to be doable, but a complete list of the signs needed in this font
>> would be
>> crucial (I am not the fastest guy on earth with respect to metafont, but
>> I would like to give it a try).
>
> OK, great!  I'd no idea how to do this, so that would
> be very helpful.  We need to flesh out quite a bit more
> of the design before we get to this stage though.
Ok, I wouldn't have started it today, either ;-)

Marc


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Baroque lute tablature

Patrick Schmidt-3
In reply to this post by Laura Conrad-2


-------- Original-Nachricht --------
> Datum: Mon, 16 Nov 2009 10:11:07 -0500
> Von: Laura Conrad <[hidden email]>
> An: "Patrick Schmidt" <[hidden email]>
> CC: "Trevor Daniels" <[hidden email]>, [hidden email]
> Betreff: Re: [tablatures] Baroque lute tablature

> >>>>> "Patrick" == Patrick Schmidt <[hidden email]> writes:
>
>     Patrick> True, but I rather wanted to propose to implement a
>     Patrick> feature which makes it possible to change the tonality
>     Patrick> within tabmode without necessarily changing the key
>     Patrick> signature. That is to say a command like e.g. "\mode
>     Patrick> c\mixolydian" which you can use within a piece to take
>     Patrick> care of temporary modulations.
>
>
> The way I see it, you say something like:
>
>     \key c \major
>     \accidentals des, ees, fis
>
> And then when you've looked at the results you may see a Db that you
> want to be a C#, so then before that note  you say:
>
>      \accidentals cis

Not really. I thought we're talking about a (new) tabmode entry which allows to enter fret numbers (or letters signifying frets) instead of letters signifying notenames. An example (LilyPond excerpt of a german Christmas Carol – not crazy Bach! ;-) The melody modulates temporarily form g to d major):
   
      \key g \major
      \time 4/4
      \relative c' {
      a a b cis |
      d2 a |
      b4 e d cis |
      e2 d |
      }

A hypothetical tabmode entry of the same excerpt (\3 and \2 means string number; numbers without underscore signify fret numbers (quarter notes); e.g. 2_2 stands for fret 2, half note:

      \key g \major
      \time 4/4
      { \3 2 2 \2 0 2 |
      3_2 \3 2_2 |
      \2 0 \1 0 \2 3 2 |
      \1 0_2 \2 3_2 | }

As I understand it the problem is: How to teach LilyPond how to interpret the fret numbers. The second fret on the second string could mean a "c sharp" or a "d flat". So one way could be to write something like "\accidentals cis" in front of each occurrence of "\2 2". It might be even more comfortable to be able to write something like "\mode d\major" in front of the first occurrence of "\2 2" and all the following cis-notes on any string are engraved correctly. When the melody modulates back to g-major you would have to change the mode again.

Just an idea.

>
> It might actually make more sense to have a tabstaff.accidentals
> variable that can be overridden and reverted.
>
> I think putting in key and mode specifications for the crazy Bach
> modulations would be hard work, but noticing what accidentals are
> misspelled is just a normal form of proofreading.
>
> --
> Laura   (mailto:[hidden email])
> (617) 661-8097 233 Broadway, Cambridge, MA 02139  
> http://www.laymusic.org/ http://www.serpentpublications.org
>
> Just as there are no atheists in foxholes, there are no intellectuals
> on stage.
>
> Ian Bostridge, quoted in The Boston Globe, April 3, 2009
>

--
DSL-Preisknaller: DSL Komplettpakete von GMX schon für
16,99 Euro mtl.!* Hier klicken: http://portal.gmx.net/de/go/dsl02


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Baroque lute tablature

Laura Conrad-2
>>>>> "Patrick" == Patrick Schmidt <[hidden email]> writes:

    Patrick> Not really. I thought we're talking about a (new) tabmode
    Patrick> entry which allows to enter fret numbers (or letters
    Patrick> signifying frets) instead of letters signifying
    Patrick> notenames.

Yes, we are.

    Patrick> As I understand it the problem is: How to teach LilyPond
    Patrick> how to interpret the fret numbers. The second fret on the
    Patrick> second string could mean a "c sharp" or a "d flat". So
    Patrick> one way could be to write something like "\accidentals
    Patrick> cis" in front of each occurrence of "\2 2".

But I think in general we should be able to write "\accidentals cis"
at the beginning of the whole piece, or even in a lot of cases have
the program know that a key signature of D minor implies "\accidentals
cis".  

    Patrick> It might be even more comfortable to be able to write
    Patrick> something like "\mode d\major" in front of the first
    Patrick> occurrence of "\2 2" and all the following cis-notes on
    Patrick> any string are engraved correctly. When the melody
    Patrick> modulates back to g-major you would have to change the
    Patrick> mode again.

Not really.  If there isn't a C#, having the "\accidentals cis" in
effect doesn't matter; the only reason you would need to change it
would be if there were a note you wanted to spell as Db.  

I'm saying that asking people to do harmonic analysis on a piece is
asking more than just asking them how to spell the accidentals.  And
anyone reading the transcription would have to think harder to realize
that "\mode g \dorian" means that there should be a Bb rather than an
A# than if it just said "\accidentals bes".  And if someone gets the
analysis wrong and doesn't notice because the accidentals are spelled
right, it will be confusing to a subsequent reader.  This happens
with key signatures all the time -- the fact that the lilypond (or
ABC) key signature contains information that isn't in the printed
music is a good thing when the information is correct, but not so good
when it's wrong.

It's true that if there's a sudden modulation from C major to Db
major, and then to G# major, that's typing a lot of accidentals, but
in real-world tab, I really don't think that happens so often.  I
don't remember a John Dowland piece that uses both G# and Ab, for
instance.  Yes, I'm sure you can find a Bach piece that does, but did
he write it in tablature?

--
Laura   (mailto:[hidden email])
(617) 661-8097 233 Broadway, Cambridge, MA 02139  
http://www.laymusic.org/ http://www.serpentpublications.org

A zen teacher once taught his students, "When drinking tea, just drink
tea."  Later one of them found him drinking tea and reading the
newspaper.  When confronted, the teacher replied, "When drinking tea
and reading the newspaper, just drink tea and read the newspaper."

Quoted by Michelle Poirot in the New York Times, October 11, 2009


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Baroque lute tablature

Patrick Schmidt-3

-------- Original-Nachricht --------
> Datum: Tue, 17 Nov 2009 08:07:59 -0500
> Von: Laura Conrad <[hidden email]>
> An: "Patrick Schmidt" <[hidden email]>
> CC: [hidden email], [hidden email]
> Betreff: Re: [tablatures] Baroque lute tablature

> >>>>> "Patrick" == Patrick Schmidt <[hidden email]> writes:
>
>     Patrick> Not really. I thought we're talking about a (new) tabmode
>     Patrick> entry which allows to enter fret numbers (or letters
>     Patrick> signifying frets) instead of letters signifying
>     Patrick> notenames.
>
> Yes, we are.
>
>     Patrick> As I understand it the problem is: How to teach LilyPond
>     Patrick> how to interpret the fret numbers. The second fret on the
>     Patrick> second string could mean a "c sharp" or a "d flat". So
>     Patrick> one way could be to write something like "\accidentals
>     Patrick> cis" in front of each occurrence of "\2 2".
>
> But I think in general we should be able to write "\accidentals cis"
> at the beginning of the whole piece, or even in a lot of cases have
> the program know that a key signature of D minor implies "\accidentals
> cis".  
Sounds reasonable.

>
>     Patrick> It might be even more comfortable to be able to write
>     Patrick> something like "\mode d\major" in front of the first
>     Patrick> occurrence of "\2 2" and all the following cis-notes on
>     Patrick> any string are engraved correctly. When the melody
>     Patrick> modulates back to g-major you would have to change the
>     Patrick> mode again.
>
> Not really.  If there isn't a C#, having the "\accidentals cis" in
> effect doesn't matter; the only reason you would need to change it
> would be if there were a note you wanted to spell as Db.  
>
> I'm saying that asking people to do harmonic analysis on a piece is
> asking more than just asking them how to spell the accidentals.  And
> anyone reading the transcription would have to think harder to realize
> that "\mode g \dorian" means that there should be a Bb rather than an
> A# than if it just said "\accidentals bes".  And if someone gets the
> analysis wrong and doesn't notice because the accidentals are spelled
> right, it will be confusing to a subsequent reader.  This happens
> with key signatures all the time -- the fact that the lilypond (or
> ABC) key signature contains information that isn't in the printed
> music is a good thing when the information is correct, but not so good
> when it's wrong.
True.
>
> It's true that if there's a sudden modulation from C major to Db
> major, and then to G# major, that's typing a lot of accidentals, but
> in real-world tab, I really don't think that happens so often.  I
> don't remember a John Dowland piece that uses both G# and Ab, for
> instance.  Yes, I'm sure you can find a Bach piece that does, but did
> he write it in tablature?
Well Bach probably didn't write his pieces in tablature but there exist a couple of transcriptions of anonymous contemporaries of Bach's works for the baroque lute in (French) tablature.

>
> --
> Laura   (mailto:[hidden email])
> (617) 661-8097 233 Broadway, Cambridge, MA 02139  
> http://www.laymusic.org/ http://www.serpentpublications.org
>
> A zen teacher once taught his students, "When drinking tea, just drink
> tea."  Later one of them found him drinking tea and reading the
> newspaper.  When confronted, the teacher replied, "When drinking tea
> and reading the newspaper, just drink tea and read the newspaper."
>
> Quoted by Michelle Poirot in the New York Times, October 11, 2009
>

--
DSL-Preisknaller: DSL Komplettpakete von GMX schon für
16,99 Euro mtl.!* Hier klicken: http://portal.gmx.net/de/go/dsl02


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Baroque lute tablature

Trevor D-2
In reply to this post by Trevor D-2

Trevor Daniels wrote 16 November 2009 11:58

> OK, I'll continue.  Next step is set out an implementation
> plan.

Sorry for hiatus - some other things came up.

I see the implementation proceeding in three phases:

Phase I: Implement lute tab output from notemode input with basic
facilities

I suggest these basic facilities:

  Lettered fret indications
  Duration changes
  Bass courses
  Laissez vibrer indication as slur
  Right-hand fingerings
  Left-hand fingerings

The glyphs to be used will be those currently available in LilyPond.

This will require resolving (at least!) these issues:

  How should bass course tunings be specified?
  Baroque lute tab context definitions
  Use markup above/below tab or some other approach?
  How much can be done in Scheme?
  Is a new engraver needed or should an existing one be modified?
  What context and grob properties are required?

Phase II: Implement tabmode input

Issues to be resolved: (much less clear at present)

  Input syntax for tablature
  Syntax for defining accidentals to be used for Staff output
  How/when to convert to notemode
  How this is to be implemented

Phase III: Tidy up and implement additional features

Some to consider:

  Decorations
  Laissez vibrer indication with correct end point
  Improved glyphs
  End of section and end of piece indications
  Double pluck indication (diagonal line between two frets)
  Simultaneous pluck indication (vertical line with decoration)
  Italian style

Comments on this welcome.

At the moment I'm setting up a suitable unix-based development
environment.  That might take a little while ....

Trevor










Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Baroque lute tablature

Carl Sorensen



On 11/22/09 3:57 AM, "Trevor Daniels" <[hidden email]> wrote:

>
>
> Trevor Daniels wrote 16 November 2009 11:58
>
>> OK, I'll continue.  Next step is set out an implementation
>> plan.
>
> Sorry for hiatus - some other things came up.
>
> I see the implementation proceeding in three phases:
>
> Phase I: Implement lute tab output from notemode input with basic
> facilities
>
> I suggest these basic facilities:
>
>   Lettered fret indications
>   Duration changes
>   Bass courses
>   Laissez vibrer indication as slur
>   Right-hand fingerings
>   Left-hand fingerings
>
> The glyphs to be used will be those currently available in LilyPond.
>
> This will require resolving (at least!) these issues:
>
>   How should bass course tunings be specified?

There are two options I can think of:

1.  Add a bassTunings property that lists the bass courses
2.  Add the bass course tunings to stringTunings, and add a new property
that indicates the number of bass courses.

I think I prefer option 1.  Since we need to add a property anyway, it might
as well be the bass course tunings, which is the information we realy want
to have answered.

>   Baroque lute tab context definitions
>   Use markup above/below tab or some other approach?

I think that the quickest thing to do would be to use markups.

But I think the best thing to do is to create some new engravers.  I haven't
thought carefully about the names, but they'd be something like
lute_notehead_engraver, lute_stem_engraver, and lute_bass_engraver.  Then
we'd have the proper logical entries.

>   How much can be done in Scheme?

All *can* be done in Scheme, but I don't think it all should.  New engravers
are in C++.

>   Is a new engraver needed or should an existing one be modified?

See above.

>   What context and grob properties are required?

This will come out as you get things implemented.

>
> Phase II: Implement tabmode input
>
> Issues to be resolved: (much less clear at present)
>
>   Input syntax for tablature
>   Syntax for defining accidentals to be used for Staff output
>   How/when to convert to notemode
>   How this is to be implemented
>
> Phase III: Tidy up and implement additional features
>
> Some to consider:
>
>   Decorations
>   Laissez vibrer indication with correct end point
>   Improved glyphs
>   End of section and end of piece indications
>   Double pluck indication (diagonal line between two frets)
>   Simultaneous pluck indication (vertical line with decoration)
>   Italian style

You may want this to be part of Phase I, as it will help govern the context
and grob properties desired.

HTH,

Carl



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Baroque lute tablature

Trevor D-2

Carl Sorensen wrote Sunday, November 22, 2009 3:08 PM

> On 11/22/09 3:57 AM, "Trevor Daniels" <[hidden email]>
> wrote:
>>
>> I see the implementation proceeding in three phases:
>>
>> Phase I: Implement lute tab output from notemode input with basic
>> facilities
>>
>> This will require resolving (at least!) these issues:
>>
>>   How should bass course tunings be specified?
>
> There are two options I can think of:
>
> 1.  Add a bassTunings property that lists the bass courses
> 2.  Add the bass course tunings to stringTunings, and add a new
> property
> that indicates the number of bass courses.
>
> I think I prefer option 1.  Since we need to add a property
> anyway, it might
> as well be the bass course tunings, which is the information we
> realy want
> to have answered.

I do too.  It means the existing tab-related code would
not be affected.

>>   Baroque lute tab context definitions
>>   Use markup above/below tab or some other approach?
>
> I think that the quickest thing to do would be to use markups.
>
> But I think the best thing to do is to create some new engravers.
> I haven't
> thought carefully about the names, but they'd be something like
> lute_notehead_engraver, lute_stem_engraver, and
> lute_bass_engraver.  Then
> we'd have the proper logical entries.

The problem with this is that quite a lot of the
existing tab-related code for noteheads would be
duplicated in the new engraver.  The only real change
is to use letters rather than numbers.  But new
lute-stem-engraver and lute-bass-engraver sound sensible.

>>   How much can be done in Scheme?
>
> All *can* be done in Scheme, but I don't think it all should.  New
> engravers
> are in C++.

OK, I can cope with that.  Actually I'm probably happier
in C++ than Scheme, although I have little real experience
with neither.  I shall need to get more familiarity with
ubuntu and compiling though.  This might slow things up
a bit.

>> Phase III: Tidy up and implement additional features
>>
>> Some to consider:
>>
>>   Decorations
>>   Laissez vibrer indication with correct end point
>>   Improved glyphs
>>   End of section and end of piece indications
>>   Double pluck indication (diagonal line between two frets)
>>   Simultaneous pluck indication (vertical line with decoration)
>>   Italian style
>
> You may want this to be part of Phase I, as it will help govern
> the context
> and grob properties desired.

I left these until later as they all raise new
problems and I didn't want to hold up I and II
because of that.  Surely any properties they require
can be added when we come to code them, can't they ??

Trevor




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Baroque lute tablature

Carl Sorensen



On 11/23/09 10:48 AM, "Trevor Daniels" <[hidden email]> wrote:

>
>
> Carl Sorensen wrote Sunday, November 22, 2009 3:08 PM
>
>> On 11/22/09 3:57 AM, "Trevor Daniels" <[hidden email]>
>> wrote:
>>>   Baroque lute tab context definitions
>>>   Use markup above/below tab or some other approach?
>>
>> I think that the quickest thing to do would be to use markups.
>>
>> But I think the best thing to do is to create some new engravers.
>> I haven't
>> thought carefully about the names, but they'd be something like
>> lute_notehead_engraver, lute_stem_engraver, and
>> lute_bass_engraver.  Then
>> we'd have the proper logical entries.
>
> The problem with this is that quite a lot of the
> existing tab-related code for noteheads would be
> duplicated in the new engraver.  The only real change
> is to use letters rather than numbers.  But new
> lute-stem-engraver and lute-bass-engraver sound sensible.

Ahh, you're correct, having thought about it more than me.

>
>>>   How much can be done in Scheme?
>>
>> All *can* be done in Scheme, but I don't think it all should.  New
>> engravers
>> are in C++.
>
> OK, I can cope with that.  Actually I'm probably happier
> in C++ than Scheme, although I have little real experience
> with neither.  I shall need to get more familiarity with
> ubuntu and compiling though.  This might slow things up
> a bit.
>

Actually, if it's done correctly, it will likely be a mix of C++ and scheme.
The standard way to do it is to have the C++ handle the events, then call a
scheme routine to actually create the output.


>>> Phase III: Tidy up and implement additional features
>>>
>>> Some to consider:
>>>
>>>   Decorations
>>>   Laissez vibrer indication with correct end point
>>>   Improved glyphs
>>>   End of section and end of piece indications
>>>   Double pluck indication (diagonal line between two frets)
>>>   Simultaneous pluck indication (vertical line with decoration)
>>>   Italian style
>>
>> You may want this to be part of Phase I, as it will help govern
>> the context
>> and grob properties desired.
>
> I left these until later as they all raise new
> problems and I didn't want to hold up I and II
> because of that.  Surely any properties they require
> can be added when we come to code them, can't they ??
>

Of course they can.  It's no problem to save them for later.  And since it's
your project, you can work on it in any order you want.

If it were my project, I'd probably try to get decorations, double pluck
indication, and simultaneous pluck indication in Phase I.

I'd probably also do Italian style in phase I.

I'd leave Laissez vibrer, end of section, end of piece, and improved glyphs
for phase III.

But that's just personal preference.  And it reflects the way I chose to
work on fret diagrams.  I got every feature I could think of implemented in
markup fret diagrams before I put them in the FretBoards context.

I think your plan is marvelous.

Thanks,

Carl




> Trevor
>
>
>
>



12
Loading...