From the original SynthMaker forum (2004–2014), with its members’ names and dates.
martinvicanek ·
I added a Hann-like window function to the FFT Display module. Here is an illustration of what it does:
Basically you get rid of the side lobes, at the expense of resolution.
Tech question: is there a smart way of generating (green) custom arrays in SM? For example a Hann window function would be a[n] = sin^2(Pi*n/(N-1)) I tried to assign such array elements one by one but even with tick100 it takes ages.
Oh, here is the OSM! 🙂
trogluddite ·
martinvicanek wrote: I tried to assign such array elements one by one but even with tick100 it takes ages.
Yes, you can use the 'Integer Loop' primitive - that one will do the loops as quickly as the calculations can be done. Also, you only have to fill the array once when building the schematic - if you store the array into a 'Float Array Sample and Hold' primitive, the array contents are preserved when you save the schematic (or do an export) - no need to re-calculate them every time the schematic is loaded, and the looping part can be 'Purgable' for a smaller export size & quicker loading times...
You could even have a selection of different arrays all pre-calculated for different window shapes and sizes.
martinvicanek ·
Many thanks Trog, you are amazing! How can you have a complete solution ready with a neatly arranged OSM so quickly?
You could even have a selection of different arrays all pre-calculated for different window shapes and sizes.
I considered that as a last resort. May not be such a bad idea, though I'm not sure about the export size then. On the other hand, the Integer Loop seems fast enough to calculate the array when needed.
On another note, if the Integer Loop primitive sends a trigger at each iteration step, would that not provide a way of building a fast (>100) ticker? 😉
infuzion ·
martinvicanek wrote: Many thanks Trog, you are amazing! How can you have a complete solution ready with a neatly arranged OSM so quickly?
Trog keeps a laptop in his utility belt.
Green data only goes so fast, unfortunately.
edit: Ooh man, thanks for your module Martin! I think your solution using the "Float Array Selection" is best if you expect the user to change the Window Size often. Another trick to prevent constant recalculation is to place a Sample And Hold after a set of calculationsyou do not need to be re-ran every second, like in the diagram below. Watch link order; the trigger needs to be last.
trogluddite ·
martinvicanek wrote: On another note, if the Integer Loop primitive sends a trigger at each iteration step, would that not provide a way of building a fast (>100) ticker?
Yes, as infuzion points out, the speed is still limited by whatever calculations have to be done within the loop. Also, there is significant CPU used by the system that keeps track of the triggers as they flow around the schematic - so ultra fast triggers would lead to a really big CPU load very quickly. (Note that Green and GUI CPU doesn't show on SM's CPU meter - it only shows stream and code CPU use - Windows Task Manager is a better guide to the total).
infuzion wrote: martinvicanek wrote:Many thanks Trog, you are amazing! How can you have a complete solution ready with a neatly arranged OSM so quickly?
Trog keeps a laptop in his utility belt.
He he, maybe I should get out of the house more? 😀 Today's top tip for speedy .osm construction - using a graphics tablet rather than a mouse you can really fly through making links.
martinvicanek ·
Thanks, Infuzion and Trog for sharing your insights. Meanwhile I have succeeded in generating some 1000 ticks per second however at the cost of heavy CPU load, exactly what Trog predicted. My motivation was to build a low-latency trigger from stream data, e.g. to trigger MIDI notes from a (suitably processed) audio signal. The solution below is just not responsive enough.
A fast ticker would only be needed to drive the M2F primitive, so that should not generate so much load?
infuzion ·
For sample-accurate MIDI data, the entire green system in SM needs to be revamped. There was a beta for that, like 4-5 years ago, then disappeared. I'd expect that upgrade to SM about when we have a permanent base on the moon. Maybe even Mars.
trogluddite ·
It is a shame that there is no solution on the Horizon. I would settle for even just a sample-rate primitive that hooks into the MIDI driver ('Stream MIDI Event') - that would at least give us a workaround that the hard-core coders could build more 'user friendly' solutions around. I am getting some good results by doing stream-to-MIDI conversion externally (see Thread) - it's low CPU and sample accurate, but means that the plugins will only ever work in the intended 'target' environment (Reaper for my system, Nix has something similar using MAX/MSP). OK for personal projects, but no way viable for creating anything commercial.
rl ·
...just for fun. Here is another way to calculate the window:
martinvicanek ·
Nice! Thanks rl! 😀
martinvicanek ·
This has become my standard FFT analyzer. It offers a selection of popular window functions and allows to select the number of samples from the GUI. There is also an ( 😊 unlabeled) knob which controls how fast the device will respond - handy if you're testing with white noise. Feel free to improve.
infuzion ·
v1.1 + reduced code & some triggers (I'm not great at math, but I'm sure h+0=h) + 5FPS (33% of CPU) & 25FPS (-0% CPU?) options + Update Now trigger-In + Update Now anytime (useful if in CPU saving 5FPS mode & need faster changes temporarily) + Update Now now actually flushes (sends a stack of triggers) out most of old history kept by the LP filter (test: flip from Sawtooth to Sine) - moved GUI around
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker