High-resolution oscilloscope

[DigitalWhiteByte]

If I change from one buffer to a larger buffer all is well but if I change from a large to a smaller buffer I need to clear the audio before it works.
Can anyone confirm that ?

Sorry, my sample hold value, not working properly.
Ok now after you change the buffer size and retrig it refresh the new value size.

[tektoog]

Works for me too...*-*
good job !

[tester]

Ehm, so... This "Get_Audio_Buffer_Size_DWB~2012.osm" should be connected inside cyto's "superScope.osm" somewhere?

By the way (superScope.osm) - direct sound output seems to work fine here, my ASIO - not (view changes into this strange stretching flickering mode).

When we are at the graphs, I have another question. Is it possible to make using SM and ASM - an efficient FFT frequency viewer (and/or accurate freq peak finder)? Let say an equivalent of the resolution 0.336 to 0.084Hz at 44.1kHz and at some acceptable refresh rate?

[trogluddite]

Ehm, so... This "Get_Audio_Buffer_Size_DWB~2012.osm" should be connected inside cyto's "superScope.osm" somewhere?

At the moment, the size is hard-coded into Cyto's asm, so it needs a fair chunk of the code re-writing so that it can handle the different buffer sizes read by DWB's little gadget.
I imagine that also explains the difference when you switch to ASIO - your buffer size is probably different to the one that the code is made for (128 samples).

When we are at the graphs, I have another question. Is it possible to make using SM and ASM - an efficient FFT frequency viewer (and/or accurate freq peak finder)? Let say an equivalent of the resolution 0.336 to 0.084Hz at 44.1kHz and at some acceptable refresh rate?

A stream FFT is not impossible, I think, but very difficult - assembly in SM only supports a limited set of instructions, making nested arbitrary size loops tricky to code. For a really efficient FFT you would probably need to "unroll" a lot of the loops, making for a very large block of code (very easy to make a mistake, and very hard to de-bug).

High accuracy of frequency measurement and fast refresh (i.e. high accuracy of timing measurement) are, unfortunately, mutually contradictory due to the uncertainty principle. For greater frequency resolution it is always necessary to analyse a larger sample window containing more cycles of the waveform - this is also true of other frequency analysis techniques such as auto-correlation etc.
As an example, take a look at my "Funky Mountains" schematic. Try playing some pitched sounds into it while changing the "Speed vs. Accuracy" parameter - as you raise the value, a greater number of samples are used in the analysis, and you will see the frequency peaks become much more defined. At low values, the display is less sluggish, but the frequency plot becomes almost meaningless. (NB. the schematic has a fixed semi-tone resolution).
The optimisations that make FFT (relatively) fast also rely on the window having a power-of-two number of samples - so there is little room for maneouvre when choosing a compromise of window size. The window size also determines the lowest frequency that can be reliably measured - the wavelength must fit inside the window (several times for a good analysis).
For peak frequency/pitch measurement, you can get around these limitations to a degree by using interpolation etc. when there are certain known conditions - e.g. the pitch is known to be within a particular frequency range etc. For a good example of this, take a look at Martin's Pitch Extraction schematic. This uses auto-correlation to look for the discrete pitches of "concert tuned" semitones, folllowed by interpolation of adjacent frequency bands to find the degree of "pitch bend".

[tester]

Thanks Trog, I understand these issues. I just feel so encouraged by previous resuts achieved in long-time scoping/viewing (impossible became real).

I have an idea (I think). Since the peak detection is semi-sensoric (you hear the sound, you look at the screen), resolution can be dynamically changed, depending on actual zoom. The more you zoom to certain frequency spectra (left/right border limits or center point), the greater accuracy can there be. Magnification levels could be connected to resolution progression? I see no reason to display high resolution FFT on a small window/screen, but magnified area could show some more details (sometimes two or three peaks that produce very slow differential beating). I also think, that displaying the spectra below maybe 20-30 Hz is useless via FFT, maybe through some other algos for slow changes (wavelet or something like that as far I remember is used there?) - because there is nothing "musical/melodic" going on (most audible vibrations are harmonic, differential or physiological/phase-dependent in nature), only "bass pumping" and quasi/semi DC added to the signal. So maybe there are some ways to overcome some habits? Probably there some "overlap" routines can be used (repeating blocks?) or seeing the 44kHz as 22kHz and lower (which extends the time of samples). I don't know which one for offline and which one for "real time" view are used however. Just some thoughts.

