Stream Goodies and Baddies Detectors

[trogluddite]

A couple of useful little DSP stream modules fell out of my SchematicWatcher project, which I thought I'd post separately for the attention of anyone who might find them useful.

Peak Meter Ballistics
This generates the ballistics (decay time) for a peak-reading meter in a way that is guaranteed to capture the highest peak value even if it doesn't coincide with when you sample a green float from the stream for driving the meter GUI.

Infinity and NaN detector
Lights an LED whenever a stream is found to contain a value of infinity, minus infinity, or NaN (not-a-number), even if it's only for a single sample. Feeding any of these values into a recursive filter or delay often causes them to lock up, so it might be handy for working out where they're coming from.

peak_inf_and_NaN.fsm

(130.59 KiB) Downloaded 1676 times

[Spogg]

Excellent trog!

Catching those peaks is something I’ve struggled with for years. This solution is better than what I currently use.

I will need to use the nan detector at some point I’m sure (unfortunately).

Cheers

Spogg

[trogluddite]

Thanks, Spogg.

The trick with the toggle driven from the same trigger as the M2F is quite a handy one for locking/resetting a vital output value, and it works just as well in DSP code. The M2F fetches the current sample value and the changed toggle state is picked up on the very next one. Even the order in which the trigger links are connected doesn't seem to make any difference. If the CPU were absolutely maxed out, I guess there might be a delay in theory due to the different thread priorities, but I've never noticed it happen in practice.

[tulamide]

Peak Meter Ballistics
This generates the ballistics (decay time) for a peak-reading meter in a way that is guaranteed to capture the highest peak value even if it doesn't coincide with when you sample a green float from the stream for driving the meter GUI.

I missed this thread! The funny thing is that I made something similar, but I moved the ballistics completely from DSP code to Ruby (I simply have no clue about DSP code), and just catch the highest peak independendly from the drawing. Not as elegant, but due to the much lower drawing rate regarding ballistic a less stressful method for the CPU?

EDIT: Just had a closer look at the module, and because of my laziness it isn't documented. I'm not sure anymore how I made it, but it seems to be a general "downforce" of the meter at a fixed rate, overwritten only by the peaks.

[trogluddite]

due to the much lower drawing rate regarding ballistic a less stressful method for the CPU?

Pretty likely, I would have thought, as the Ruby drawing code has to run anyway - the posted method is likely only better if a 'drop-in' module is needed for interfacing with 'green' GUI parts.

I may have a go at a version using the 'Ruby Frame buffer' trick that I've used in a few recent modules. That would have the advantages of your system (ballistics maths at GUI rate), plus lower overhead for reading DSP values into Ruby (no M2Fs to trigger, and reading via a method call anywhere in the Ruby code). In fact, the latest version of the 'spline envelope' uses a similar 'push down' system via Frames to poll whether any voices are playing on each redraw tick.

[tulamide]

I may have a go at a version using the 'Ruby Frame buffer' trick that I've used in a few recent modules. That would have the advantages of your system (ballistics maths at GUI rate), plus lower overhead for reading DSP values into Ruby (no M2Fs to trigger, and reading via a method call anywhere in the Ruby code). In fact, the latest version of the 'spline envelope' uses a similar 'push down' system via Frames to poll whether any voices are playing on each redraw tick.

Something like this? (see link)
I was turned away from it because of the intense cpu load, but I bet you found something much more elaborate that works blazingly fast!

[trogluddite]

Rather different to that (though as you say there, it's nice to see a practical example of "normal" use of Frames)! I used the trick in the mono4/poly readouts that I posted recently (the little 'how it works' module shows example code, but unfortunately it's a trick which only works for ASM on the stream side).

Basically, the trick makes a Frame into a custom "mem" - but without having to do any conversions between Ruby, green Float Array, and mem every time that data is exchanged. Both the stream ASM and Ruby can read or write to any address in this "buffer" at any time. So, the Frame doesn't need to capture the whole of every single audio buffer, and the values don't even have to all be from the same mono channel. For those readouts, there's only a single Frame element per-channel which is continuously updated with the most recent single sample value. The only thing missing is the peak-hold, which is just a matter of 'max'ing the sample values - the Ruby would then just have to 'push down' the max each time it reads the buffer, as in your system.

The only down-side is that it relies on passing raw memory pointers. It's unlikely, but it could potentially get broken if MyCo were to change how Frames are implemented (for example; if the method were removed which gives access to their address - a perfectly legitimate thing to do, as it's not a documented feature).

Now that I think about it, having the 'meter' versions of those readout modules take true peaks would actually be quite useful, so I may have a bash at adding it to those. It also should make it possible to remove all of the greedy ballistics and decibel calculations from the stream code.

[wlangfor@uoguelph.ca]

Hmm, these are just what I need. Thankyou

[tulamide]

Rather different to that (though as you say there, it's nice to see a practical example of "normal" use of Frames)! I used the trick in the mono4/poly readouts that I posted recently (the little 'how it works' module shows example code, but unfortunately it's a trick which only works for ASM on the stream side).

I just had a lok at it, and I immediately remembered upon viewing that I already used your trick a few years ago, when Martin needed ASM access to memory that's filled by Ruby. I don't know exactly what it was back then, but it was about SSE 4 channel access of Ruby arrays, something like that. Maybe Martin can elaborate on that?

However, I still love the solution! It took me quite some time and the patient help of KG_is_back to understand the packing you did there.

[trogluddite]

It took me quite some time and the patient help of KG_is_back to understand the packing you did there.

I think I probably picked up the idea from the same source - I didn't dream it up for myself, that's for sure! It probably helped that I used to do a lot of C coding years ago, where that kind of type-punning was a lot more common. It turns up in the API for the FS DLL component, too - the data that's passed to the .dll is formally an integer array, and you have to do a load of C++ "<reinterpret cast>" to turn the bit-patterns into the data types that they really represent.

It dawned on me the other day that the trick can be nested too. The Frame could contain float values which are really pointers to other Frames - proper multi-dimensional arrays in ASM without having to "flatten" them.