fix handling of grace notes to shorten preceding tied notes correctly

fix handling of grace notes to shorten preceding tied notes correctly

In Note_performer::process_music(), when a grace note was encountered,
the immediately preceding Audio_note (or Audio_notes if the grace note
followed a chord) was/were shortened, but it failed to check whether the
Audio_note is part of a tie.  Ensure that any note being shortened in
this way is the head of a tie, if it is part of a tie.

https://code.google.com/p/lilypond/issues/detail?id=3091

The following refactorings were also done in separate commits:

- extract new Audio_note::tie_head() method

  This makes it easy to retrieve the first note in a tie,
  and will be used in the fix for issue #3091.

- use Audio_note::get_column() rather than directly accessing the member field

  This adheres to the principle of encapsulation.

Finally, I implemented Audio_note::to_string() which came in handy
whilst I was debugging, and I thought it would be worth keeping this
for future debugging even though it's not used by the new code.

[Keith, 2013-01-15 04:30:52]

Congratulations on finding the cause of the problem, through the maze of objects
implementing MIDI output.

https://codereview.appspot.com/7108043/diff/1/input/regression/midi-grace-aft...
File input/regression/midi-grace-after-tie.ly (right):

https://codereview.appspot.com/7108043/diff/1/input/regression/midi-grace-aft...
input/regression/midi-grace-after-tie.ly:3: texidoc = "Grace notes don't break
ties which immediately precede them."
Tied notes sound as one note in MIDI.  Grace notes following a tied note shorten
the resulting single note in MIDI.

https://codereview.appspot.com/7108043/diff/1/lily/include/audio-item.hh
File lily/include/audio-item.hh (right):

https://codereview.appspot.com/7108043/diff/1/lily/include/audio-item.hh#newc...
lily/include/audio-item.hh:90: virtual string to_string () const;
It seems fine to have the debug-output helper to_string(), but why make it a
virtual member function?  Unless the compiler is a lot smarter than me, that
would seem to require a pointer to the actual function be stored in every
Audio_note object.  Then every user would need extra memory for every note, but
would get no benefit.

[benko.pal, 2013-01-15 09:00:54]

2013/1/15  <k-ohara5a5a@oco.net>:
>
https://codereview.appspot.com/7108043/diff/1/lily/include/audio-item.hh#newc...
> lily/include/audio-item.hh:90: virtual string to_string () const;
> It seems fine to have the debug-output helper to_string(), but why make
> it a virtual member function?  Unless the compiler is a lot smarter than
> me, that would seem to require a pointer to the actual function be
> stored in every Audio_note object.  Then every user would need extra
> memory for every note, but would get no benefit.

no, pointer to the actual function is stored in a per-type (not
per-object) table,
the object stores a single pointer to the per-type function table,
and that pointer is needed anyway for a type with virtual members.
(btw I thought without checking that to_string is inherited from a
(very low level) base and now I can't easily check whether it's
really so - is it?)

p

[Keith, 2013-01-16 05:35:28]

Okay.  The class 'Audio_note' is a sub-class of 'Audio_item', which has
virtual functions itself, so the cost of a v-table pointer is already paid.

In any case, one extra word per note is not *too* bad.

[adam.spiers, 2013-01-26 21:13:08]

Revised patch set using Keith's suggested text for the texidoc string.