KVR :: rs-met » Signal Analyzer [View Original Topic]
There are 62 posts in this topic.

---

Dozius - Fri Feb 08, 2008 2:47 pm

---

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

---

Robin from www.rs-met.com - Fri Feb 08, 2008 4:17 pm

---

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 - Fri Feb 08, 2008 8:49 pm

---

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.

---

Robin from www.rs-met.com - Sat Feb 09, 2008 12:00 am

---

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?




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?



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 - Mon Feb 11, 2008 11:11 am

---

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.




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.



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.

---

Robin from www.rs-met.com - Mon Feb 11, 2008 4:52 pm

---

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

http://www.tequipment.net/pdf/Instek/GDS-800-series_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 - Mon Feb 11, 2008 6:07 pm

---

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.

---

Robin from www.rs-met.com - Tue Feb 12, 2008 9:48 am

---

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 - Tue Feb 12, 2008 12:51 pm

---

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 - Tue Feb 19, 2008 10:24 am

---

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

---

Robin from www.rs-met.com - Wed Feb 20, 2008 11:40 am

---

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.



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



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.



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



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

---

CUNKA - Fri Feb 22, 2008 3:41 pm

---

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

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

---

Robin from www.rs-met.com - Fri Feb 22, 2008 3:49 pm

---

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 - Wed Feb 27, 2008 4:01 pm

---

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 - Thu Feb 28, 2008 4:47 am

---

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.

---

Robin from www.rs-met.com - Thu Feb 28, 2008 5:57 am

---

this is good news for me. now, as for further improving it...



oh i don't think, i want to do FFT in the waveform mode, but looking for the 'true' zero crossing (of the unfiltered signal) with the zero crossing of the filtered signal as point of departure might be worth a try. maybe i should also replace the lowpass by a bandpass with lower cutoff frequency somwhere in the subsonic range.



mmhh, i'm using a GUI library (JUCE) so these dropdown-menu related things are not really in my hands, i think. as for the random lines - might this be the not-in-time GUI-redrawing thing which was already mentioned or is this something else?

---

Robin from www.rs-met.com - Thu Feb 28, 2008 6:01 am

---

wot? disappear?! errm, the whole display disappeared or only the waveform itself? did it come back? what kind of 'abuse' was it?



much thanks

---

cnicky - Thu Feb 28, 2008 7:30 am

---

The abuse was holding down a note and violently modulating the frequency & amplitude of an FM OP Modulator using my midi keyboard joystick.

The resultant noise is unpleasant. This, on one occasion, caused the wave display to disappear, just the display. Clicking to spectrum and back made it return.


Not that repeatable during normal use.

I'll try a video capture if you'd like?

---

Robin from www.rs-met.com - Thu Feb 28, 2008 1:41 pm

---

well, if it is somewhat reproducable and you can capture it, i'd like to see it. this appears really strange. could it be, that the synth itself creates an invalid (out of reasonable range) sample value? i do not do any bounds-checking for the signal before drawing it, so maybe the display tries to draw a line to a point at infinity or something like that...just an idea

---

Optomadic - Tue Apr 22, 2008 5:22 pm

---

Robin any chance that Signal Analyzer can run as light as Multi Mod?

Thanks for any helpp.

---

Robin from www.rs-met.com - Wed Apr 23, 2008 2:58 am

---

i see some potential for optimization for the oscilloscope view when it is zoomed out (i think, my buffering technique is suboptimal here). however for the spectrum analyzer i can't see that much optimization potential at the moment. as light as MultiMod? whoa...gimme an FFT algo as light as a multiplication...well, not exactly the same case but close.

---

Optomadic - Wed Apr 23, 2008 8:07 am

---

As I know nothing about this stuff it kinda of confuses me when thinking of more effects is less processing. Or maybe it just seems that way when the hood is closed down over the engine ..

---

Robin from www.rs-met.com - Wed Apr 23, 2008 8:34 am

---

