[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Harmonics in tablature
From: |
Lukas-Fabian Moser |
Subject: |
Re: Harmonics in tablature |
Date: |
Mon, 29 Jun 2020 11:57:05 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 |
Hi Valentin,
1) Yes. Without my mistake it calculates on which fret the sounding note would
be, thus placing the note head onto the correct string. I’m sorry for that.
Yes - thanks much! Now it works as expected (at least by me):
If
i) #pitch is the pitch of an open string (as defined with \set
TabStaff.stringTunings), and
ii) #fret-number is the number of a fret that "can" create a harmonic note,
\harmonicByFret #fret-number #pitch
now prints
a) in a TabStaff: the instruction to create a harmonic on fret
#fret-number on the string tuned to #pitch
b) in a Staff: the resulting sounding pitch when doing so.
I very much think that this should be made the standard behaviour of
\harmonicByFret.
[To be precise, stringTunings seems to expect that strings are created
lowest-to-highest; but I readily admit that non-monotonic tunings are
not really common.]
If #pitch is not an open string, the result is not meaningful, as you
already said.
On a violin or cello, I would expect that non-open-string #pitch should
create artificial harmonics (for which, in particular, one would need
some kind of graphical representation in tabs indicating the use of two
fingers on the same string), namely, playing #pitch on a stopped
position and then adding a harmonic finger #fret-number frets above that
position. But I actually do not even know if artificial harmonics are
used at all on instruments for which we create tabs.
2) Yes, you are right about that. The nomenclature might be a bit confusing,
but it helps to thing of the pitch in calc-harmonic-pitch as ratio.
Then why is calc-harmonic-pitch hand-tailored if it could be implemented
by \transpose c' #pitch #music ?
About your example: What exactly does not work? This look exactly like I would
expect from the lilypond code.
... and this _I_ did mess up. Sorry.
In Staceys example, I stumbled across the following strange thing where
\relative behaves strangely:
mus = \relative c,, { \harmonicByRatio #1/4 <e\3 a\2>2. }
<<
\new TabStaff
{
\set Staff.stringTunings = \stringTuning <a,,, e,, a,, e, a, cis>
\tabFullNotation
\mus
}
\new Staff \mus
>>
In my desire to reproduce this problem with \harmonicByFret I
custom-made it by entering a large octave offset in a relative code
myself. Stupid me.
But I admit that, while I spent some time yesterday to try and
understand \harmonicByFret, I still have to do this for
\harmonicByRatio, so maybe there's a simple explanation.
3) Forcing a string number can be done manually easily (though this is not
good if the tuning changes at some point). But in code it is quite a bit more
effort to achieve the same result, because we then would need to read the
string tunings from the context and determine for each single note on which
string that is. By simply setting minimumFret to an appropriate value (sorry
again), we can achieve the same result without coding the same thing multiple
times. Only problem is that doing it this way will override minimumFret
directions done before.
I admit that I still have to understand the way LilyPond figures out the
correct position in tablature of a note: I understand that
\harmonicByFret calculates the sounding pitch, but this implied that
there must be a mechanism that forces a tab position for the note that
does not correspond with its actual sounding pitch. (Which can also be
seen if we use your improved \harmonicByFret to create a harmonic on a
non-open string: The sounding pitch changes, the displayed tab doesn't.)
Lukas