@whale-av The 3.5mm jack without a resistor would actually add more noise than with it,. The input jack is a switchting type jack, with nothing plugged in the tip and ring is shorted directly to ground, if you just plugged in a bare plug, it would break that short to ground, the plug would become an antenna and while being very short and limited in the wavelengths it could pickup, it would pickup a good deal and certainly more than the Johnson noise of a resistor, if you just plugged in a cable and left the other end unplugged, you would get even more since your antenna is now longer and can pick up longer wavelengths better. A resistor added in, will just resist, those weak RF signals will need to over come that resistance to reach the preamp and be amplified. Johnson noise is a very small factor, it does contribute, but it is not something one would really want to try and exploit as a noise source, a few feet of and wire will give you considerably more. A rather simplified explanation and not completely correct, consider it practical but not technical.

As an aside, the second ring on the standard tip, ring, ring 3.5 mm plug that we see on phones and anything that can take a headset is powered, those headsets use electret microphones which need some voltage to function. I am not sure what this voltage is, but if you can find a zener diode with a reverse breakdown voltage that is less than the voltage supplied by the jack for a microphone, you could likely build a noise generator into a standard 3.5mm plug with little issue. Zener diodes are generally thought of as poor noise generators, their output level is quite erratic, they are too random to be good noise, but that is great when your needs are random and not pure white noise. There is no real gain to building such a noise source into a plug, just plugging in any cable and leaving the other end floating will do just as well and with less effort.

@deframmentazione-geometrica Some of that noise would also be from the circuitry feeding the ADC, from here we get the noise from the preamp which generally just has its input shorted to ground when nothing is plugged in and still is amplifying anything that manages to get into the circuit, this includes the self noise of the amp, Johnson noise, any RF which manages to get in, ground noise, digital noise seeping into the analog, etc. This is unlikely to be a portable solution since some devices will turn off the ADC itself when nothing is plugged in as a power saving measure, so no noise or clock jitter and some will likewise turn off the preamp when nothing is plugged in, so we loose that source of noise, which is likely the dominant source in most cases.

Hi Pd

Here is a higher precision & functions knob GUI object [abcknob], as a replacement for [knob].

Main features (advantages over the wellknown [knob]) :

• A variable gauge startpoint, not only leftmost but also any point you can set
• Available a numerical meter at the center area of the knob
• Accurately showing knob direction when its degree is 90, 180 or 270
• Downward compatibility for [knob]; Your patch will work well if you replace [knob] with [abcknob] by any text editor

I made this object when the pd-extended was on-going.
Recently I found that the pd-extended is now outdated and the current pd-vanilla does not supply the [knob] object. So I updated my own object and would like to share it to help your patching life.

abcknob - Mac, Win and Linux binaries archive for Pd 0.47

Yoichi

@svanya Wow. Looks nice.

The values I had used for the various bands were chosen to approximate a flat frequency response. So, you adjusted one value, and the noise was suppresed (more or less) evenly accross all bands.

You've made it so that you can suppress the noise by band - sort of a graphic noise equalizer.

The value you've labeled hip_frq is what differentiates static noise from actual content. The lower this value, the longer a sound must be present for it to be removed as noise. Say, you sing a really long note that goes on for 10 seconds. If the hip_frq is set to 1Hz, then that note will be recognized as noise after a second or so and will be filtered out. So, you would set the hip_frq to a lower value (say, 0.1Hz) which will make the filter allow the long note. It also means that the filter will respond slowly to all noise. With hip_frq set to 0.1Hz, it will take around 10 seconds before a sound with a constant volume is filtered out.

The lop_frq is sort of the opposite. Anything whose volume changes to quickly is assumed to be noise. If lop_frq is set too low, then you will lose things like snaps or pops (say, the click of beating drumsticks together or the onset of a cymbal crash.)

The values for hip_frq and lop_frq I used were what I found useful for speech.

hip_frq probably needs to be lower for music, and lop_frq probably needs to be higher for music.