errrmm...you mean like: the more audible a process is, the more cpu-load you expect? the notion of 'more effect' is rather ambigous. i could - as a simple example - just hard-clip some incoming audio and drive the input of the clipper heavily. that would certainly be a VERY audible effect, yet take next to no cpu. and an FFT analyzer is not suppsoed change the incoming audio stream at all - its sole purpose is visualization. but in order to visualize the signal, it has to do some serious processing. on the bright side, it takes cpu only when the GUI is open (as opposed to effects which modify the sound).

---

atomota - Wed Apr 23, 2008 8:37 am

---

This is where the hold off control on my analog scope really helps. Contrary to what was said earlier in this thread, it doesn't set the delay between the trigger and the subsequent sweep (there is a different function for that), it holds off the trigger (ignores trigger conditions) for some adjustable time after the end of a sweep, e.g., until approximately the start of the next period. Alternatively, you can put a wave with the same period but a more stable shape on the other channel and trigger from that.

---

Optomadic - Wed Apr 23, 2008 8:39 am

---

No no I was thinking the more feaures a plugin has the more CPU it would consume.

I just figured a plugin that is being used as a visual aid would be easier to optimize than one with filters etc. When you mention FFT processes going on under the hood in the analyzer it makes much more sense though.

One more question, does just the frequency analysis portion use FFT? Or the amplitude anaylsis also?

---

Robin from www.rs-met.com - Wed Apr 23, 2008 8:56 am

---

well, there might be some correlation but it certainly depends on the specific algorithm. many knobs = high CPU ... nah, that's too simple. in fact, i have a vocoder in mind that would not strictly require any controls at all, yet eat CPU for breakfast (and sound great).


why that? in particular filters can be made pretty fast - as long as don't design them a sample-rate.


no, the waveform display does not need FFT. but it needs buffering and peak-to-peak extraction for larger 'zoomed out' views - here is where i could probably squeeze out some more efficiency.

---

Robin from www.rs-met.com - Wed Apr 23, 2008 8:59 am

---

which is exactly what i do: the waveform with the same period but 'more stable' shape is just a lowpassed version of the incoming signal. that works really well for mono-pitched signals.

---

Optomadic - Wed Apr 23, 2008 9:18 am

---

Sounds interesting.. I'd be willing to feed it some CPU if its hungry ...

---

Robin from www.rs-met.com - Wed Apr 23, 2008 9:34 am

---

yeah, but it doesn't exist - and if it will exist someday, then with a modified algorithm (...which has some controls (and less cpu hunger) )

---

Optomadic - Wed Apr 23, 2008 9:38 am

---

Not to sound ungrateful but may you could make 2 separate analyzers?

---

Robin from www.rs-met.com - Wed Apr 23, 2008 10:01 am

---

you mean two separate plots for left and right instead of colour coding? i could...but what would be the real advantage of such a presentation? i mean, i'd have to squeeze the plot-height then by a factor of two (or a bit more than that). or increase the GUI size (and - by the same token - couldn't an increased GUI size be better used for a bigger color-coded display then?)

---

Optomadic - Wed Apr 23, 2008 10:04 am

---

No no 2 separate plugins one for freq other for amp. Either that or maybe when you switch to velocity view it turns off FFT all together (vice versa)..

---

Robin from www.rs-met.com - Wed Apr 23, 2008 10:25 am

---

there would not be any benefit in that - if you want spectrum analysis and oscilloscope at the same time, simply use two instances, one as spectrum analyzer and one as oscilloscope. see, the only 'advantage' of having separate plugins for each application would be the *impossibility* to switch the mode for each.


velocity? this is not a MIDI monitor - i guess you are talking about the time domain signal (oscilloscope view)? in that view, of course, the FFT is not running - it only runs when it's needed. ...ahh i see the first request now in a different light - you assumed the FFT was always running and wasting CPU even in oscilloscope mode? no - that's not the case.

---

Optomadic - Wed Apr 23, 2008 4:08 pm

---

Ahh I see. Ok sorry for being a bit selfish there

---

Robin from www.rs-met.com - Fri Apr 25, 2008 11:17 am

