newsAdvanced Gtk+ Sequencer - News: GSequencer development insights

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]

GSequencer development insights

Item posted by Joël Krähemann <jkraehemann> on Sun 04 Mar 2018 02:15:03 PM UTC.

GSequencer v2.0.0 is going to be different. Some notable changes are going to be introduced.

Most regarded change is the replacement of :soundcard property by :output-soundcard and :input-soundcard. These objects are going to see the change:

  • AgsAudio
  • AgsChannel
  • AgsRecycling
  • AgsAudioSignal
  • AgsRecall

This change is considered to be important because I want to add ags-capture recall. It shall allow you to record audio data. Thought the AgsWave object was prior introduced. I didn't feel like providing a hacky solution to deal with output/input related objects implementing AgsSoundcard.

AgsPlayable interface is going to be replaced by AgsSoundContainer and AgsSoundResource. There was always some bad taste about this blown interface. However feel free to implement both interfaces.

AgsDistributedManager is going to be renamed to AgsSoundServer. Thought I wanted this name to be reserved for future own implementation. But the original name was just confusing.

I want to replace all occur of GParameter by a pair of gchar** string vector and a GValue* array. This is required for introspection.

AgsConnection and AgsConnectionManager will be removed.

Further damping/vibration fields are just added to AgsAudioSignal. This is going to be tricky to implement. Since you might have intersections that the rt-safe mode can't handle correctly.

There is going to be a new configuration mechanism by following functions:

This shall allow you to disable audio processing events by plain function pointers like:

  • AgsAudio::play-recall
  • AgsRecall::run_init_pre
  • AgsRecall::run_init_inter
  • AgsRecall::run_init_post
  • AgsRecall::feed_input_queue
  • AgsRecall::automate
  • AgsRecall::run_pre
  • AgsRecall::run_inter
  • AgsRecall::run_post
  • AgsRecall::do_feedback
  • AgsRecall::feed_output_queue

As might have noticed AgsRecall provides now a stronger semantics how your audio data is going to be processed. However I have to evaluate the introduced over-head and then decide if its worthy.

AgsAudio and AgsChannel are going to introduce common events to do audio processing.

  • AgsAudio::duplicate_recall
  • AgsAudio::resolve_recall
  • AgsAudio::init_recall
  • AgsAudio::play_recall
  • AgsAudio::cancel_recall
  • AgsAudio::done_recall
  • AgsChannel::duplicate_recall
  • AgsChannel::resolve_recall
  • AgsChannel::init_recall
  • AgsChannel::play_recall
  • AgsChannel::cancel_recall
  • AgsChannel::done_recall

by Joël


No messages in GSequencer development insights


Back to the top

Powered by Savane 3.1-cleanup1