newsAdvanced Gtk+ Sequencer - News: Inaccurate attack calculation of bpm

Latest News
The new dispatcher: ags_channel_recursive_run_stage() posted by jkraehemann, Sun 18 Mar 2018 05:37:45 PM UTC - 0 replies
GSequencer development insights posted by jkraehemann, Sun 04 Mar 2018 02:15:03 PM UTC - 0 replies
GSequencer v2.0.0 - forecast posted by jkraehemann, Tue 06 Feb 2018 03:04:57 PM UTC - 0 replies
Conservative multi-threaded setup posted by jkraehemann, Wed 17 Jan 2018 04:22:14 AM UTC - 0 replies
Goals of GSequencer 1.4.x posted by jkraehemann, Fri 05 Jan 2018 01:43:07 AM UTC - 0 replies
[Submit News]
[55 news in archive]

Inaccurate attack calculation of bpm

Item posted by Joël Krähemann <jkraehemann> on Sat 19 Aug 2017 11:56:06 PM UTC.

As having bigger buffers especially by using pulseaudio, the algorithm that calculates attacks of target buffer seems to fail.

The attack is calculated by one of these functions:

  • ags_devout_adjust_delay_and_attack()
  • ags_jack_devout_adjust_delay_and_attack()
  • ags_pulse_devout_adjust_delay_and_attack()

The goal of the algorithm would be having constant delay but alternating attacks. This formula was considering only buffer lengths of 512 or lower.

Rework the algorithm

The computation shall return an approximation attack with a certain tolerance of deviation. I would say it doesn't matter if there is a swing of 10 to 20 frames each delay.

It should figure out best fit of delay and approximated attack. The problem with bigger buffer lengths is the algorithm can't smaller delays accurately. This was done for simplicity but doesn't meet current requirements, yet.

By Joël


No messages in Inaccurate attack calculation of bpm


Back to the top

Powered by Savane 3.1-cleanup1