Generally I'm interested in two directions. Visual observations of how the sound (and it's changes) looks like, and spectral peak detection over surrounding "background area" (peak frequencies, which in my case - are 2-4 per band in c.a. 10 bands, and these per band are very close to each other, let say 0.2 to 30Hz difference) per audio sample (batch processing on multiple files. These are for further projects, but I'm writting here while I remember about them.

[trogluddite]

Maybe something like the correlator system used in the "Funky Mountains" example (from my previous post) is more suitable then.
Compared to FFT it is inherently more scalable - the centre frequency and integration time of each bin are independently adjustable to any arbitrary value, there is no reliance on discrete "blocks" of samples, and extra bins are easily added by copying and pasting modules.
In that schematic the integration times are already scaled according to the frequency of each bin, as shown by the faster decay time for high frequency peaks (just a low pass filter on the correlator outputs, in fact). So the update speed vs. accuracy compromise is also very easy to tweak.
Should be quite simple to derive the frequency centres from the zoom scale, and also to scale up the integration times as the zoom increases in order to reveal the extra detail. There have been some nice quadrature oscillators posted since I made that too, which could potentially save a lot of CPU in the correlator code.

[cyto]

At the moment, the size is hard-coded into Cyto's asm, so it needs a fair chunk of the code re-writing so that it can handle the different buffer sizes read by DWB's little gadget.
I imagine that also explains the difference when you switch to ASIO - your buffer size is probably different to the one that the code is made for (128 samples).

I just looked over the code again, and I don't think it would be too hard to integrate. It would only involve adjusting 2 of the counters in there in addition to 2 "green" calculations. I think the most difficult part would be ensuring that we get an accurate buffer value before any of the accumulation routines start to run. Without knowing exactly how DWB's wonderful little sensor works, I can't be too sure how to implement it. I would imagine there is a significant time lapse (in terms of samples) between when the stream is initialized and when the final buffer size is returned. I promise I'll get back to this when my attention can be a little more focused (too many pots on the stove right now).

-cyto

PS. not to split hairs, but it's actually 256 samples

[DigitalWhiteByte]

Without knowing exactly how DWB's wonderful little sensor works, I can't be too sure how to implement it. I would imagine there is a significant time lapse (in terms of samples) between when the stream is initialized and when the final buffer size is returned.

I try to explain, as I think it works.
each time it fires a polyphonic voice, it respects the size of the buffer of the soundcard.
then the smallest execution of a note will have the size of the buffer.
if you try to increase the duration of the note in milliseconds, you will notice that the read buffer will be increased by a size equal to cover the period.
for example if my buffer is 1024 samples, each time will be increased will be equal to the size of the buffer, then 1024 +1024 +1024 and so on.

Then measuring the shortest note that the polyphonic voice can make you get the size of the buffer set to the sound card.

Audio_Buffer_Size_Watch.osm

(7.06 KiB) Downloaded 171 times

[tester]

Knock, knock!:-) Any chances to finalize the cytoscope with this buffer tiny thing?

[cyto]

Knock, knock!:-) Any chances to finalize the cytoscope with this buffer tiny thing?

Soon I had a chance to work on it a little tonight. I have the buffer-size issue sorted out. It works well even at "strange" buffer sizes. There still is one tiny little issue with the internal timing that causes a very slow "drift" in the readout at certain zoom settings. I want to get that worked out before I post it. Sorry it has taken so long... I have a lot on my plate right now!

-cyto

[aliasant]

Keep on perfecting Cyto!
Well all be here waiting patiently in an unorganized line/mess

Interesting that you figured out how to get it to work with odd buffers.

[cyto]

Okay. I think I have everything sorted out.

superScope2.osm

(63.93 KiB) Downloaded 177 times

I was able to integrate DWB's "buffer get" method into the scope (I was actually able to simplify it even more, but the essence is still the same). This version should work for all buffer sizes, but there are a few caveats...

First, the resolution of the scope display (data points) is always equal to the buffer size. This may be problematic if you are using either very small (ie <64 sample) or very large (>1024) buffers. There is a way to adjust the resolution based on integer factors of the buffer, but I don't think it would be worth it to add that functionality. I'm sure most people will be using around 128-512 sample buffers, which should translate pretty well to the scope display.

Second, you have to manually reset the scope if your current ASIO setup is not compatible with the scope. For instance, when you download this osm, it is configured to "my" buffer size of 256. If yours is something like 384, you have to hit the little "reset" button that I added. This will grab your value and re-initialize the scope. Adding an "automatic" detect would just be too much trouble, I'm afraid, since there is a lot green-to-poly-to-mono-to-green-to-mono stuff going on during initialization. So obviously, this is not really something that can go into a finished vst. But for metering during a build, this should be acceptable.

Anyway, it tested pretty well in my setup. If anybody runs into any problems, let me know and I'll try to address them.

-cyto

[tester]

Can the reset not be done simple and automatically? Something like "after load" trigger plus trigger on changing soundcard? But manual reset/cleanup is desirable option too Thanks!

[adamszabo]

Very nice stuff guys! Cyto, I have added a new zoom control and changed the old zoom into an amp knob. I guess it can be done in a nicer way, I just did it for fun

[cyto]

Can the reset not be done simple and automatically? Something like "after load" trigger plus trigger on changing soundcard?

Absolutely! If you go this route, though, you need to find some way to get a "green" trigger from the soundcard change. The only way I can think to do this is via the "audio select" module. I'm pretty sure that sends a trigger out. Just route that trigger into the "reset" node and it should work okay. I'd be interested in any better suggestions for "auto-detect" though.

Adam, that zoom is awesome! Though, may I suggest that the "amp" multiply the incoming audio signal and not the arrays. The reason this might be better is that the code section has a "clipping" routine to keep the graphs [-1 to 1]. So if you have a loud signal going in and you "amp" it down to see its peaks, they won't be there because they will have already been clipped. If you multiply the incoming signal, though, they will be kept intact. A cool feature, though!

-cyto