---

selfish? i would say, you have been having some misconceptions about the internal working of the plugin but i can't see you having been selfish here.

---

damstraversaz - Mon Apr 28, 2008 11:45 am

---

i really like your plugs, very useful .
I have a little question: does signal analyser introduce some latency ? I really like the gui, and I'm thinking to use it as meter for live use.I ask this question because most of analyse's plugs I know introduce latency

thanks again !

damien

---

Robin from www.rs-met.com - Mon Apr 28, 2008 1:27 pm

---

not on the audio path - signals are just passed through. only the visual display is delayed by the blocksize.

---

damstraversaz - Mon Apr 28, 2008 1:32 pm

---

thanks for the quick answer!

---

Robin from www.rs-met.com - Mon Apr 28, 2008 1:43 pm

---

no problem. however, i'm not so sure if i would really recommend it for live use...it may slow down the responsiveness of your setup (the actual FFT is done in the GUI thread).

---

Optomadic - Tue Apr 29, 2008 4:42 am

---

Again with the FFT

---

sikahr - Thu Jan 14, 2010 5:01 pm

---

Hi Robin,

is it possible to add one more mode:

L-R Spectrum Difference,

very useful for filter or EQ design.

Many thanks, Your plugins are top gear.

Nenad

---

mystran - Thu Jan 14, 2010 7:38 pm

---

+1, some sort of mid/side mode would be lovely

---

Robin from www.rs-met.com - Fri Jan 15, 2010 4:34 pm

---

yes - mid/side mode is very useful indeed. i have implemented it today. unfortunately, it appears that i have messed up a couple of other things while refactoring the code (which was due anyway). when fixed, i'll upload it.

---

Robin from www.rs-met.com - Sat Jan 16, 2010 1:31 pm

---

...so here we go:

www.rs-met.com/software/betas/MultiAnalyzer.zip

this one is different in that it uses my newer GUI look-and-feel and is also very different internally. ah - and i apparently changed the name with the hidden agenda that it may eventually may provide yet more views and analysis options. so i hope, i didn't break anything - just let me know when something doesn't work as expected.

if everything is alright, i'll address some minor cosmetic modifications and finally make an official update.

---

gts - Fri Jan 22, 2010 5:36 am

---

Hi man,

I like this plugin alot. But your new version is quite pc hungry.

Anyway as much as i find this plugin useful, could you implement something like a slow motion knob in a new version? Because it's quite difficult to follow the waves sometimes

Anyway thanks for this plugin

---

Robin from www.rs-met.com - Fri Jan 22, 2010 6:12 pm

---

more so than the old?


are you talking about the oscilloscope here? if this is the case, then how would such a slow-motion mode be supposed to work? i mean, the waveform must somehow stay in sync with the input - or not? frozen frames every so-or-so fraction of a second? that would probably look like a game on a too slow computer. maybe i misunderstand your request? btw.: for monophonic, pitched signals, the waveform-sync actually works rather well but for chords and stuff the display can become a bit erratic, i know.

---

gts - Sat Jan 23, 2010 10:14 am

---

Yeah at the size 32768 i can't use more than 2 plugins. My pc starts to lag. I didn't have this problem with v.1


I was talking about oscilloscope and a spectrum analyzer. In voxengo span you can adjust the speed of spectrum from 6 to 64. Its quite handy when you do a real time adjustments. I think it's not in sync with imput and it's not a bad thing.
The same goes for osciloscope

Anyway what i like in your plugin is the small size of it and that you can have size of 32768 and watch spectrum in detail. The zoom is very nice as well

---

Robin from www.rs-met.com - Fri Jan 29, 2010 12:04 pm

---

...as is often the case when i actually plan to do some 'minor modifications', i ended up doing some major rewrite. this time it is about the handling of colorschemes in the user interface. there's now a 'Setup' button in the top-right corner where the user can adjust the colorscheme to taste. let me know what you think. i'm considering to reverse the operation of the 'Gamma' slider (thereby turning it into an anti-gamma or gamma-correction slider) - would that be better?


