Advanced Gtk+ Sequencer - News

Group

Main
- Main
- View members
- Search
Homepage
Download
Docs
Support
- ~~Submit new~~
- Browse
- Reset to open
- Digest
- Dependencies
- ~~Export~~
- Get statistics
- Search
Mailing lists
Source code
Bugs
- Submit new
- Browse
- Reset to open
- Digest
- Dependencies
- ~~Export~~
- Get statistics
- Search
Tasks
- ~~Submit new~~
- Browse
- Reset to open
- Digest
- Dependencies
- ~~Export~~
- Get statistics
- Search
News
- Browse
- Atom feed
- ~~Submit~~
- ~~Manage~~

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