Handling of open strings in tablature

Handling of open strings in tablature

This patch creates a switch called ignoreOpenStrings. When set to #f
(default), LilyPond handles open strings as usual.

Setting ignoreOpenStrings to #t excludes open strings and
forces the fret calculation routine to find a fretted position
even for pitches equal to an open string.

[Julien Rioux, 2012-02-26 06:07:39]

1 line adds whitespace errors. That's all.
Regards,
Julien

http://codereview.appspot.com/5695058/diff/6001/input/regression/tablature-op...
File input/regression/tablature-open-string-handling.ly (right):

http://codereview.appspot.com/5695058/diff/6001/input/regression/tablature-op...
input/regression/tablature-open-string-handling.ly:19: 
git complains about a new blank line at EOF here.

[marc, 2012-02-26 07:44:51]

Am 26.02.2012 07:07, schrieb julien.rioux@gmail.com:
> 1 line adds whitespace errors. That's all.
> Regards,
> Julien
>
>
>
http://codereview.appspot.com/5695058/diff/6001/input/regression/tablature-op...

>
> File input/regression/tablature-open-string-handling.ly (right):
>
>
http://codereview.appspot.com/5695058/diff/6001/input/regression/tablature-op...

>
> input/regression/tablature-open-string-handling.ly:19:
> git complains about a new blank line at EOF here.
Ok, corrected. Sorry.
>
> http://codereview.appspot.com/5695058/
>

[Carl, 2012-02-27 00:17:05]

Looks like a good solution.

I think I would prefer the name excludeOpenStrings to ignoreOpenStrings.

I think "exclude" is a better word for what is happening than "ignore"

Thanks,

Carl

[dak, 2012-02-27 09:01:32]

On 2012/02/27 00:17:05, Carl wrote:
> Looks like a good solution.
> 
> I think I would prefer the name excludeOpenStrings to ignoreOpenStrings.
> 
> I think "exclude" is a better word for what is happening than "ignore"

I am actually not all too happy with either choice since, if I understand it
correctly, the proper name would be somewhat like
dontTreatOpenStringsSpecially: they are excluded or ignored only if minimumFret
(or so) is set to a value greater than 0.

But then I can't think of a usefully better name.

[marc, 2012-02-27 10:51:25]

Am 27.02.2012 10:01, schrieb dak@gnu.org:
> On 2012/02/27 00:17:05, Carl wrote:
>> Looks like a good solution.
>
>> I think I would prefer the name excludeOpenStrings to
> ignoreOpenStrings.
>
>> I think "exclude" is a better word for what is happening than "ignore"
>
> I am actually not all too happy with either choice since, if I
> understand it correctly, the proper name would be somewhat like
> dontTreatOpenStringsSpecially: they are excluded or ignored only if
> minimumFret (or so) is set to a value greater than 0.
Whereas dontTreatOpenStringsSpecially is probably the proper word,
I'll go for excludeOpenStrings.

I hope I corrected everything accordingly, because I screwed up my local
branch ... :-(

Regards,

Marc
>
> But then I can't think of a usefully better name.
>
> http://codereview.appspot.com/5695058/
>

[dak, 2012-02-27 11:09:44]

On 2012/02/27 10:51:25, marc wrote:
> I hope I corrected everything accordingly, because I screwed up my local
> branch ... :-(

That's quite improbable to do thoroughly with git.

Try git reflog and see whether a useful copy is sitting among the given
references.

[dak, 2012-02-27 11:19:50]

Instead of dontTreatOpenStringsSpecially, something like omitOpenStrings or
skipOpenStrings looks less like an active special action for open strings, and
maybe normalOpenStrings or fingerOpenStrings or fretOpenStrings suggests that
the point is to include them in the normal calculations instead of treating them
exceptionally.

No, I am not happy with all that, but I am pretty sure we will have users that
have a problem understanding that "excludeOpenStrings" means that we _include_
them in the normal fret distance calculations.

[marc, 2012-02-27 18:33:14]

Am 27.02.2012 12:19, schrieb dak@gnu.org:
> Instead of dontTreatOpenStringsSpecially, something like omitOpenStrings
Well, omitOpenStrings sounds quite good IMHO. Before I do another patch,
any suggestions/corrections from other string-addicted people ;-) ?

Regards,

Marc
> or skipOpenStrings looks less like an active special action for open
> strings, and maybe normalOpenStrings or fingerOpenStrings or
> fretOpenStrings suggests that the point is to include them in the normal
> calculations instead of treating them exceptionally.
>
> No, I am not happy with all that, but I am pretty sure we will have
> users that have a problem understanding that "excludeOpenStrings" means
> that we _include_ them in the normal fret distance calculations.
>
> http://codereview.appspot.com/5695058/
>

[marc, 2012-02-27 18:46:04]

Am 27.02.2012 12:09, schrieb dak@gnu.org:
> On 2012/02/27 10:51:25, marc wrote:
>> I hope I corrected everything accordingly, because I screwed up my
> local
>> branch ... :-(
>
> That's quite improbable to do thoroughly with git.
Well, I did it.

I don't know what happened, but most probably a git reset --hard in the 
wrong
branch :-(
>
> Try git reflog and see whether a useful copy is sitting among the given
> references.
>
I downloaded the raw patch and applied it - the original description is
on the internet, too, so it wasn't all that complicated.
> http://codereview.appspot.com/5695058/
>