@svanya Hello Svanya...... first, I apologise for the "Spaghetti Omelette". Your patch was not at all messy. My damaged brain could not concentrate enough to comprehend any of it.
Noise is pretty random. There are elements of it that can be predictable depending on the source, but only by frequency. So a "hum" in Europe will be exactly 50Hz, and in the US 60Hz. High frequency noise (from poorer quality op amps) though is absolutely random. Often nowadays there can be some predictable noise from a computer bus, and again that can be filtered by a notch filter.
But apart from filtering those known frequencies you cannot "predict" the waveform of the noise. You can kill it dead with a reverse phase in real time, but once you have the desired signal, music or whatever, added to the noise then the battle is lost. You certainly cannot loop an "anti-phase" signal for future subtraction. The noise is not a repetitive waveform except for those determined frequencies.
Noise cancelling headphones have a microphone capturing the external noise and adding that out of phase to the headphone amplifier signal...... but the noise is "known" in real-time, which makes that possible.
As you have mentioned before, extreme filtering has some nasty side effects. In post production, where the "noise" is analysed, and an anti-phase signal added to what is deemed to be noise, the desired signal can be heavily distorted, to the point where some frequencies are so overly amplified that there is high frequency "ringing", and high frequencies "muted".... so the music ends up sounding like an old wax gramophone recording! It can only be used in very small doses. Clicks and pops are much easier to deal with.....
David.

@svanya Use the MultibandNoiseFilter. The left inlet is audio, the right sets how much noise to remove. The outlet is the filtered audio,

Attach a slider to the right inlet with a range from 0 to 2. That ought to be a wide enough range that you can adjust it to clean things up without also destroying the voice signal.

How it works is pretty simple, but difficult for me to put into words. If you are interested in how it works, take a look inside NoiseFilter and NoiseDetector.

NoiseFilter pretty much just attenuates the audio based on the noise level that it finds. How it finds the noise level is the trick.

It uses the subpatch dBr to find the level of the signal, then passes that through a highpass filter and a low pass filter. Those two determine what is seen as "static" noise. Anything that changes slower than the high pass is static noise. Anything that changes slower than the lowpass is signal. Anything that changes faster than the lowpass is noise.

Changing the value of the highpass determines how fast things get filtered out - if it "eats" your long notes, then you need to make the cutoff of the high pass lower.

Once it has the filtered level, it takes the absolute value of the variations in the level and compares them to the selected noise reduction level. Anything below the desired level closes the gate. Since this causes a pulsing signal, theres's a lowpass to smooth it out.

Now, you have a signal proportional to how much noise is in your signal. The more the noise, the lower this proportional signal is.
Multiply that with your original audio, and it attenuates the audio according to how much noise there is.

The rest is splitting it into bands so that you don't attenuate everything at once, but just the frequencies where there's noise.

Well, the forum crash seems to have eaten my last post.

I have made a noise filter to clean up audio signals live.

Other noise removal filters need to have a noise sample selected and try to remove that noise from the complete track - they only work offline.

This patch works online. It removes any stationary noise from the signal and doesn't need any user adjustment except that it does need to be told how much to reduce the noise.

"Stationary noise" is a signal whose frequency content and amplitude stay (more or less) constant for over 1 second. Fan hum is a good example, as well as the more or less "white" noise from the wind from the fan. Car motor sounds from a car travelling at constant speed is also a good example.

It will also kill feedback squeal cold, even at the lowest settings.

The patch is built in layers, and the lower layers can be used independently or combined and used to build different filters.

The attached zip file includes all the components from the lowest level up to a complete demonstation that takes in audio from a microphone and puts out filtered audio on line out. It also includes a set of help files that describe the function and use of the various modules.

Included modules:
NoiseLevelDetector.pd - estimates the amplitude of the stationary noise

NoiseFilter.pd - attenuates the signal based on the amplitude from
NoiseLevelDetector.pd Since it is more effective at high frequencies, it is best to feed it limited bandwidth signals and use multiple filters to cover the desired audio range.

BandLimitedNoiseFilter.pd - a Noisefilter that only works on the specified frequency range.

MultibandNoiseFilter.pd - a complete filter that covers the range from 40Hz upto 22000 hz to filter the complete audio spectrum.

Test.pd - demo program that demonstrates the use of MultibandNoiseFilter.pd

It works best for speaking voices. Singing tends to be more stationary. It could be adapted to singing voices by changing a single value in one of the lower level blocks.

The original idea was to create filter for removing car noises from microphone audio for two-way radios. When used to cover just the range from 300Hz to 3000Hz, it does a very good job.

The biggest disadvantage is that it will start making "musical noise" if there is a lot of noise and the attenuation is set high. It also adds a slight echoing quality to the filtered audio.

The project is hosted on GitHub: PureData NoiseFilter project.

PureData_NoiseFilter.zip

Thank you all for your help. The samphold~ thing seems to do the trick, producing a sound that sounds much closer to the clip I posted than white noise. It sounds a little bit shakier than the clip, though, but this is a good start.

@nestor said:

I think what you're looking at IS the noise function, which seems to be the largest portion of the sample you posted. Perhaps the noise function is just as you described it, a random "flip-flop."

