newsAdvanced Gtk+ Sequencer - News: GSequencer development insights

Latest News
GSequencer v2.1.53 for debian buster posted by jkraehemann, Fri 08 Mar 2019 11:01:12 PM UTC - 0 replies
Get emotional as debian buster is going to be released posted by jkraehemann, Thu 07 Mar 2019 12:46:59 AM UTC - 0 replies
State of GSequencer in debian buster posted by jkraehemann, Sun 03 Mar 2019 07:08:32 PM UTC - 0 replies
handling LV2 iriref posted by jkraehemann, Wed 13 Feb 2019 10:20:49 AM UTC - 0 replies
fixed ref-count posted by jkraehemann, Sat 09 Feb 2019 02:46:41 PM UTC - 0 replies
[Submit News]
[79 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.4