i just checked it out. span seems to always have some kind of inertia and implements some kind of afterglow schlieren. inertia could be realized by using a first order filter on the bin-magnitudes - the problem is that i poll the magnitudes asynchronously which would have to be changed for such an inertia-filter. for the oscilloscope, on the other hand, i can't think of a sensible way to implement inertia (but ideas are welcome). but...mmm...actually i happen to prefer the more direct response. with those higher frequency resolutions, you actually have some kind of inertia already built in anyway due to the time averaging of the longer windows (aka uncertainty principle).

i will now see if i can figure out what increased the CPU usage...

---

sinkmusic - Fri Jan 29, 2010 12:11 pm

---

Hi
The name "multi analyzer" seems to imply that it can work on several channels (like Schope or the BlueCat's one) : is it the case (if so, i haven't found how to route and configure it) ? If not, i mighthave been misleaded by the name, sorry

---

Robin from www.rs-met.com - Fri Jan 29, 2010 12:17 pm

---

ohh - what i actually wanted to express, is that it analyzes the signal in multiple ways (O.K.: currently only 2, but i hope that to grow - maybe sonagram, vector-scope, etc. at some stage). but i'm not entirely happy with that name anyway, so suggestions are welcome.

---

MWSOS - Sat Jan 30, 2010 5:40 am

---

Hi Robin,

I'm loving this SignalAnalyzer plug-in of yours, because it makes it so easy to switch between frequency and time domains It will hopefully be getting a plug from me in a future PC Notes column as well

