Advanced Gtk+ Sequencer - News
Delay and attack correction in GSequencer
Item posted by Joël Krähemann <jkraehemann> on Mon 07 Dec 2020 03:54:04 PM UTC.
This delay and attack is related to timing playing notes. A delay specifies how many times buffer_size occur until next note is played. And attack means in this context at what frame position to insert the note.
Need for correction
AgsSoundcard implementations have got an array of delay and attack sized 2 times AGS_SOUNDCARD_DEFAULT_PERIOD. But currently only fist period is used.
Assumed you have got a project with following tempo and presets:
BPM = 136
segment = 1 / 16 * 4
samplerate = 44100
buffer_size = 1024
This gives you an absolute delay of:
absolute_delay = 60.0 * ((samplerate / buffer_size) / bpm) * segment = 4.749971278
This results in a variable attack depending on offset played. This is not how things work in GSequencer.
The corrected delay
The delay is corrected in such a way that attack is periodically. This means after AGS_SOUNDCARD_DEFAULT_PERIOD times delay we obtain:
attack = 0
The magic behind attack is calculated in ags_soundcard_util.c
http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/audio/ags_soundcard_util.c
So we calculate the remaining frames after AGS_SOUNDCARD_DEFAULT_PERIOD and use total_correct_frame_count to adjust absolute_delay.
default_tact_frames = absolute_delay * buffer_size;
total_correct_frame_count = ((guint) AGS_SOUNDCARD_DEFAULT_PERIOD * default_tact_frames) % buffer_size;
correct_frame_count = (gdouble) total_correct_frame_count / AGS_SOUNDCARD_DEFAULT_PERIOD;
corrected_delay = absolute_delay + (correct_frame_count / buffer_size);
So our delay changes from 4.749971278 to 4.750918277. The difference is 0.000946999, resulting in a inaccuracy of approximately 1 thousandth of a segment duration.
Here we have got 8 playing keys within a second. This segment duration of 0.125 seconds divided by 1000 gives you the inaccuracy in time.
by Joël
Powered by Savane 3.14-8aba.
Corresponding source code