newsAdvanced Gtk+ Sequencer - News: Delay and attack correction in GSequencer

Latest News
Delay and attack correction in GSequencer posted by jkraehemann, Mon 07 Dec 2020 03:54:04 PM UTC - 0 replies
GSequencer v3.6.x release goals posted by jkraehemann, Fri 31 Jul 2020 10:17:04 AM UTC - 0 replies
GSequencer v3.4.x release goals posted by jkraehemann, Thu 11 Jun 2020 06:58:14 PM UTC - 0 replies
GSequencer v3.3.x replaced all recalls by ags-fx engine posted by jkraehemann, Wed 20 May 2020 07:25:15 AM UTC - 0 replies

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

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

No messages in Delay and attack correction in GSequencer


Back to the top

Powered by Savane 3.5