BB <bblo...@arcor.de> writes:
> I come up with one of my ideas again in a feature request.
>
> If one simply transfers music to TabStaff as a rule some notes in a Tab make
> trouble because they are not bound to a string. Often notes are interpreted
> out of range of the instrument. So the user dediously has to correct the
> notes of the tab. Sometimes notes are omitted and kill triples, pull offs,
> hammer ons and the bar structure. One gets just a crippled and useless tab.
>
> Example code:
>
> \version "2.16.2"
> % Tested with
> % \version 2.17.23-1
> % as well
>
>
>
> \new TabStaff {
> \key g \major
> \set TabStaff.tablatureFormat = #fret-number-tablature-format-banjo
> \set TabStaff.stringTunings = #banjo-open-g-tuning
> \tabFullNotation
> \stemDown
> \relative c'
> {
> \times 2/3{d,^" P " (c)^" H" (d)} %1. quarter note
> d^" P" (c) %2. quarter note
> %\times 2/3{gis^" H " (f')^" P" (g)} %3. quarter note
> %g8^" H" (a) <d b g>8 g %4. quarter note
> }
> }
>
>
> There could be support by lilypond very easily!
Uh what? c is not a note on a Banjo in open G tuning. There is no way
LilyPond can support the play of non-existing notes.
> As a rule the next note of a tune very likely is close to the note
> just befor. (That is a result of many scientific investigations i.e.
> http://csjarchive.cogsci.rpi.edu/proceedings/2011/papers/0843/paper0843.pdf,
> http://www.etbu.edu/opencms/handle404?exporturi=/export/sites/default/Academics/universityScholars/siteResources/past_honors_projects/Jennifer_Shafer.pdf
> - and lots more. Cluster theory comes to a similar conclusion! The
> graphics show that the change of frequency squared is highest with
> little change!) May be modern and atonal music follows other rules!
>
> Therefore, if lilypond uses the closest note to the note before with the
> defined name, the chance to fit is highest!
Uh, that's called "\relative" note entry.
> In case of undefined octaves lilypond simply should take the closest
> note to that immediatly before. Example: if a note d is following a
> c, most likely the d close to c (two halfsteps) is required. I think
> it is a good idea to mark such a note set by lilypond with a red
> colour as a sign for the user to check it and eventually change it.
So LilyPond should iterate back and forth over music second-guessing the
user? And decide that sometimes \relative mode is right, and sometimes
wrong, and make an educated guess where to break continuity and diverge
from what the user entered?
And you call that "There could be support by LilyPond very easily"?
This is so confused that I have a hard time counting this as a "feature
request".
Having LilyPond point out unplayable notes by source location is a
reasonable request, and that's what Issue 3484
<URL:http://code.google.com/p/lilypond/issues/detail?id=3484> is about.
Once that makes it into LilyPond, LilyPond shells like Emacs or
Frescobaldi will flag the bad notes in the source code.
That's as good as it gets. I don't see a reasonably reliable way for
LilyPond to do second-guessing based on a particular instrument, and one
would not actually do the user much of a favor since a change of
instrument would suddenly cause a change of octave relations in the
score.
--
David Kastrup
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
