newsAdvanced Gtk+ Sequencer - News: State of GSequencer in debian buster

 
 
Latest News
Advanced Gtk+ Sequencer version 6.5.x posted by jkraehemann, Sun 11 Feb 2024 05:06:15 PM UTC
Advanced Gtk+ Sequencer version 6.3.5 posted by jkraehemann, Fri 19 Jan 2024 11:53:24 AM UTC
Advanced Gtk+ Sequencer v6.1.0 released posted by jkraehemann, Thu 28 Sep 2023 04:55:19 AM UTC
Advanced Gtk+ Sequencer v6.0.0 released posted by jkraehemann, Mon 21 Aug 2023 11:48:52 AM UTC
Advanced Gtk+ Sequencer v5.5.0 released posted by jkraehemann, Sat 05 Aug 2023 10:21:52 AM UTC

State of GSequencer in debian buster

Item posted by Joël Krähemann <jkraehemann> on Sun 03 Mar 2019 07:08:32 PM UTC.

In debian buster is currently v2.1.53 published.

On 26-Feb-2019 21:39 v2.1.64 is available and was immediately pushed to debian repository.

https://salsa.debian.org/multimedia-team/gsequencer

New functions available


These are the new functions introduced in v2.1.61

  • ags_channel_next()
  • ags_channel_prev()
  • ags_channel_next_pad()
  • ags_channel_prev_pad()
  • ags_recycling_next()
  • ags_recycling_prev()


The OSC server provided in Advanced Gtk+ Sequencer does unsafe iteration of AgsChannel:next. This was fixed in v2.1.61 and replaced iteration by ags_channel_next(). It was not race aware but it is fixed and provided in debian repository, now.

Version v2.1.61 is available since: 24-Feb-2019 20:42

GSequencer is conflict free


Due to design of Advanced Gtk+ Sequencer it is aware from data-races. This is because AgsTaskThread runs exclusive. The OSC server on the opposite runs decoupled from the multi-thread environment powering the audio engine. See above for its implications.

The API and reference counters


GSequencer has neither in v2.1.53 nor in v2.1.64 problems dealing with them. Because of its multi-threaded design. Anyhow, in v2.1.53 the situation using the API is actually bad. There was no unified behavior of reference counters of functions, except the property getter/setter do it correct. This was fixed in v2.1.63.

Update vs. cherry-pick


I have to work through the diff and cherry-pick the bug-fixes done so far.

But why should I do this.

I would love to attract developers to use the Advanced Gtk+ Sequencer API. But I won't encourage to use v2.1.53.

Use AppImage instead


Recently, I started to provide GSequencer as AppImage available from:

https://www.opendesktop.org/p/1290114/

The common sense


You can expect from someone that very same as you expecting from me

Additional work


I am willing to work through the diff. It is up to the debian developer to decide what changes will be accepted.

I provide you 2 different type of patches:

  • bug-fixes
  • sustainable code


Responsibility chain


I think of deserving the occasion to sell my changes.

Failure of debian mentors


I contacted my sponsor to ask for progress, without any reply.

I was asking for attention about missing latest changes in debian before the dead-line expired.

The policy


As told before I provide the patches needed.



by Joël

 

Back to the top

Powered by Savane 3.13-f8d8.
Corresponding source code