updated helpfiles 'completed' for all Buffer processes - in creative English and with a few dodgy explanations - and sill no example inserted from the test files.
This Class performs basic compositing on buffers on the non-real-time thread. It avoids having to come back to the language side. It is part of the Fluid Decomposition Toolkit of the FluCoMa project. footnote::
This was made possible thanks to the FluCoMa project (http://www.flucoma.org/) funded by the European Research Council (https://erc.europa.eu/) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 725899).::
This class performs basic compositing on buffers on the non-real-time thread. It avoids having to come back to the language side. It is part of the Fluid Decomposition Toolkit of the FluCoMa project. footnote::
This was made possible thanks to the FluCoMa project (http://www.flucoma.org/) funded by the European Research Council (https://erc.europa.eu/) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 725899).::
The algorythm will take two buffer in, and will put the composited information at the provided dstBuf.
@ -69,9 +70,10 @@ ARGUMENT:: dstStartChanB
ARGUMENT:: dstBufNum
The bufNum of the destination buffer.
returns::
RETURNS::
Nothing, as the various destination buffers are declared in the function call.
It is part of the Fluid Decomposition Toolkit of the FluCoMa project. footnote::
This was made possible thanks to the FluCoMa project (http://www.flucoma.org/) funded by the European Research Council (https://erc.europa.eu/) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 725899).::
This class triggers a Harmonic-Percussive Source Separation process (HPSS for short) on buffers on the non-real-time thread of the server. It implements a few academic papers (TODO:refs) with some bespoke improvements. It is part of the Fluid Decomposition Toolkit of the FluCoMa project. footnote::
This was made possible thanks to the FluCoMa project ( http://www.flucoma.org/ ) funded by the European Research Council ( https://erc.europa.eu/ ) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 725899).::
The algorithm will take a buffer in, and will divide it in two or three outputs, depending on the mode: LIST::
## an harmonic component;
## a percussive component;
## a residual of the previous two if the flag is set to inter-dependant thresholds. See the modeFlag below.::
The whole process is based on the assumption that, in a spectrogram, a percussive element will be a vertical line (white-ish spectrum) and an harmonic component will be a horizontal line (same spectral bin sustained over time). The way to remove the noisiness inherent to the analysis is a median filter acting on binary masks, which are then applied to the spectrogram of the full file. More information on median filtering, and on HPSS for musicianly usage, are availabe in LINK::Guides/FluCoMa:: overview file.
CLASSMETHODS::
METHOD:: process
(describe method here)
This is the method that calls for the HPSS to be calculated on a given source buffer.
ARGUMENT:: server
(describe argument here)
The server on which the buffers to be processed are allocated.
ARGUMENT:: srcBufNum
(describe argument here)
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:: startAt
(describe argument here)
Where in the srcBuf should the NMF process start, in sample.
ARGUMENT:: nFrames
(describe argument here)
How many frames should be processed.
ARGUMENT:: startChan
(describe argument here)
For multichannel srcBuf, which channel should be processed first.
ARGUMENT:: nChans
(describe argument here)
For multichannel srcBuf, how many channel should be processed.
ARGUMENT:: harmBufNum
(describe argument here)
The index of the buffer where the extracted harmonic component will be reconstructed.
ARGUMENT:: percBufNum
(describe argument here)
The index of the buffer where the extracted percussive component will be reconstructed.
ARGUMENT:: resBufNum
The index of the buffer where the residual component will be reconstructed in mode 2.
ARGUMENT:: pSize
(describe argument here)
The size in spectral bins of the median filter for the percussive component.
ARGUMENT:: hSize
(describe argument here)
The size in consecutive spectral frames of the median filter for the harmonic component.
ARGUMENT:: modeFlag
The way the masking is happening on the spectrogram.
table::
## 0 || Original paper - the loudest winds.
## 1 || Relative mode - the thresholds set next on the harmonic counterpart will decide of a binary masking, and the percussive mask is its complement.
## 2 || Inter-dependant mode - the thresholds are independant on the harmonic and percussive component, but are then normalised to make a null sum and their difference is sent to the residual buffer.
::
ARGUMENT:: thresholdExplanations
soon here
ARGUMENT:: winSize
(describe argument here)
The window size. As HPSS relies on spectral frames, we need to decide what precision we give it spectrally and temporally, in line with Gabor Uncertainty principles. http://www.subsurfwiki.org/wiki/Gabor_uncertainty
ARGUMENT:: hopSize
(describe argument here)
The window hope size. As HPSS relies on spectral frames, we need to move the window forward. It can be any size but low overlap will create audible artefacts.
ARGUMENT:: fftSize
(describe argument here)
The inner FFT/IFFT size. It should be at least 4 samples long, at least the size of the window, and a power of 2. Making it larger allows an oversampling of the spectral precision.
returns::
RETURNS::
Nothing, as the various destination buffers are declared in the function call.
This Class performs Non-Negative Matrix Factorisation (NMF for short) on buffers on the non-real-time thread. It is a good way to get different components out of a buffered signal. It is part of the Fluid Decomposition Toolkit of the FluCoMa project. footnote::
This was made possible thanks to the FluCoMa project (http://www.flucoma.org/) funded by the European Research Council (https://erc.europa.eu/) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 725899).::
This class triggers a Non-Negative Matrix Factorisation process (NMF for short) on buffers on the non-real-time thread of the server. It is a good way to get different components out of a buffered signal. It is part of the Fluid Decomposition Toolkit of the FluCoMa project. footnote::
This was made possible thanks to the FluCoMa project (http://www.flucoma.org/) funded by the European Research Council (https://erc.europa.eu/) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 725899).::
The algo will take a buffer in, and will divide it in a number of ranks. It can provide back either or all of the following: LIST::
The algorithm will take a buffer in, and will divide it in a number of ranks. It can provide back either or all of the following: LIST::
## a spectral contour of each rank in the form of a magnitude spectrogramme (called a dictionary in NMF lingo);
## an amplitude envoloppe of each rank in the form of gains for each consecutive frames of the unterlying FFT (called an activation in NMF lingo)
## an amplitude envoloppe of each rank in the form of gains for each consecutive frames of the unterlying FFT (called an activation in NMF lingo);
## a reconstruction of each rank in audio domain. ::
The whole process can be related to a vocoder, where each filter is instead a spectrograme of magnitudes (no phase information). More information for musicianly uses of NMF are availabe on this website, and in LINK::Guides/FluCoMa:: overview file.
The whole process can be related to a vocoder, where each filter is instead a spectrograme of magnitudes (no phase information). More information for musicianly uses of NMF are availabe in LINK::Guides/FluCoMa:: overview file.
CLASSMETHODS::
@ -86,9 +88,10 @@ ARGUMENT:: windowType
ARGUMENT:: randomSeed
The NMF process needs to seed its starting point. If specified, the same values will be used. The default of -1 will randomly assign them. (not implemented yet)
returns::
RETURNS::
Nothing, as the various destination buffers are declared in the function call.
A non-real-time transient-based slice extractor implementing footnote::This was made possible thanks to the FluCoMa project (http://www.flucoma.org/) funded by the European Research Council (https://erc.europa.eu/) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 725899).::
This class implements a non-real-time slicer implementing an algorithm assessing novelty in the signal to estimate the slicing points. It implements the seminal results published in 'Automatic Audio Segmentation Using a Measure of Audio Novelty' by J Foote. It is part of the Fluid Decomposition Toolkit of the FluCoMa project. footnote::This was made possible thanks to the FluCoMa project ( http://www.flucoma.org/ ) funded by the European Research Council ( https://erc.europa.eu/ ) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 725899).::
The process will return a buffer which contains indices (in sample) of estimated starting points of different slices.
CLASSMETHODS::
METHOD:: process
(describe method here)
This is the method that calls for the slicing to be calculated on a given source buffer.
ARGUMENT:: server
(describe argument here)
The server on which the buffers to be processed are allocated.
ARGUMENT:: srcBufNum
(describe argument here)
The index of the buffer to use as the source material to be sliced through novelty identification. The different channels of multichannel buffers will be summed.
ARGUMENT:: startAt
(describe argument here)
Where in the srcBuf should the slicing process start, in sample.
ARGUMENT:: nFrames
(describe argument here)
How many frames should be processed.
ARGUMENT:: startChan
(describe argument here)
For multichannel srcBuf, which channel should be processed.
ARGUMENT:: nChans
(describe argument here)
For multichannel srcBuf, how many channel should be summed.
ARGUMENT:: transBufNum
(describe argument here)
The index of the buffer where the indices (in sample) of the estimated starting points of slices will be written. The first and last points are always the boundary points of the analysis.
ARGUMENT:: kernelSize
(describe argument here)
The granularity of the window in which the algorithm looks for change, in samples. A small number will be sensitive to short term changes, and a large number should look for long term changes.
ARGUMENT:: threshold
(describe argument here)
The threshold in the novelty curve, the latter being derived from running the kernel across the diagonal of the similarity matrix, and looking for peak of changes (NOT CLEAR)
ARGUMENT:: winSize
(describe argument here)
The window size. As novelty estimation relies on spectral frames, we need to decide what precision we give it spectrally and temporally, in line with Gabor Uncertainty principles. http://www.subsurfwiki.org/wiki/Gabor_uncertainty
ARGUMENT:: hopSize
(describe argument here)
The window hope size. As novelty estimation relies on spectral frames, we need to move the window forward. It can be any size but low overlap will create audible artefacts.
ARGUMENT:: fftSize
(describe argument here)
The inner FFT/IFFT size. It should be at least 4 samples long, at least the size of the window, and a power of 2. Making it larger allows an oversampling of the spectral precision.
returns::
RETURNS::
Nothing, as the various destination buffers are declared in the function call.
It is part of the Fluid Decomposition Toolkit of the FluCoMa project. footnote::
This was made possible thanks to the FluCoMa project (http://www.flucoma.org/) funded by the European Research Council (https://erc.europa.eu/) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 725899).::
This class triggers a Sinusoidal Modelling process on buffers on the non-real-time thread of the server. It implements a mix and match algorithms taken from classic papers. It is part of the Fluid Decomposition Toolkit of the FluCoMa project. footnote:: This was made possible thanks to the FluCoMa project ( http://www.flucoma.org/ ) funded by the European Research Council ( https://erc.europa.eu/ ) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 725899).::
The algorithm will take a buffer in, and will divide it in two parts: LIST::
## a reconstruction of what its detects as sinusoidal;
## a residual derived from the previous buffert to allow null-summing::
The whole process is based on the assumption that signal is made of pitched steady components that have a long-enough duration and are periodic enough to be perceived as such, that can be tracked, resynthesised and removed from the original, leaving behind what is considered as non-pitched, noisy, and/or transient. It first tracks the peaks, then checks if they are the continuation of a peak in previous spectral frames, by assigning them a track. More information on this model, and on how it links to musicianly thinking, are availabe in LINK::Guides/FluCoMa:: overview file.
CLASSMETHODS::
METHOD:: process
(describe method here)
This is the method that calls for the sinusoidal estimation to be calculated on a given source buffer and to be resynthesised.
ARGUMENT:: server
(describe argument here)
The server on which the buffers to be processed are allocated.
ARGUMENT:: srcBufNum
(describe argument here)
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:: startAt
(describe argument here)
Where in the srcBuf should the NMF process start, in sample.
ARGUMENT:: nFrames
(describe argument here)
How many frames should be processed.
ARGUMENT:: startChan
(describe argument here)
For multichannel srcBuf, which channel should be processed first.
ARGUMENT:: nChans
(describe argument here)
For multichannel srcBuf, how many channel should be processed.
ARGUMENT:: sineBufNum
(describe argument here)
The index of the buffer where the extracted sinusoidal component will be reconstructed.
ARGUMENT:: resBufNum
(describe argument here)
The index of the buffer where the residual of the sinusoidal component will be reconstructed.
ARGUMENT:: bandwidth
(describe argument here)
The width in bins (OR IN PERCENT IN NEW INTERFACE) of the fragment of the fft window that is considered a normal deviation for a potential continuous sinusoidal track. It has an effect on CPU cost: the widest is more accurate but more computationally expensive.
ARGUMENT:: threshold
(describe argument here)
The normalised threshold, between 0 an 1, to consider a peak as a sinusoidal component from the normalized cross-correlation.
ARGUMENT:: minTrackLen
(describe argument here)
The minimum duration, in spectral frames, for a sinusoidal track to be accepted as a real pitch component. It allows to remove space-monkeys, but is more CPU intensive and might reject quick pitch material.
ARGUMENT:: magWeight
(describe argument here)
The weight of the magnitude proximity of a peak when trying to associate it to an existing track (relative to freqWeight - suggested between 0 to 1)
ARGUMENT:: freqWeight
(describe argument here)
The weight of the frequency proximity of a peak when trying to associate it to an existing track (relative to magWeight - suggested between 0 to 1)
ARGUMENT:: winSize
(describe argument here)
The window size. As sinusoidal estimation relies on spectral frames, we need to decide what precision we give it spectrally and temporally, in line with Gabor Uncertainty principles. http://www.subsurfwiki.org/wiki/Gabor_uncertainty
ARGUMENT:: hopSize
(describe argument here)
The window hope size. As sinusoidal estimation relies on spectral frames, we need to move the window forward. It can be any size but low overlap will create audible artefacts.
ARGUMENT:: fftSize
(describe argument here)
The inner FFT/IFFT size. It should be at least 4 samples long, at least the size of the window, and a power of 2. Making it larger allows an oversampling of the spectral precision.
returns::
RETURNS::
Nothing, as the various destination buffers are declared in the function call.
A non-real-time transient-based slice extractor implementing footnote::This was made possible thanks to the FluCoMa project (http://www.flucoma.org/) funded by the European Research Council (https://erc.europa.eu/) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 725899).::
This class implements a non-real-time transient-based slice extractor relying on the same algorithm than Classes/FluidBufTransients using clicks/transients/derivation/anomaly in the signal to estimate the slicing points. It is part of the Fluid Decomposition Toolkit of the FluCoMa project.footnote::This was made possible thanks to the FluCoMa project ( http://www.flucoma.org/ ) funded by the European Research Council ( https://erc.europa.eu/ ) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 725899).::
The process will return a buffer which contains indices (in sample) of estimated starting points of the different slices.
CLASSMETHODS::
METHOD:: process
(describe method here)
This is the method that calls for the slicing to be calculated on a given source buffer.
ARGUMENT:: server
(describe argument here)
The server on which the buffers to be processed are allocated.
ARGUMENT:: srcBufNum
(describe argument here)
The index of the buffer to use as the source material to be sliced through transient identification. The different channels of multichannel buffers will be summed.
ARGUMENT:: startAt
(describe argument here)
Where in the srcBuf should the slicing process start, in sample.
ARGUMENT:: nFrames
(describe argument here)
How many frames should be processed.
ARGUMENT:: startChan
(describe argument here)
For multichannel srcBuf, which channel should be processed.
ARGUMENT:: nChans
(describe argument here)
For multichannel srcBuf, how many channel should be summed.
ARGUMENT:: transBufNum
(describe argument here)
The index of the buffer where the indices (in sample) of the estimated starting points of slices will be written. The first and last points are always the boundary points of the analysis.
ARGUMENT:: order
(describe argument here)
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 algorythm 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
(describe argument here)
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:: padding
(describe argument here)
The size of the handles on each sides of the block simply used for analysis purpose and avoid boundary issues.
ARGUMENT:: skew
(describe argument here)
The hysteresis on the bespoke detection function. Values from -10 to 10 will allow to prioritise change in the low or high register.
ARGUMENT:: threshFwd
(describe argument here)
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
(describe argument here)
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
(describe argument here)
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:: debounce
(describe argument here)
The window size in sample within with positive detections will be clumped together to avoid overdetecting in time. No slice will be shorter than this duration.
RETURNS::
Nothing, as the destination buffer is declared in the function call.
returns::
Nothing, as the various destination buffers are declared in the function call.
A non-real-time transient extractor implementing footnote::This was made possible thanks to the FluCoMa project (http://www.flucoma.org/) funded by the European Research Council (https://erc.europa.eu/) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 725899).::
This class triggers non-real-time 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 Fluid Decomposition Toolkit of the FluCoMa project. footnote::
This was made possible thanks to the FluCoMa project ( http://www.flucoma.org/ ) funded by the European Research Council ( https://erc.europa.eu/ ) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 725899).::
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 algorythm 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. More information on signal estimation, and on its musicianly usage, are availabe in LINK::Guides/FluCoMa:: overview file.
CLASSMETHODS::
METHOD:: process
(describe method here)
This is the method that calls for the transient extraction to be performed on a given source buffer.
ARGUMENT:: server
(describe argument here)
The server on which the buffers to be processed are allocated.
ARGUMENT:: srcBufNum
(describe argument here)
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:: startAt
(describe argument here)
Where in the srcBuf should the NMF process start, in sample.
ARGUMENT:: nFrames
(describe argument here)
How many frames should be processed.
ARGUMENT:: startChan
(describe argument here)
For multichannel srcBuf, which channel should be processed first.
ARGUMENT:: nChans
(describe argument here)
For multichannel srcBuf, how many channel should be processed.
ARGUMENT:: transBufNum
(describe argument here)
The index of the buffer where the extracted transient component will be reconstructed.
ARGUMENT:: resBufNum
(describe argument here)
The index of the buffer where the estimated continuous component will be reconstructed.
ARGUMENT:: order
order of the IR filter used to model the signal in samples (how many samples previously are used to predict the next one as reference for the model) - higer = more accurate spectral def - like fft - low end res improv as well but not conencted to temporal res
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 algorythm 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
size of frame on which it is operating - hi is hi cpu but determines max trans size (not more than half)
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:: padding
handles on each sides of the block just for analyse - just for model param, not processed
The size of the handles on each sides of the block simply used for analysis purpose and avoid boundary issues.
ARGUMENT:: skew
-10 to 10 -> chapt 5 or 7 of the digital (kind of hysteresis on bespoke detection function)
The hysteresis on the bespoke detection function. Values from -10 to 10 will allow to prioritise change in the low or high register.
ARGUMENT:: threshFwd
threshold of the onset of error
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
threshold of the offset of the error
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
averaging window of the error detection function (because it is jittery)
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:: debounce
clumps transients within that window size
The window size in sample within with positive detections will be clumped together to avoid overdetecting in time.
returns::
RETURNS::
Nothing, as the various destination buffers are declared in the function call.
A sanity test for the FluCoMa Real-Time Client Wrapper footnote::This was made possible thanks to the FluCoMa project (http://www.flucoma.org/) funded by the European Research Council (https://erc.europa.eu/) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 725899).::
This class implements a sanity test for the FluCoMa Real-Time Client Wrapper. footnote::This was made possible thanks to the FluCoMa project ( http://www.flucoma.org/ ) funded by the European Research Council ( https://erc.europa.eu/ ) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 725899).::
CLASSMETHODS::
@ -20,9 +22,10 @@ ARGUMENT:: frameSize
ARGUMENT:: gain
Audio or control rate change of the gain.
returns::
RETURNS::
Same as input, delayed by the windowSize, multiplied by the gain factor.
EXAMPLES::
Summing with the inverse (gain of -1) with a delay of the latency gives us CPU-expensive silence.
A sanity test for the FluCoMa Real-Time Client FFT/IFFT Wrapper footnote::This was made possible thanks to the FluCoMa project (http://www.flucoma.org/) funded by the European Research Council (https://erc.europa.eu/) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 725899).::
This class implements a sanity test for the FluCoMa Real-Time Client FFT/IFFT Wrapper. footnote::This was made possible thanks to the FluCoMa project (http://www.flucoma.org/) funded by the European Research Council (https://erc.europa.eu/) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 725899).::
CLASSMETHODS::
@ -24,7 +25,7 @@ ARGUMENT:: hopSize
ARGUMENT:: fftSize
How large will the FFT be, zero-padding the buffer to the right size, which should be bigger than the windowSize argument, bigger than 4 samples, and should be a power of 2. This is a way to oversample the FFT for extra precision. The -1 default value will default to windowSize. This is not modulatable.
summary:: This section gives an overview of the toolbox for signal decomposition
categories:: Libraries>FluidDecomposition
related:: Classes/FluidBufNMF
TITLE:: Fluid Decomposition Toolbox
SUMMARY:: An overview of the FluCoMa toolbox for signal decomposition
CATEGORIES:: Libraries>FluidDecomposition
RELATED:: Classes/FluidBufNMF
description::
This is my description. It is part of the Fluid Decomposition Toolkit of the FluCoMa project. footnote::
This was made possible thanks to the FluCoMa project (http://www.flucoma.org/) funded by the European Research Council (https://erc.europa.eu/) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 725899).::
DESCRIPTION::
This is my description of the Fluid Decomposition Toolkit, part of the FluCoMa project. footnote::
This was made possible thanks to the FluCoMa project (http://www.flucoma.org/) funded by the European Research Council (https://erc.europa.eu/) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 725899).::
subsection:: stuff
This is my subsection
a note about the curated order of params, from source to necessary to poutine
Pierre Alexandre Tremblay
7 years ago