Solution: more predictable tick100's

[wlangfor@uoguelph.ca]

I like Ruby, and i find the ticks defined by Ruby are nearly perfect; I used aronb's average tick tester and compared to the primitive version, which seems way too fast.
Instead of being 0.1, it's 0.01 in speed if you do the testing which made Me realize, there was another option available due to some volatility when ruby ticks are connected to anything using a considerable amount of memory.

And now I use a ruby custom tick set at 0.1 and have it send its tick: to a max tick module designed by another flowstone or synthmaker programmer (for the benchmarking, not for the source tick to be limited). By utilizing this max device, I can then rely once again on the primitive tick (which I had employed for a visual meter mono(4) to graph array prim). And the primitive tick does not create the same unstable peaks and spikes in CPU usage.

For instance, when relying on ruby, I was getting an extra 4% in spikes intermittently, but with this method maybe only 0.25 - 0.5%.
For those developers who are watching their CPU use in schematics; I highly recommend employing this method.

Tomorrow I will provide a schematic showing how it is done. Thanks again to AronB and to the synthmaker user who made the max triggers module, very intuitive!

actually - I was able to get a primitive down to 98 - 103 hz all the time. I'll post the method tomorrow.

[wlangfor@uoguelph.ca]

Here's the fsm for more predictable tick100's.

It stays at 96-97 in flowstone 0.6-0.8 and about 100 in the alpha.

DSPplug tick100.fsm

(31.44 KiB) Downloaded 779 times