The OSC server has definitely a need for the changes introduced in
version 2.1.61. Since it runs decoupled from the audio threads, it is
not conflict free. In order to run race aware it needs safe iteration
As you might change channel alignment from UI and modify or monitor
the affected audio object, it may SIGSEGV in version 2.1.53.
Here is another change, it fixes a memory leak that happens as running
the different stages of playback - version 2.1.61:
* fixed memory-leak in ags_channel_recursive_setup_run_stage_down()
In version 2.1.54 a wrong property specification was fixed:
As you might have noticed most of the changes are related to reference
counter. I decided to introduce 6 new functions as fixing the above
described problem with the OSC server.
* implemented ags_channel_next() and ags_channel_prev()
* implemented ags_channel_next_pad() and ags_channel_prev_pad()
* implemented ags_recycling_next() and ags_recycling_prev()
Then I started to replace iterating AgsChannel instead by property
AgsChannel::next with the above functions.
I prefer the iteration functions over g_object_get() because they have
always well defined behavior. On the opposite, when you pass NULL to
g_object_get() it won't write to any return location specified by