Sorry, yes, I'm using libpd. I'm trying to create a wide-band spectrogram app for Android.

Amplitude modulation of any sort, including envelopes, always distorts the spectrum to some extent.

Normally we don't notice because typical sounds have a complex spectrum, which masks the distortion.

But here, you are applying it to an artificially simple spectrum, containing only DC offset. DC offset is silent, and the spectral distortion is not, so there is nothing to cover it.

I generated an audio file with a 30 ms ramp up and 50 ms ramp down. For comparison, I applied this envelope to a sine wave in the right channel. Then I opened this file in Audacity and looked at the spectrogram.

I think it's pretty easy to see here why the envelope might be audible in the case of DC * envelope, but not perceptible in the case of the audible signal * envelope.

Bottom line is, just because you hear spectral distortion in an artificial scenario which you would never encounter with audible signals, doesn't mean that it will be noticeable in real world scenarios.

(Carrying it further: If there is no envelope, there's a risk of an instantaneous transition from non-zero to zero or vice versa. Instantaneous transitions require a lot of high-frequency content, which we hear as a click. A linear transition effectively lowpass-filters the instantaneous transition -- there are still artifacts, but they are relatively low amplitude, and in a frequency range normally occupied by musical tones at a much higher amplitude. A ramp-enveloped sound will never be perfect, but it's better than a rectangular envelope.)

"replaced by something better" -- A sinusoidal envelope shows a smoother spectrogram. You might try that: cos * 0.5 + 0.5 -- from pi to 2pi is your ramp up, 0 to pi is the ramp down.

Edit: You can eliminate the +0.5 by squaring the cos and halving theta, because cos^2 x = cos(2x) * 0.5 + 0.5. Actually cos~, IIRC, scales radians down to 0 .. 1, so you could do line~ --> cos~ --> [*~] (cos~ to both inlets) and drive it by "0.25, 0.5 30" for the ramp up, and "0, 0.25 50" for the ramp down. Haven't verified this at the computer but I think it's right.

hjh

@ddw_music here https://github.com/pure-data/pure-data/tree/master/extra/bob~ miller refers to the "cutoff frequency" which would be an odd term to use for a bandpass filter.. if you look at bob~ without any resonance it definitely behaves like a a lowpass.. I think that as the resonance goes up the pass-band might get attenuated? most discussions of the moog ladder filter refer to the lowpass filter (rather than the High-pass one) and since this certainly is not a high-pass filter I would say that in all likelihood it's an emulation of the lowpass species.
If you want to go for instructional clarity I agree that maybe other filters look more like "lowpass" filters in spectrograms tho (but bob~ still sounds like a lowpass to me imho)

This screenshot of a spectrogram recorded by alternating bob~ with a biquad low pass filter shows:

• bob~ attenuates both low and high frequencies somewhat.
• The biquad attenuates high frequencies significantly, but not low (the stronger band in the middle is resonance from Q).

bob~ doesn't sound to me like low pass, nor does its observed frequency response look like low pass.

hjh

Hi @Kitty Dyson. I tried to port a spectrogram shader to ofelia. Just updated it for Ofelia v3. You need to change it a bit for your desired result.
You can download it here (it is the sonogram patch): https://forum.pdpatchrepo.info/topic/12168/3-shader-adaptions-sonogram-vectorscope-and-conway
But I am sure you can implement a spectrogram without shaders too.

in tried to implement three shaders that could be useful with pure data.
the shaders are not my work, but i had to adapt and to learn a lot to make them work with pure data.
would be nice to improve them further.
i put the links from the shaders as comments into the frag. files.

ofelia_conway_sonogram_vectorscope.zip

the spectrogram works quite well, but i do not know if i implemented the best fft algorithm for that case / and in the right way...).

the vectorscope is quite gpu expensive. from the comment:
"GLSL is the absolutely worst medium for rendering this,
but Shadertoy seemed like a good place to find people who
might have ideas about this.

On the left is a return diagram. It is an X-Y plot of a
function against itself at a constant offset. The offset is
a tunable parameter. If it is set to one fourth of the
period of a certain frequency, then waves at that frequency
will cause the diagram to draw circles. Other frequencies
will cause some kind of ellipses.

On the right is a phase space diagram of the signal. It is
an X-Y plot of the signal against its differential. The
scaling factor applied to the differential is a sort of
tunable paramater too, which again allows you to choose one
frequency to form perfect circles.

These both draw kind of neat patterns, but not really neat
enough to work as visualization. How could this be improved?
(You'd probably have to do it in something other than a single
shader, though, to be able to draw more points, or lines.
Having access to more of the signal might also be a good thing.)"

The conway shader works good, but i do not understand it enough to change the rules or even the size of the cells...

@leech If you reduce the dynamic range of the spectrogram, or increase the resolution, or both, you can get it to show a line at 80Hz.
40dB and about 16384 bins should give you a red line with standard colours.
Although a sine wave has a constant frequency the rate of change of amplitude varies over the cycle.
Windowing functions are used with FFTs. These transform the signal block-by-block into a spectral representation whose resolution (accuracy) in both the frequency and time domains are proportional to their size.
Unless the window "width" ...... time....... matches the width of a cycle or cycles of the sine wave you will get spectral leakage.
http://download.ni.com/evaluation/pxi/Understanding FFTs and Windowing.pdf
David.

Hey guys, I just tried to record a simple osc~ 80 Hz in a wav file.
When I open the file in sonic visualiser to get the spectrogram I wasn't expecting it to be like this but to clearly show a red line at 80Hz and nothing else..? What am I missing? Spectrogram attached.
Thanks

In Sonic Visualizer, there's a spectrogram option called 'Bins' that, when I set it to 'Frequencies', seems to show precise frequencies like SPEAR, but with a higher resolution/more info. I'll try using that for a new analysis and see if it helps...

I guess I should read through the SV documentation at some point.

@Azoso Hello and welcome to the forum.
It can all be done of course.
I would recommend starting with an installation of Pd extended if possible, rather than Vanilla, as at least one of the tools that you need (spectrum analyser) is then immediately available in the download.
If you are using a recent 64-bit mac os then that will not be possible, and things get more complicated.
You will then need to use "help" "find externals" from the Menu of Pd and download all the externals.

You can always switch to Vanilla later when you know more about the workings of Pd "under the hood".

The spectrum analyser (probably the most difficult part of your project) can then be created instantly by placing an object [spectrogram~-help] in your patch. Then right-click it to open it.

You can see it working by connecting an [adc~] to the [spectrogram~] object instead of the [noise~] object...... and you will be inspired to continue.

Then change [spectrogram~-help] to [spectrogram~] so as to use it in your patch.

Come back when you get stuck!
David.