In this section I'll introduce the keyword run which can be understood as a playing instance. But I rather talk about run because it's not guaranted that the recall outputs directly to a device.
The implemented effect as a subclass of AgsRecall resides as template on the appropriate AgsAudio or AgsChannel.
When recycling changes on input, new AgsRecallRecycling will be added. This class function may be of relevancy:
-
AgsChannel::recycling-changed()
As a new run occures the AgsRecallAudioRun and AgsRecallChannelRun will be duplicated, dependencies resolved, state initialized and enter the play loop hierarchy. These class functions will be called on the recall:
-
AgsChannel::duplicate-recall()
- This function will be called on the template object to instantiate the the object which will pass further processing.
Further processing:
-
AgsRecall::resolve-dependency()
-
The recall may want to depend on a other recall (eg. a counter) and may ignore following calls while rather do processing on an event of the dependency.
-
-
AgsRecall::run-init-pre(), AgsRecall::run-init-inter() & AgsRecall::run-init-post()
-
Will be called only once for the run refering to dedicated AgsRecallID.
-
-
AgsRecall::run-pre(), AgsRecall::run-inter() & AgsRecall::run-post()
-
Will be called for each cycle of a run refering to AgsRecallID.
-
There may be more than one AgsRecallID for a template i.e. there can exist more than one run at the very same time.
-
As soon as an add_audio_signal event will be emitted on an AgsRecycling, the AgsRecallAudioSignal subclass will be instantiated which performs audio stream manipulation. These class functions will be called on the recall:
-
AgsRecall::run-init-pre(), AgsRecall::run-init-inter() & AgsRecall::run-init-post()
-
AgsRecall::automate(), AgsRecall::feed-input-queue(), AgsRecall::run-pre(), AgsRecall::run-inter(), AgsRecall::run-post() & AgsRecall::feed-output-queue()
When you're done with processing call:
-
AgsRecall::done()