Great work, Cytp - the addition of the peak and DC readouts is a masterstroke.
cyto wrote:I added a couple lines into the code that manipulates when the sampled values are being assigned to the exported arrays
This is looking like a very interesting technique - though there are still some mysteries that I haven't quite got my head around yet! I'll stick my neck out and see how I'm doing so far...
44100/256 = 172.5Hz - so blocks of 256 samples can be generated much faster than ticks.
There is no explicit "signalling" between the code and the mono to graph - the code does not know when a tick has happened, nor a frame drawn - and the ticker does not know any of the code's variable values.
From which I deduce...
There is an implicit "frame size" for the receipt of triggers from the windows timer (ticker) - triggers to the 8*Graph can only occur at 256 sample boundaries. Indeed if count1 is loaded with a non-zero value in stage(0), the whole graph is "rotated" - but never drifts.
Effectively the routine that reads the windows timer, and generates triggers from it is using a hop(256), synchronised to the sample sample counter (ecx) used for all other hops.
Your buffer is filled at the desired rate (appropriate to the zoom) - and the reading out is a continuous loop at sample rate, but (here I am completely guessing!) the clock for this is advacned/retarded based on the write index.
This is a real revelation to me - not only is your scope fantastic (the "analytical" complement to my "low CPU, but sketchy" version) - but I think that you have discovered something really fundamental about the inner workings of SM that I have never seen before.