[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is Anyone Working on a Better Tablature Algorithm?
From: |
David Kastrup |
Subject: |
Re: Is Anyone Working on a Better Tablature Algorithm? |
Date: |
Thu, 10 Nov 2016 22:05:44 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) |
christopher-heckman <address@hidden> writes:
> David Kastrup wrote
>> christopher-heckman <
>
>> ccheckman@
>
>> > writes:
>>
>>> In the past few years, a couple of algorithms have been released which
>>> do a better job for tablature. Since Lilypond uses one of the most
>>> naïve ones (not much different from the one that TuxGuitar uses), it
>>> might be time for an update.
>>>
>>> Is anyone working on this? I haven't been able to find any information
>>> on current projects.
>>
>> Personally I think there should be a _translator_ doing the string/fret
>> assignment and recording it into the music expression.
>>
>> Why?
>>
>> This translator can keep context and, for example, default to using the
>> identical assignment for repeated chords, continued _notes_ and similar.
>
> I strongly disagree with you on this.
The following rather sounds like you strongly disagree with something
else. No idea what.
> If you are playing the guitar, especially if you are playing passages
> with lots of notes, you may not always want to go to the same
> fingering for the chord. There are cases where you would have to shift
> your hand position by 5 or 10 frets, play one chord, and move
> back. This is not idea.
>
>
>> It can also be employed at TabStaff level (rather than at TabVoice
>> level) in order to create a workable assignment for polyphonic
>> guitar/lute play.
>
> The algorithm I have in mind does work for polyphony, so it can be
> used at the staff level. (And that would be how I would design it: for
> the entire piece.)
I thought you strongly disagreed with keeping context, like "the entire
piece"?
> It would accept a musical expression and then add the string (and
> fingering) information to the notes.
Some disagreement that is...
>> So with a bit of retooling, one end up with a more versatile set of
>> modular tools than what we have now.
>
> Which begs the question that I started off with: Is anyone working on
> this?
Not that I know of.
--
David Kastrup