Signal Analyzer

[Dozius]

I've always thought the vst world needed a proper oscilloscope plugin. I've had to make due with smexscope, which is pretty decent but still lacking in features. Are there any plans to expand the functionality of this one? I thought it would be worth asking since it's a fresh project.

Also, while I'm at it I just want to say funcshaper rocks. I've been wishing the image-line waveshaper would let me input expressions for a long time.

-d

[Music Engineer]

hi Dozius,

and a warm welcome for the opening post here in this new forum. adding features to the signal analyzer? mmmhhh. i was thinking about - maybe - include a histogram view for the amplitude distribution at some time later. and maybe spectrum estimation methods other than the plain vanilla FFT (filter-bank, maybe chirp-z, correlation whith an oscillator bank, linear prediction, etc.). but these are at the moment not my first priority. do you have specific feature requests?

glad, you like the func-shaper. i guess, my first priority at this time should be to write documentations to these first 3 plugIns.

[Dozius]

do you have specific feature requests?

Well, what I've always wanted was a typical hardware oscilloscope in vst.

The things you would find on your typical oscilloscope:

At least two channel inputs with independent controls for all the usual things like v/div, coupling, reference. The usual horizontal controls (delay,time/div). A decent triggering section with hold off, level, slope and the ability to trigger from either channel plus internal and external source. XY display mode etc etc

This is just to give an idea, this would obviously take a lot of work to pull off.

[Music Engineer]

Well, what I've always wanted was a typical hardware oscilloscope in vst.

The things you would find on your typical oscilloscope:

At least two channel inputs with independent controls for all the usual things like v/div, coupling, reference. The usual horizontal controls (delay,time/div).

i have to admit that i'm not that familiar with hardware oscilloscpoes - i used one a few times during my studies but that is already some time ago. i think the v/div and time/div would be the vertical and horizontal zoom level, right? these are available via the zoom widgets associated with the scroll-bars in the bottom right corner. coupling, reference? what are these parameters supposed to do?

A decent triggering section with hold off, level, slope and the ability to trigger from either channel plus internal and external source.

well, yes, the sync menu has some space for some more triggering algorithms - at the moment, i provide a triggering by zero-crossings of a lowpassed input signal. that seems to work very well with periodic signals. but i can imagine to include other algorithms here as well (such as threshold triggering which seems to be what most oscilloscopes do). do you have some technical information about what all those terms mean and what those parameters do? as said - i'm not really familiar with such hardware devices. i approached my implementation more from a 'what do i want to see' point of departure rather then refering to existing devices.

internal triggering - you mean by some sort of built in oscillator? but why would one want to trigger to a signal which is in general unrelated to the input signal? and external triggering? that would require some sort of side-chain input then, right? mmmhhh...dunno what would that be good for?

XY display mode etc etc

maybe. but probably with a rotated coordinate system (by 45 degrees counterclockwise) then - aka Stereo Meter. but maybe that would fit better into the Track Meter.

[Dozius]

i have to admit that i'm not that familiar with hardware oscilloscpoes - i used one a few times during my studies but that is already some time ago. i think the v/div and time/div would be the vertical and horizontal zoom level, right? these are available via the zoom widgets associated with the scroll-bars in the bottom right corner. coupling, reference? what are these parameters supposed to do?

yes, v/div is vertical and time/div is horizontal. Generally you have control over each channels v/div and vertical positioning separately to make viewing two signals easier and one set of horizontal controls for all channels.

Coupling basically refers to the way the signal is presented to the scope. AC, DC and GND are three used. GND just ties your channel to ground and lets you set your reference on the scope, not so useful on modern digital scopes because your ground for each channel is usually indicated by a marker but on analog scopes you absolutely needed to know where on the scope your reference was especially when positioning multiple signals vertically across the scope. DC, the signal is sent straight through and the DC and AC content is shown. AC, basically the signal is sent through a cap in series your DC component is removed and your left only with your AC. Both have their uses.

well, yes, the sync menu has some space for some more triggering algorithms - at the moment, i provide a triggering by zero-crossings of a lowpassed input signal. that seems to work very well with periodic signals. but i can imagine to include other algorithms here as well (such as threshold triggering which seems to be what most oscilloscopes do). do you have some technical information about what all those terms mean and what those parameters do? as said - i'm not really familiar with such hardware devices. i approached my implementation more from a 'what do i want to see' point of departure rather then refering to existing devices.

internal triggering - you mean by some sort of built in oscillator? but why would one want to trigger to a signal which is in general unrelated to the input signal? and external triggering? that would require some sort of side-chain input then, right? mmmhhh...dunno what would that be good for?

hold off is basically a delay that happens when the scope is triggered. Good for viewing different parts of a signal. Level is just the threshold level, it seems your already familiar with that. Slope determines what edge the scope triggers on, usually you can pick rising, falling or both.

The internal trigger is generally used when slope or threshold triggering doesn't work out very well. It's really almost never used, but I figured I'd include it. Yes, External trigger would require a third input. This feature really is essential when you want to keep two signals correctly referenced in time to each other. For example your external channel would be connected to a clock, the display is now trigger by the clock and the signals can be viewed relative to each other in time correctly. There are many other uses as well. This is a lot more useful for data signals.

The reason I've been wanting a proper oscilloscope VST is when I'm doing work in things like bidule or other DSP environments and I want to apply scope techniques I use all the time in the lab. When dealing with raw audio signals some of these things might not seem necessary but once you start wanting to see how data signals and audio signals are working together or how audio signals are being changed from one point to another these scope features become essential.

