chroma help files
parent
02aaab7efc
commit
31651016f8
@ -0,0 +1,126 @@
|
||||
TITLE:: FluidBufChroma
|
||||
SUMMARY:: An histogram of chroma classes on a Buffer
|
||||
CATEGORIES:: Libraries>FluidDecomposition
|
||||
RELATED:: Guides/FluCoMa, Guides/FluidDecomposition, Guides/FluidBufMultiThreading, Classes/FluidChroma
|
||||
|
||||
DESCRIPTION::
|
||||
This class computes the histogram of the energy contained within each chroma class. Also known as chromagram, this typically allows to get a contour of how much each semitone is represented in the spectrum. Tuning the central frequency reference, and how many bands are computed, allow for a flexible imprint of octaviated pitch classes.
|
||||
|
||||
The process will return a single multichannel buffer of STRONG::numChroma:: per input channel. Each frame represents a value, which is every hopSize.
|
||||
|
||||
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 chromagram to be calculated 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 analysed. The different channels of multichannel buffers will be processing sequentially.
|
||||
|
||||
ARGUMENT:: startFrame
|
||||
Where in the srcBuf should the 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:: features
|
||||
The destination buffer for the STRONG::numChroma:: to be written to.
|
||||
|
||||
ARGUMENT:: numChroma
|
||||
The number of chroma bands per octave. It will decide how many channels are produce per channel of the source.
|
||||
|
||||
ARGUMENT:: ref
|
||||
The frequency of reference in Hz for the tuning of the middle A (default: 440 Hz)
|
||||
|
||||
ARGUMENT:: normalize
|
||||
This flag enables the scaling of the output. It is off (0) by default. (1) will normalise to the FFT size. (2) normalises each frame independently.
|
||||
|
||||
ARGUMENT:: minFreq
|
||||
The lower frequency included in the chromagram, in Hz.
|
||||
|
||||
ARGUMENT:: maxFreq
|
||||
The highest frequency included in the chromagram, in Hz.
|
||||
|
||||
ARGUMENT:: windowSize
|
||||
The window size. As spectral description 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
|
||||
The window hop size. As spectral description relies on spectral frames, we need to move the window forward. It can be any size but low overlap will create audible artefacts. The -1 default value will default to half of windowSize (overlap of 2).
|
||||
|
||||
ARGUMENT:: fftSize
|
||||
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. The -1 default value will use the next power of 2 equal or above the windowSize.
|
||||
|
||||
ARGUMENT:: padding
|
||||
Controls the zero-padding added to either end of the source buffer or segment. Possible values are 0 (no padding), 1 (default, half the window size), or 2 (window size - hop size). Padding ensures that all input samples are completely analysed: with no padding, the first analysis window starts at time 0, and the samples at either end will be tapered by the STFT windowing function. Mode 1 has the effect of centering the first sample in the analysis window and ensuring that the very start and end of the segment are accounted for in the analysis. Mode 2 can be useful when the overlap factor (window size / hop size) is greater than 2, to ensure that the input samples at either end of the segment are covered by the same number of analysis frames as the rest of the analysed material.
|
||||
|
||||
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 [features] as an argument.
|
||||
|
||||
returns:: an instance of the processor
|
||||
|
||||
EXAMPLES::
|
||||
|
||||
code::
|
||||
// create some buffers
|
||||
(
|
||||
b = Buffer.read(s,File.realpath(FluidBufChroma.class.filenameSymbol).dirname.withTrailingSlash ++ "../AudioFiles/Tremblay-SlideChoirAdd-M.wav");
|
||||
c = Buffer.new(s);
|
||||
)
|
||||
|
||||
// run the process with basic parameters
|
||||
(
|
||||
Routine{
|
||||
t = Main.elapsedTime;
|
||||
FluidBufChroma.process(s, b, features: c, windowSize: 4096).wait;
|
||||
(Main.elapsedTime - t).postln;
|
||||
}.play
|
||||
)
|
||||
|
||||
// listen to the source and look at the buffer
|
||||
b.play;
|
||||
c.plot
|
||||
::
|
||||
|
||||
STRONG::A stereo buffer example.::
|
||||
CODE::
|
||||
|
||||
// load two very different files
|
||||
(
|
||||
b = Buffer.read(s,File.realpath(FluidBufChroma.class.filenameSymbol).dirname.withTrailingSlash ++ "../AudioFiles/Tremblay-SA-UprightPianoPedalWide.wav");
|
||||
c = Buffer.read(s,File.realpath(FluidBufChroma.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 a buffer as destinations
|
||||
c = Buffer.new(s);
|
||||
|
||||
//run the process on them
|
||||
(
|
||||
Routine{
|
||||
t = Main.elapsedTime;
|
||||
FluidBufChroma.process(s, b, features: c, windowSize: 4096).wait;
|
||||
(Main.elapsedTime - t).postln;
|
||||
}.play
|
||||
)
|
||||
|
||||
// look at the buffer: 10 bands for left, then 10 bands for right
|
||||
c.plot(separately:true)
|
||||
::
|
||||
@ -0,0 +1,136 @@
|
||||
TITLE:: FluidChroma
|
||||
SUMMARY:: An histogram of chroma classes in Real-Time
|
||||
CATEGORIES:: Libraries>FluidDecomposition
|
||||
RELATED:: Guides/FluCoMa, Guides/FluidDecomposition, Classes/FluidBufChroma
|
||||
|
||||
DESCRIPTION::
|
||||
This class computes the histogram of the energy contained within each chroma class. Also known as chromagram, this typically allows to get a contour of how much each semitone is represented in the spectrum. Tuning the central frequency reference, and how many bands are computed, allow for a flexible imprint of octaviated pitch classes. This implementation allows to select the range and number of chroma classes dynamically. It is part of the LINK:: Guides/FluidDecomposition:: of LINK:: Guides/FluCoMa::. For more explanations, learning material, and discussions on its musicianly uses, visit http://www.flucoma.org/
|
||||
|
||||
The process will return a multichannel control steam of size STRONG::maxNumChroma::, which will be repeated if no change happens within the algorythm, i.e. when the hopSize is larger than the server's kr period.
|
||||
|
||||
CLASSMETHODS::
|
||||
|
||||
METHOD:: kr
|
||||
The audio rate in, control rate out version of the object.
|
||||
|
||||
ARGUMENT:: in
|
||||
The audio to be processed.
|
||||
|
||||
ARGUMENT:: numChroma
|
||||
The number of chroma bands per octave. It will decide how many channels are produce per channel of the source.
|
||||
|
||||
ARGUMENT:: ref
|
||||
The frequency of reference in Hz for the tuning of the middle A (default: 440 Hz)
|
||||
|
||||
ARGUMENT:: normalize
|
||||
This flag enables the scaling of the output. It is off (0) by default. (1) will normalise to the FFT size. (2) normalises each frame independently.
|
||||
|
||||
ARGUMENT:: minFreq
|
||||
The lower frequency included in the chromagram, in Hz.
|
||||
|
||||
ARGUMENT:: maxFreq
|
||||
The highest frequency included in the chromagram, in Hz.
|
||||
|
||||
ARGUMENT:: maxNumChroma
|
||||
The maximum number of chroma classes. This sets the number of channels of the output stream, and therefore cannot be modulated.
|
||||
|
||||
ARGUMENT:: windowSize
|
||||
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
|
||||
The window hop 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. The -1 default value will default to half of windowSize (overlap of 2).
|
||||
|
||||
ARGUMENT:: fftSize
|
||||
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. The -1 default value will use the next power of 2 equal or above the windowSize.
|
||||
|
||||
ARGUMENT:: maxFFTSize
|
||||
How large can the FFT be, by allocating memory at instantiation time. This cannot be modulated.
|
||||
|
||||
RETURNS::
|
||||
A KR signal of STRONG::maxNumChroma:: channels, giving the measure amplitudes for each chroma. The latency is windowSize.
|
||||
|
||||
|
||||
EXAMPLES::
|
||||
|
||||
code::
|
||||
//create a monitoring bus for the descriptors
|
||||
b = Bus.new(\control,0,24);
|
||||
|
||||
//create a monitoring window for the values
|
||||
|
||||
(
|
||||
w = Window("Chroma Bands Monitor", Rect(10, 10, 620, 320)).front;
|
||||
a = MultiSliderView(w,Rect(10, 10, 600, 300)).elasticMode_(1).isFilled_(1);
|
||||
)
|
||||
|
||||
//run the window updating routine.
|
||||
(
|
||||
~winRange = 0.1;
|
||||
r = Routine {
|
||||
{
|
||||
b.get({ arg val;
|
||||
{
|
||||
if(w.isClosed.not) {
|
||||
a.value = val/~winRange;
|
||||
}
|
||||
}.defer
|
||||
});
|
||||
0.01.wait;
|
||||
}.loop
|
||||
}.play
|
||||
)
|
||||
|
||||
//play a simple sound to observe the values
|
||||
(
|
||||
x = {
|
||||
var source = SinOsc.ar(LFTri.kr(0.1).exprange(80,800),0,0.1);
|
||||
Out.kr(b,FluidChroma.kr(source, numChroma: 24, maxNumChroma:24));
|
||||
source.dup;
|
||||
}.play;
|
||||
)
|
||||
|
||||
//we can observe that in the low end, the precision of the fft is not good enough to give a sharp pitch centre. We still can observe the octaviation quantized in quarter tones.
|
||||
|
||||
// free this source
|
||||
x.free
|
||||
|
||||
// load a more exciting one
|
||||
c = Buffer.read(s,File.realpath(FluidChroma.class.filenameSymbol).dirname.withTrailingSlash ++ "../AudioFiles/Tremblay-SlideChoirAdd-M.wav");
|
||||
|
||||
// analyse with parameters to be changed
|
||||
(
|
||||
x = {arg chroma = 24, low = 20, high = 20000, norm=1;
|
||||
var source = PlayBuf.ar(1,c,loop:1);
|
||||
Out.kr(b,FluidChroma.kr(source ,numChroma: chroma, minFreq: low, maxFreq: high, normalize: norm, maxNumChroma: 24, windowSize: 4096) / 10);
|
||||
source.dup;
|
||||
}.play;
|
||||
)
|
||||
|
||||
//set the winRange to a more informative value
|
||||
~winRange = 0.04;
|
||||
|
||||
//instead, let's normalise each frame independently
|
||||
~winRange = 0.2;
|
||||
x.set(\norm, 2);
|
||||
|
||||
// observe the number of chroma. The unused ones at the top are not updated
|
||||
x.set(\chroma,12)
|
||||
|
||||
// back to the full range
|
||||
x.set(\chroma,24)
|
||||
|
||||
// focus all the bands on a mid range
|
||||
x.set(\low,320, \high, 800)
|
||||
|
||||
// back to full range
|
||||
x.set(\low,20, \high, 20000)
|
||||
|
||||
// free everything
|
||||
x.free;b.free;c.free;r.stop;
|
||||
::
|
||||
|
||||
STRONG::A musical example::
|
||||
|
||||
CODE::
|
||||
//something will happen here.
|
||||
::
|
||||
Loading…
Reference in New Issue