Near the end of the clip, there are some noise hi-hat sounds which seem to be actual noise, varying randomly within a range as opposed to most of the sounds which oscillate between two values. It seems strange that sounds in a "noise channel" can either be actual noise or just a random pulse wave. With 44100 Hz white noise I can't tell the difference, though at a lower sampling rate the pulse wave sounds a bit sharper.

well, I've got the four main instruments and the panelling done for my pd-NES, all that's left is to add glue for the sequencing and composition tools. I had to cheat pretty badly on the noise channel though. For the standard noise mode I used the method from zenpho which looks simple and sounds good, but I noticed he didn't emulate the looped-decay noise mode, which all my resources describe as being "difficult", but otherwise provide slightly different explanations of the mode. It appears that emulators and other software that fully emulate the noise channel seem to "wing it" and use their own unique methods. I'm guessing it's because the actual hardware driving the random number generator kicks out one random bit to the 4-bit DAC at 890KHz, which I guess I can't simulate in pd unless I could change my sampling rate to 445kHz (for 4bit codes). I haven't found a good explanation of what happens to each bit - apparently the hardware updates one of two different bit sequences (a 93-bit sequence and a 32kbit sequence, the latter of which makes no sense to me - that's a big load on the memory bus). I've tried creating different kinds of noise generators or 93bit noise samples, and looping them with an interpolating sampler and decay envelope, but it never sounded right. The problem is the noise itself - no matter how fast I loop I never get a smooth tone, or I still hear regular noise over the tone.

I ended up ripping the looped noise sounds from NES games and an emulator, storing them as timbre presets, and using soundfiler and elementary granular methods to transpose. It's definitely cheating, but it doesn't limit me to the 16 pitch colors that the hardware has to choose from. So I got what I wanted, the NES sound without all the NES limitations, but I'm a little frustrated that I couldn't find a solution that uses only generators as opposed to external samples.

Does anyone have a recommendation for correctly emulating the looped-decay-noise sound? I've attached a wav ripped from Megaman that has a D# tone at four different timbres (caused by different decay strengths in the envleope).

http://www.pdpatchrepo.info/hurleur/nnlx4_ds.wav

Hello,

please excuse my stupidity both in programming and generally in understanding PD. i've been trying to figure a way to convert a frame number (received with OSC) to a timecode but the code i tried to adapt from a matlab script by Malcolm A. MacIver that i found here http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=1116&objectType=File
involves some for...loop and i dont know how to do the same in PD... can anyone explain, please?
i guess the field part of the smpte timcode (and other bits of information) are usually not needed, for most people HH:MM:SS:FF Information will be ok... maybe with an adjustable framerate between 30 (ntsc) and 25 (pal)

greetings,
till

function smpte = dec2smpte(init, framecount, field)
% convert the smpte time from the total elapsed frames and field as an integer
% to the new smpte time

first_field=init(9);
weight=[1080000 108000 18000 1800 300 30 10 1];

ns=[];
remain=framecount;
for i=1:8
  ns(i)=floor(remain/weight(i));
  remain=remain- (ns(i)*weight(i));
end

if strcmp(first_field,':')
   second_field='.';
else                                     
   second_field=':';
end

if field==1
   field_flag=first_field;
else
   field_flag=second_field;
end

smpte=[ ...
    num2str(ns(1)) num2str(ns(2)) ':' ...
    num2str(ns(3)) num2str(ns(4)) ':' ...
    num2str(ns(5)) num2str(ns(6)) field_flag ...
    num2str(ns(7)) num2str(ns(8))];

different approach here

function itc (int "framecount", float "rate", bool "ms")
{
rate=default(rate,25)
ms = default(ms, false)

drop = (rate==29.97)? true : false
rate2 = (drop==true)? 30 : rate

hours=floor((framecount/rate)/3600)%60
mins=floor((framecount/rate)/60.0)%60
secs=floor(framecount/rate)%60
milli=floor(1000*framecount/rate)%6000%1000
fmilli=framecount/rate - floor(framecount/rate)
#frames=floor(fmilli*rate2)
frames=framecount%int(rate)

dframes = (drop==false)? frames : (secs==0)&&(mins%10!=0)? floor(fmilli*rate2) + 2 : frames

return (ms==false)? (string(hours,"%02.0f")+":"+string(mins,"%02.0f")+":"+string(secs,"%02.0f")+":"+string(frames,"%02.0f")) :
\ (string(hours,"%02.0f")+":"+string(mins,"%02.0f")+":"+string(secs,"%02.0f")+":"+string(milli,"%03.0f"))
}