Closed infovore closed 3 years ago
Thanks for reporting, it looks like the amplitude setting isn't ignored completely, in relation to the other noise generators it is simply set to 1/4th of the supplied value:
https://github.com/processing/processing-sound/blob/8bc3339fd2a43431b22e82c4b38fa164bf57e3e0/src/processing/sound/BrownNoise.java#L65-L68
So if your other noise generators have an amplitude of say 0.5
, you can just set brown.amp(2.0)
to achieve the same (physical) amplitude of the signal.
I can't quite remember why this was necessary, but judging from the comment it sounds like brown noise is prone to clipping (due to the strong low-frequency components), so the generator's amplitude is reduced as a precaution. I think that brown noise also greatly exceeds the perceived loudness of other same-amplitude noise generators, but dividing by 4 was definitely just a hunch/quick fix.
If you could try out empirically which amplitude for the brown noise you think is 'equivalent' (physically? perceptually?) to which amplitude of the other generators, we can adjust the scaling to a more suitable factor than 4.
Oh, wait a minute. So: in my sketch, I have keybinds for swapping between white/pink/brown noise. Brown noise, set to exactly the same settings as the others, is perceptually far louder. A quick tyrekick suggests that reducing the (already scaled) output of BrownNoise
by a factor of 10 (ie, 40, really) gets me something that sounds similar to the others.
Sample Sketch here; 1/2/3 keys toggle noise type. This sketch sets amplitude of the noise output to 0-1.0 based on MouseY; when Brown noise is selected, it scales 0-0.1.
Ah yes, that is more in line with what I remember. I just compared the time-dimension amplitudes (see sketch below) and it seems like the amplitudes of the different noise sources are all incommensurable, even if BrownNoise is a particular outlier. It might be good to change the BrownNoise amplitude scaling to an even lower value by default, even if this might break/affect sketches that mix Brown noise with other sounds. On my own laptop speakers the perceived difference in amplitude isn't quite a factor of 10 (i.e. 40) though -- are you using speakers with very good bass response by any chance? That might explain the difference in perceived loudness.
import processing.sound.*;
// All noise generators are instances of the Noise superclass.
Noise noises[] = new Noise[3];
// Store information on which of the noises is currently playing.
int current = 0;
Waveform waveform;
int samples = 500;
void setup() {
size(640, 360);
background(255);
// Turn the volume down globally.
Sound s = new Sound(this);
s.volume(0.2);
// Create the noise generators and put them into an array.
noises[0] = new WhiteNoise(this);
noises[1] = new PinkNoise(this);
noises[2] = new BrownNoise(this);
// Initialise the FFT and start playing the (default) noise generator.
waveform = new Waveform(this, samples);
noises[current].play();
waveform.input(noises[current]);
}
void draw() {
// Only play one of the four oscillators, based on mouseY
int nextNoise = constrain(floor(map(mouseY, 0, height, 0, noises.length)), 0, noises.length - 1);
if (nextNoise != current) {
noises[current].stop();
current = nextNoise;
// Switch FFT analysis over to the newly selected noise generator.
waveform.input(noises[current]);
// Start playing new noise
noises[current].play();
}
// Draw frequency spectrum.
background(125, 255, 125);
fill(255, 0, 150);
strokeWeight(2);
noFill();
// Perform the analysis
waveform.analyze();
beginShape();
for(int i = 0; i < samples; i++){
// Draw current data of the waveform
// Each sample in the data array is between -1 and +1
vertex(
map(i, 0, samples, 0, width),
map(waveform.data[i], -1, 1, 0, height)
);
}
endShape();
// Display the name of the noise generator class.
textSize(32);
fill(0);
float verticalPosition = map(current, -1, noises.length, 0, height);
text(noises[current].getClass().getSimpleName(), 0, verticalPosition);
}
My speakers possibly have "passable" bass response (they're very low-end studio monitors, or high-end computer speakers, but yeah, very different to laptop speakers). I'm also aware that perceptual response to sound is not a good way of making decisions given the variance in human ears!
Good point on not breaking existing sketches. TBH, I'd be happy with an update to documentation rather than code - I fully wasn't expecting to have to treat different noise oscillators as having such wildly different amplitude outputs; it took me a while to realise it was not my code at fault. Keeping existing behvaiour (and thus not breaking other people's sketches in future), but updating documentation to hint that this might occur, would be an almost equally acceptable solution, I think.
Yeah that sounds good, a brand new Processing documentation website (with Sound and Video library docs generated directly from the library source code JavaDoc annotations) is gonna go online very soon, so I'll be sure to add a note to the BrownNoise
class (and maybe tweak the amplitude scaling just a little bit lower...) Thanks again for reporting!
New online documentation/website is online!: https://processing.org/reference/libraries/sound/BrownNoise.html
As per https://github.com/processing/processing-sound/blob/8bc3339fd2a43431b22e82c4b38fa164bf57e3e0/src/processing/sound/BrownNoise.java#L20 : BrownNoise overrides amplitude settings, unlike pink/white, thus making it a) hard to compare to the others and b) outputingg totally different values for the same amplitude setting overall.
Is this intentional? It feels like it isn't.