Support

If you have a problem or need to report a bug please email : support@dsprobotics.com

There are 3 sections to this support area:

DOWNLOADS: access to product manuals, support files and drivers

HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects

USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here

Stream Goodies and Baddies Detectors

DSP related issues, mathematics, processing and techniques

Stream Goodies and Baddies Detectors

Postby trogluddite » Tue Jan 07, 2020 5:29 pm

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 316 times
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
User avatar
trogluddite
 
Posts: 1541
Joined: Fri Oct 22, 2010 12:46 am
Location: Yorkshire, UK

Re: Stream Goodies and Baddies Detectors

Postby Spogg » Wed Jan 08, 2020 8:39 am

Excellent trog! :ugeek:

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
User avatar
Spogg
 
Posts: 2507
Joined: Thu Nov 20, 2014 4:24 pm
Location: Birmingham, England

Re: Stream Goodies and Baddies Detectors

Postby trogluddite » Wed Jan 08, 2020 11:58 am

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.
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
User avatar
trogluddite
 
Posts: 1541
Joined: Fri Oct 22, 2010 12:46 am
Location: Yorkshire, UK

Re: Stream Goodies and Baddies Detectors

Postby tulamide » Tue Feb 18, 2020 12:46 am

trogluddite wrote: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.
tulamide
 
Posts: 2158
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany

Re: Stream Goodies and Baddies Detectors

Postby trogluddite » Tue Feb 18, 2020 6:58 am

tulamide wrote: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.
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
User avatar
trogluddite
 
Posts: 1541
Joined: Fri Oct 22, 2010 12:46 am
Location: Yorkshire, UK

Re: Stream Goodies and Baddies Detectors

Postby tulamide » Tue Feb 18, 2020 8:29 am

trogluddite wrote: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!
tulamide
 
Posts: 2158
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany

Re: Stream Goodies and Baddies Detectors

Postby trogluddite » Tue Feb 18, 2020 4:51 pm

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.
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
User avatar
trogluddite
 
Posts: 1541
Joined: Fri Oct 22, 2010 12:46 am
Location: Yorkshire, UK

Re: Stream Goodies and Baddies Detectors

Postby wlangfor@uoguelph.ca » Tue Feb 18, 2020 8:47 pm

Hmm, these are just what I need. Thankyou :)
User avatar
wlangfor@uoguelph.ca
 
Posts: 792
Joined: Tue Apr 03, 2018 5:50 pm
Location: North Bay, Ontario, Canada

Re: Stream Goodies and Baddies Detectors

Postby tulamide » Wed Feb 19, 2020 12:13 am

trogluddite wrote: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.
tulamide
 
Posts: 2158
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany

Re: Stream Goodies and Baddies Detectors

Postby trogluddite » Wed Feb 19, 2020 12:44 am

tulamide wrote: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.
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
User avatar
trogluddite
 
Posts: 1541
Joined: Fri Oct 22, 2010 12:46 am
Location: Yorkshire, UK


Return to DSP

Who is online

Users browsing this forum: Google [Bot] and 3 guests