| Re: [tablatures] Re: bends: pre-implementation issues |
[ Thread Index |
Date Index
| More lilynet.net/tablatures Archives
]
On 1/4/10 12:29 PM, "Marc Hohl" <marc@xxxxxxxxxx> wrote:
> Han-Wen Nienhuys schrieb:
>> On Mon, Jan 4, 2010 at 10:38 AM, Marc Hohl <marc@xxxxxxxxxx> wrote:
>>
>>> [...]
>>>
>>> As bends are musically and technically some sort of slurs, I think the
>>> best way to implement them is mainly to copy the slur engraver code and to
>>> adapt it properly. Internally, slurs cannot be created via
>>>
>>> slur = (make-music 'SlurEvent)
>>>
>>> so with bends, I have to add the commands to the parser. Is this correct?
>>>
>>
>> Initially, you can define the appropriate events in
>> define-music-types.scm, and use an identifier to access them; see
>>
>> ly/declarations-init.ly
>>
>> for examples on how to instantiate them.
>>
> Ok, thanks for the hint!
>> You should focus on building the backend formatting before worrying
>> about the syntax. It is ok to launch the feature with an experimental
>> syntax for one release or so, so don't worry about getting the syntax
>> right, as experimenting with syntax is the easy part.
>>
>> You are worrying about the engravers, but in reality engravers are
>> simple classes which just connect grobs together, and the real
>> difficulty is in writing the formatting code that manipulates the
>> grobs.
>>
> To be honest: I do not worry about the engravers alone, I am
> frighened by the whole task, but I need bends, so ...
>> Do not use the slur code for creating the bends. Slurs have many
>> graphic peculiarities, and you will spend needless energy in switching
>> off the slur behavior. The real question you need to resolve first is
>> item vs. spanner, i.e. if you have a bend like this:
>>
>> <<
>> { c4\bend d4\release }
>>
>> { f8 g8 a8 b8 }
>>>>
>>
>> will the bend traverse the 8th note to reach up to the following 4th
>> note (the D)? Or is its shape more or less fixed?
>>
> Sorry for not having an example attached. As I said, bends are
> just a special case for slurs, and I defined a scheme function which uses
> the control points for the bezier curve (let's call them z1, z2, z3 and z4),
> computes the point in the middle between z2 and z3 (z23) and draws a line
> from z1 to z23 and from z23 to z4. The slur routine takes care of all stems,
> accidentals and stuff, so it seemed natural to me to use this code as a
> base.
> Please look at the attached pdf, especially pointed slurs in the normal
> staves.
>
> (At first, I tried to implement bends only with scheme, but there are
> problems
> arising when a bend is followed by a "real" slur, so I decided to do it
> in a cleaner way.)
>
> By the way: what is the difference between a spanner and an item? I strongly
> feel bends *must* be spanners, but honestly, I don't know the reason.
A spanner has a start event and an end event, and covers the time in between
those events.
Nearly all of the bends that you have drawn must be spanners, I think.
I'm curious about measures 8 and 9 of the example you posted. In the first
beat of each note, you have a grace note bent up to a note. In measure 8,
the grace and the note have a different horizontal position in the tab; in
measure 9 they have the same horizontal position.
As I look at this notation more clearly, it seems that the amount of bend is
an attribute of a note. You might consider just specifying the string and
fret of a note, and then given a string tuning, string, and fret, the amount
of bend can be calculated.
Bend curves could then be drawn between successive notes at the same fret on
the same string, and the amount of bend can be calculated automatically.
With that kind of architecture, you'd just have the bend engraver catch
notes, and it would spit out a spanner whenever the string and fret were the
same and the note differed.
This is fairly similar to how the autobeam engraver works. It checks a
note, and provisionally starts a beam. If the beam shouldn't be created, it
junks it.
So what would happen in the beam engraver is that every note would be
caught, along with its fret and string. The note, fret, and string would be
stored in internal variables. Then, if the note is different, but the fret
and string are the same, a bend would be engraved. Otherwise, the previous
bend would be junked.
Once the disposition of the previous potential bend has been completed, a
new bend would be started, with the note, fret, and string of the current
note. This bend could either be finished or junked according to the next
note.
An alternative way to handle the bend is to just add an optional bend amount
to the note (the default of which would be zero). Then you'd have a similar
algorithm, but with slightly different details.
Get a note. If the string and fret are the same, but the bend is different,
finish and print the bend. Otherwise, junk the bend.
Then, start a new bend with the given string, fret, and bend.
>
> But to answer your question: there are situations where two strings are
> plucked
> together, the lower one being bent, while the other one sounds unchanged for
> the whole duration.
>>
>> [...]
>> As said, the engravers are just for setting up grobs, and engravers
>> receive information in time-order, ie. when receiving the event for
>> the first bend, the engraver does not know about the 2nd bend. Of
>> couse, you can alter the 1st bend on receiving the 2nd bend, but the
>> administration involved may be tricky, as it needs to work correctly
>> in polyphonic situations too, like the example I quoted above.
>>
> Hm. Another possibility would be to leave it to the user to draw.
> consecutive bends etc. by overriding some properties. Then,
> it would be cleaner to use different commands for bend and
> release bend.
With the architecture above, I don't think you need to specify bend and
release bend. All of the bends you show have a note at each end of the bend
(either a real note or a grace note).
You'd also need to have the note engraver somehow decide whether or not to
parenthesize the notehead. This could be done by saving the last fret,
string, and bend inside the tabnote engraver.
HTH,
Carl