The CPU overheads in Spectrum mode are indeed mich higher than other similar plug-ins I have (such as Nugen's excellent Visualizer), although they remain manageable with the FFT window size set to 8192.

However, as you're being so proactive, can I please ask for a couple of minor tweaks to streamline general operation?

It would be much easier if the Display and Sync controls were buttons like Freeze, so you could toggle their setting with a single mouse click rather than the current click, move your mouse, click again

Many thanks if this is possible!


Martin

---

Robin from www.rs-met.com - Sat Jan 30, 2010 9:21 am

---

PC Notes? is that a magazine you work as editor for? if so, i'd certainly be very happy about being mentioned. thx in advance.


thanks for the heads up for nugens visualizer. i just visited their website and the plugin seems to be indeed a fine one and will probably serve me well for inspiration. i just checked my code (for the newer version posted here) and might have found a reson for the high CPU usage: i have an update-interval of 20 ms (corresponding to a framerate of 50 frames/second) - that's probably overkill. half of that would be enough. maybe i should offer the framerate as user parameter?



yeah you are right - the new beta has buttons for the display (should feel almost like a tabbed interface). the reason for providing sync as a menu was that i was considering different modes for syncing - but you are right - as long there is only one option (besides off), it makes more sense to have a button. ...and since i'm actually happy with the way it syncs and therefore see no need anymore for other sync-modes, i will change this into a button

---

MWSOS - Sat Jan 30, 2010 12:22 pm

---

My name should have given the game away

Apart from all the reviews and features, I've written the monthly PC Notes column for Sound On Sound magazine since 1997:

www.soundonsound.com/search?Section=8&Subject=62


Martin

---

Robin from www.rs-met.com - Sat Jan 30, 2010 2:29 pm

---

aaahhh! i see! sound on sound. in this case, i'm especially happy that you like my pluggy.

---

tranceglobal - Sun Jan 31, 2010 3:09 pm

---

Hi Robin,

I am new to your forum, but I recently purchased EchoLab, which has to be the finest delay I have used in terms of interface and options. EQ and Scope are very useful too. I am really digging your well thought out plugins, although the interfaces are a bit brightly colored (white background) and could be larger. Still it really is some of the best stuff around, thanks!

Now regarding a Multi Analyzer plugin: I have long wished for an analyzer plugin with all of the following in one:

1. Scope / Waveform
2. Spectum Analyzer
3. Vector / stereo-gram (waterfall view option like the Blue Cat plug would be nice)
4. Sonogram
5. Tuner
6. Bit Meter

MicroSchope already does 4 of these, but is so small I can hardly use it. There are a couple other companies with similar plugins, but their price to feature ratio is not the best. I found the Nugen Audio product limited and expensive, personally - and its interface is fairly small also. Monitors are big these days - no shortage of space!

Interested to see where you decide to take this! I think with some additions and improvements your O-Scope could become another product I would be willing to buy at the right price point. Thanks for listening.

D.

---

Robin from www.rs-met.com - Sun Jan 31, 2010 3:20 pm

---

hi and welcome then. and thanks for your purchase and the kind words. as for the colors: have a look at the fresh beta of the analyzer - the colors are customizable there (within limits) - i'm planning to include this feature into all other plugins as well ...one by one (next probably into straightliner which is due for an update anyway)

as for the other analysis options - i have this in the back of my head anyway (as said), but i currently have some other higher priorities, so i can't give a time-schedule. i recently experimented a bit with a resizable GUI - alas, it seems like the drawing becomes considerably more cpu-intensive when making the GUI bigger. maybe i can optimize this a bit but i wouldn't expect miracles. a full-screen analyzer would certainly be an awesome, cool and desirable thing, but currently, this seems not feasible cpu-wise.

---

Robin from www.rs-met.com - Sun Jan 31, 2010 3:49 pm

---

mmhhh...Bit Meter? what is that? how is it supposed to work?

---

tranceglobal - Sun Jan 31, 2010 4:09 pm

---

Rather than me messing up the explanation, I will offer this link - in the thread, one of Cakewalk's programmers comments on some of the uses of their BitMeter plugin:

http://forum.cakewalk.com/tm.aspx?high=&m=956916&mpage=1#956957

I must admit that such a feature would not be useful to everyone. I have always just imagined one analyzer that does everything from one interface, rather than having to load up and open so many different plugins to get picture of whats going on.

D.

---

MWSOS - Sun Jan 31, 2010 4:15 pm

---

Hi D!

At the risk of going off-topic here, like Robin I'm impressed with Nugen Audio's Visualizer, and find it one of the most comprehensive of its kind available. It also has two interface sizes that you can switch between at any time, and I personally find the larger one more than adequate

However, it lacks a scope, which is why I'm so impressed with Robin's freebie

Martin

---

Robin from www.rs-met.com - Mon Feb 01, 2010 1:33 pm

---

O.K. but somehow i still don't get what it actually shows - the bit pattern of ....what? of one particular (pseudo-randomly chosen) sample inside some time window? or maybe the bit pattern of the maximum sample inside a window? the latter would probably make more sense but still i can't really see why this should be more useful than a simple peak level-meter (except being flickering erraticaly, if that's what one likes ). information content wise, showing such bit patterns would amount to a level-meter with a resolution of 6 dB. or am i missing something here?

edit: but what could be interesting instead would be a kind of running histogram of the amplitudes. i think, i have seen something like that in izotope ozone

...hah, yes:

http://www.izotope.com/support/help/ozone/index.html

certainly a good source for inspiration as well. they also describe the bit-meter operation there, but i'm still a bit sceptical. need to think about it.

---

tranceglobal - Mon Feb 01, 2010 10:16 pm

---

After some thought, and more rigorous experimentation with the Cakewalk bitmeter under various dithering settings, I have to concede the point that this really may not be that useful on a day to day basis- I cannot say I will now start using the Cakewalk bitmeter to improve my mix in any way. I am now inclined to strike this from my previous list, and just ask directly for: Flashing Light Meter!!!!

D.

---

MWSOS - Wed Feb 03, 2010 1:44 pm

---

I agree - I do use the one in Wavelab to double check on bit activity in the lower areas when I'm working with 32-bit float and 24-bit files, and then again after I've dithered to 16-bits before I save the 16-bit version of the file, just to make sure.

However, a simpler display that would do that would be a simple '24-bit LED' that lights up if bits 17 to 24 are changing.


Martin

---

There are 62 posts in this topic.