maybe. but probably with a rotated coordinate system (by 45 degrees counterclockwise) then - aka Stereo Meter. but maybe that would fit better into the Track Meter.

Your right, that would be better implementation of that function.

I think if you can find a manual or spec sheet for one of the HP digital scopes (perhaps a HP 54602B) it might give you some deeper insight into whats going on and what types of features they have. I can also try to provide more detail on anything you have questions about. Markers and various read outs are another luxury of the mordern digital scopes that would be great to have.

[Music Engineer]

thanks for your explanations. i searched a bit and found this manual:

http://www.tequipment.net/pdf/Instek/GD ... manual.pdf

it's not the HP one, but seems to explain the parameters quite well. i think, i would need some optional "expert" mode if i want to include so many parameters without scaring off the average user. in the default mode, i would prefer to keep the user interface simple. i think i should do it.

[Dozius]

That manual seems like a good reference point. It seems to have all the standard options and then some. I agree that an 'expert' mode would be appropriate.

Just out of curiosity, I was reading in another thread that your using the JUCE API and I've noticed a few JUCE based plugins I've used have freely resizable GUIs. Would this be a possibility at all? I have no idea what kind of difficulties that might present but thought I should bring it up.

[Music Engineer]

well, it would require some dynamic arrangement of the GUI widgets such that they always meaningfully fill the space. and the actual realtime redrawing tends to become pretty CPU heavy when the GUI window is large. other than that, it is possible. do you regard is as desirable?

[Dozius]

well, it would require some dynamic arrangement of the GUI widgets such that they always meaningfully fill the space. and the actual realtime redrawing tends to become pretty CPU heavy when the GUI window is large. other than that, it is possible. do you regard is as desirable?

It would fall under the category of unnecessary but "cool" features. As long as two signals could be separated and shown in the same scope area at a reasonable size then it's not really needed but would be a nice luxury if it didn't affect performance too much.

[Highvoltage]

For me the Spectrum view badly needs an average time option. If it does, then it could be the best analyzer. Its damn fast, i dunno how you did it, but any other analyzer shits its pants at and over 8k window sizes. 32k??? youre crazy.

damn while im at it :

Also a L/R average would be cool. (maybe an option for larger view, dunno how it would affect the speed)

And pretty much what Ozone can do in the spectrum view (saving averaged curves for reference)
Ok i know thats too much but one can dream

[Music Engineer]

For me the Spectrum view badly needs an average time option.

O.K. so the display is too erratic? mhh..i actually mostly use the somewhat higher resolutions (> 4096) for which there is some kind of implicit smoothing/averaging due to the lengths of the windows. so maybe this is only because of a too low frequency resolution setting? but i will consider this. actually, i'm considering a different spectrum estimation method anyway which would include time averaging in the first place. so, we'll see.

If it does, then it could be the best analyzer.

wow. that's a bold statement. much thanks.

Also a L/R average would be cool.

ahh yes - that's good. i think i will include different channel modes like Mono L, Mono R, Stero L/R (in which it currently runs), Stereo M/S ...and maybe Mono M.

(maybe an option for larger view, dunno how it would affect the speed)

well, it would increase the CPU-load - i already tested this. maybe someday.

And pretty much what Ozone can do in the spectrum view (saving averaged curves for reference)
Ok i know thats too much but one can dream

errm...at the moment, this is probably indeed too much as i have some other projects in the pipe with higher priority.

[CUNKA]

What are your plans for SIGNAL ANALYZER? (feature wise)

Like , do you have a list that your working on now?

[Music Engineer]

not at the moment. i mean, i have a list of feature requests already in these two threads here, some of which i will probably implement when i have the time for that. but at the moment i'm working on other projects which seem to be more important. nevertheless, good ideas are always welcome.

[mystran]

I wanna give you some more feature request thingie:

For scoping audio, the biggest problem is getting a waveform to stay still when you want it to see how it changes in response to some parameter tweaking or whatever. Now the lowpass-zero-crossing method you use works remarkably well for something like a single filtered VA oscillator, but for more complex things (like mm.. two detuned oscillators, or say too much low-frequency resonance) it tends to randomly jump around as it pleases (though I have to say I've been pleased by how stable it tends to be in comparison to anything else I've tried).

So... how about this: either using FFT or autocorrelation or whatever, estimate the fundamental pitch, then use lowpass-zero-crossing to find the exact crossing, aiming for a previously estimated period? For extra fun, estimate multiple fundamentals (say two oscillators tuned in a fifth) and aim for their periods multiple (or GCD).

Oh and I'll report a bug as well (other than the randomly bugging lines that one sometimes sees in the spectrum view): open any drop down menu. Then move the plugin window. At least in FL Studio this will not close the drop down, but will not move it either and since the menu seems to be a separate floating window, you can even move the window from below it. The menu will continue to function and will happily disappear when clicking within the plugin window or switching the active application, so it's not like it's such a huge problem, but thought I'd mention it anyway.

[cnicky]

I put a single op FM patch through it with pitch/modulation wheels controlling amplitude/frequency of the modulator.

This resulted in the waveform display staying perfectly stationary. Using Sonar 7.02.

With some wild abuse I did get the waveform display to disappear.

This is one of the best tools I've seen in a vst.
Thank you.

Func Shaper is fanastic too.