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

 
 
Latest News
Advanced Gtk+ Sequencer v2.4.x final preparations posted by jkraehemann, Mon 21 Oct 2019 10:25:31 PM UTC - 0 replies
GSequencer WASAPI support as of v2.3.4 posted by jkraehemann, Sun 29 Sep 2019 10:35:09 PM UTC - 0 replies
Advanced Gtk+ Sequencer v2.3.2 released posted by jkraehemann, Tue 10 Sep 2019 07:32:44 AM UTC - 0 replies
Advanced Gtk+ Sequencer v2.3.x - implementing ags_filter_util.c posted by jkraehemann, Sun 18 Aug 2019 10:10:42 AM UTC - 0 replies

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

No messages in State of GSequencer in debian buster

 

Back to the top


Powered by Savane 3.5