You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
150 lines
6.4 KiB
Plaintext
150 lines
6.4 KiB
Plaintext
TITLE:: FluidBufTransients
|
|
SUMMARY:: Buffer-Based Transient Extractor
|
|
CATEGORIES:: Libraries>FluidCorpusManipulation, UGens>Buffer
|
|
RELATED:: Guides/FluidCorpusManipulation, Guides/FluidBufMultiThreading
|
|
|
|
DESCRIPTION::
|
|
This class triggers a transient extractor on buffers on the non-real-time thread of the server. It implements declicking algorithm from chapter 5 of the classic Digital Audio Restoration by Godsill, Simon J., Rayner, Peter J.W. with some bespoke improvements on the detection function tracking. It is part of the LINK:: Guides/FluidCorpusManipulation##Fluid Corpus Manipulation Toolkit::. For more explanations, learning material, and discussions on its musicianly uses, visit http://www.flucoma.org/
|
|
|
|
The algorithm will take a buffer in, and will divide it in two outputs: LIST::
|
|
## the transients, estimated from the signal and extracted from it;
|
|
## the remainder of the material, as estimated by the algorithm.::
|
|
|
|
The whole process is based on the assumption that a transient is an element that is deviating from the surrounding material, as sort of click or anomaly. The algorithm then estimates what should have happened if the signal had followed its normal path, and resynthesises this estimate, removing the anomaly which is considered as the transient.
|
|
|
|
STRONG::Threading::
|
|
|
|
By default, this UGen spawns a new thread to avoid blocking the server command queue, so it is free to go about with its business. For a more detailed discussion of the available threading and monitoring options, including the two undocumented Class Methods below (.processBlocking and .kr) please read the guide LINK::Guides/FluidBufMultiThreading::.
|
|
|
|
CLASSMETHODS::
|
|
|
|
METHOD:: process, processBlocking
|
|
This is the method that calls for the transient extraction to be performed on a given source buffer.
|
|
|
|
ARGUMENT:: server
|
|
The server on which the buffers to be processed are allocated.
|
|
|
|
ARGUMENT:: source
|
|
The index of the buffer to use as the source material to be decomposed through the NMF process. The different channels of multichannel buffers will be processing sequentially.
|
|
|
|
ARGUMENT:: startFrame
|
|
Where in the srcBuf should the NMF process start, in sample.
|
|
|
|
ARGUMENT:: numFrames
|
|
How many frames should be processed.
|
|
|
|
ARGUMENT:: startChan
|
|
For multichannel srcBuf, which channel should be processed first.
|
|
|
|
ARGUMENT:: numChans
|
|
For multichannel srcBuf, how many channel should be processed.
|
|
|
|
ARGUMENT:: transients
|
|
The index of the buffer where the extracted transient component will be reconstructed.
|
|
|
|
ARGUMENT:: residual
|
|
The index of the buffer where the estimated continuous component will be reconstructed.
|
|
|
|
ARGUMENT:: order
|
|
The order in samples of the impulse response filter used to model the estimated continuous signal. It is how many previous samples are used by the algorithm to predict the next one as reference for the model. The higher the order, the more accurate is its spectral definition, not unlike fft, improving low frequency resolution, but it differs in that it is not conected to its temporal resolution.
|
|
|
|
ARGUMENT:: blockSize
|
|
The size in samples of frame on which it the algorithm is operating. High values are more cpu intensive, and also determines the maximum transient size, which will not be allowed to be more than half that lenght in size.
|
|
|
|
ARGUMENT:: padSize
|
|
The size of the handles on each sides of the block simply used for analysis purpose and avoid boundary issues.
|
|
|
|
ARGUMENT:: skew
|
|
The nervousness of the bespoke detection function with values from -10 to 10. It allows to decide how peaks are amplified or smoothed before the thresholding. High values increase the sensitivity to small variations.
|
|
|
|
ARGUMENT:: threshFwd
|
|
The threshold of the onset of the smoothed error function. It allows tight start of the identification of the anomaly as it proceeds forward.
|
|
|
|
ARGUMENT:: threshBack
|
|
The threshold of the offset of the smoothed error function. As it proceeds backwards in time, it allows tight ending of the identification of the anomaly.
|
|
|
|
ARGUMENT:: windowSize
|
|
The averaging window of the error detection function. It needs smoothing as it is very jittery. The longer the window, the less precise, but the less false positive.
|
|
|
|
ARGUMENT:: clumpLength
|
|
The window size in sample within which positive detections will be clumped together to avoid overdetecting in time.
|
|
|
|
ARGUMENT:: freeWhenDone
|
|
Free the server instance when processing complete. Default true
|
|
|
|
ARGUMENT:: action
|
|
A Function to be evaluated once the offline process has finished and all Buffer's instance variables have been updated on the client side. The function will be passed [transients, residual] as an argument.
|
|
|
|
returns:: an instance of the processor
|
|
|
|
|
|
EXAMPLES::
|
|
|
|
code::
|
|
(
|
|
b = Buffer.read(s,File.realpath(FluidBufTransients.class.filenameSymbol).dirname.withTrailingSlash ++ "../AudioFiles/Tremblay-AaS-SynthTwoVoices-M.wav");
|
|
c = Buffer.new(s);
|
|
d = Buffer.new(s);
|
|
)
|
|
|
|
// with basic params
|
|
(
|
|
Routine{
|
|
t = Main.elapsedTime;
|
|
FluidBufTransients.process(s,b, transients:c, residual:d).wait;
|
|
(Main.elapsedTime - t).postln;
|
|
}.play
|
|
);
|
|
|
|
// wait for the duration to appear in the post window as a cue that the computation is finished
|
|
c.play;
|
|
d.play;
|
|
|
|
//nullsumming tests
|
|
{(PlayBuf.ar(1,c))+(PlayBuf.ar(1,d))+(-1*PlayBuf.ar(1,b,doneAction:2))}.play
|
|
|
|
|
|
// with everything changed to make it much better, at the cost of computation time (only 5 seconds are processed here)
|
|
(
|
|
Routine{
|
|
t = Main.elapsedTime;
|
|
FluidBufTransients.process(s,b, 0, 220500, 0, 1, c, d, 200, 2048, 1024, 1, 3, 1, 15, 30).wait;
|
|
(Main.elapsedTime - t).postln;
|
|
}.play
|
|
)
|
|
|
|
// wait for the duration to appear in the post window as a cue that the computation is finished
|
|
c.play;
|
|
d.play;
|
|
::
|
|
|
|
STRONG::A stereo buffer example.::
|
|
CODE::
|
|
|
|
// load two very different files
|
|
(
|
|
b = Buffer.read(s,File.realpath(FluidBufTransients.class.filenameSymbol).dirname.withTrailingSlash ++ "../AudioFiles/Tremblay-AaS-SynthTwoVoices-M.wav");
|
|
c = Buffer.read(s,File.realpath(FluidBufTransients.class.filenameSymbol).dirname.withTrailingSlash ++ "../AudioFiles/Tremblay-AaS-AcousticStrums-M.wav");
|
|
)
|
|
|
|
// composite one on left one on right as test signals
|
|
FluidBufCompose.process(s, c, numFrames:b.numFrames, startFrame:555000, destStartChan:1, destination:b)
|
|
b.play
|
|
|
|
// create 2 new buffers as destinations
|
|
d = Buffer.new(s); e = Buffer.new(s);
|
|
|
|
//run the process on them
|
|
(
|
|
Routine{
|
|
t = Main.elapsedTime;
|
|
FluidBufTransients.process(s, b, transients: d, residual:e, threshFwd:1.2, clumpLength:40).wait;
|
|
(Main.elapsedTime - t).postln;
|
|
}.play
|
|
)
|
|
|
|
//listen: stereo preserved!
|
|
d.play
|
|
e.play
|
|
::
|