- * Each event carries three time values - event->time_seconds, which is seconds since the start of the song,
- * event->time_pulses, which is PPQN clocks since the start of the song, and event->delta_pulses, which is PPQN clocks
- * since the previous event in that track. These values are invalid if the event is not attached to the track.
- * If event is attached, all three values are valid. Time of the event is specified when adding the event
- * (using smf_track_add_event_seconds(), smf_track_add_event_pulses() or smf_track_add_event_delta_pulses()); the remaining
- * two values are computed from that.
- *
- * Tempo related stuff happens automatically - when you add a metaevent that
- * is Tempo Change or Time Signature, libsmf adds that event to the tempo map. If you remove
- * Tempo Change event that is in the middle of the song, the rest of the events will have their
- * event->time_seconds recomputed from event->time_pulses before smf_event_remove_from_track() function returns.
- * Adding Tempo Change in the middle of the song works in a similar way.
- *
- * MIDI data (event->midi_buffer) is always kept in normalized form - it always begins with status byte
- * (no running status), there are no System Realtime events embedded in them etc. Events like SysExes
- * are in "on the wire" form, without embedded length that is used in SMF file format. Obviously
- * libsmf "normalizes" MIDI data during loading and "denormalizes" (adding length to SysExes, escaping
- * System Common and System Realtime messages etc) during writing.
+ * Each event carries three time values - event->time_seconds, which is seconds since
+ * the start of the song, event->time_pulses, which is PPQN clocks since the start of
+ * the song, and event->delta_pulses, which is PPQN clocks since the previous event
+ * in that track. These values are invalid if the event is not attached to the track.
+ * If event is attached, all three values are valid. Time of the event is specified when
+ * adding the event (using smf_track_add_event_seconds(), smf_track_add_event_pulses() or
+ * smf_track_add_event_delta_pulses()); the remaining two values are computed from that.
+ *
+ * Tempo related stuff happens automatically - when you add a metaevent that is Tempo PropertyChange or
+ * Time Signature, libsmf adds that event to the tempo map. If you remove Tempo PropertyChange event
+ * that is in the middle of the song, the rest of the events will have their event->time_seconds
+ * recomputed from event->time_pulses before smf_event_remove_from_track() function returns.
+ * Adding Tempo PropertyChange in the middle of the song works in a similar way.
+ *
+ * MIDI data (event->midi_buffer) is always kept in normalized form - it always begins with
+ * status byte (no running status), there are no System Realtime events embedded in them etc.
+ * Events like SysExes are in "on the wire" form, without embedded length that is used in SMF
+ * file format. Obviously libsmf "normalizes" MIDI data during loading and "denormalizes" (adding
+ * length to SysExes, escaping System Common and System Realtime messages etc) during writing.