High-resolution oscilloscope

[tester]

Thanks, nice designs. Yet in multichannel (tested on stereo) mode those fellows still don't sync best; is not bad, but not refresh irregularity is not "as one".

I would see another solution here, which should solve a display/refresh problem. Switching between "live srolling" and just "redrawing" the time window (when the wave reaches it's end). Thus - there should be no motion related flickering.

I don't know whether redrawing the scope is designed for the whole scope screen (this schematic is still beyond my comprehension), but in redrawing mode - redrawed could be only one vertical line at the time (plus some vdrtical separator), and not the whole scope screen, thus there would be no flickering at all. What do you think about such direction?

[cyto]

Ha! Awesome work trog and aliasant! While you two were having at it, I was coming up with my own take on the issue. I post it here for completeness. It certainly doesn't have all the advanced bitmap trickery as yours. I went back to just a plotted array like SMs scope. I, too, went the circular buffer route but instead of having all those complex write/read things, I kept mine inside the asm box. Oh well, here it is for those interested, though it looks like it was obsolete before it was made

(though, I think mine is more lightweight and the zoom might be smoother )

CytoScopeScrollerV3.osm

(36.08 KiB) Downloaded 111 times

-cyto

[trogluddite]

...i bet trog´s brain is equipped with the newest-high-tech 64core processors

See posting times! Boy am I quick today - think I deserve a beer or two..

...not after this many beers!

[aliasant]

Ha! Awesome work trog and aliasant! While you two were having at it, I was coming up with my own take on the issue. I post it here for completeness. It certainly doesn't have all the advanced bitmap trickery as yours. I went back to just a plotted array like SMs scope. I, too, went the circular buffer route but instead of having all those complex write/read things, I kept mine inside the asm box. Oh well, here it is for those interested, though it looks like it was obsolete before it was made

(though, I think mine is more lightweight and the zoom might be smoother )

The attachment CytoScopeScrollerV3.osm is no longer available

-cyto

Thats pretty nice. Very simple and effective design.

I just placed yours, Trogs and mine ( clearly inferior ) versions next to eachother and set their zooms so that the sync with eachother.

Mine is very limited by fixed times even though Im sure i could make the max window at least twice the sice without loosing to much performance but it does render a detailed wave. I could probably fix the zoom so that it works smooth as yours too but why waste time on something you guys already fixed in such genious ways?

Edit: Forgot to mention that mine has serious redraw problems were it cancels out the waveform at certain frequencies... Not very good eh?


Cytos seems to have a redraw glitch though. Might be fixed by finetuning the buffer size or similar or maybe use a dirty fix by extracting only a section from the final farray. Simply skip the first say 16 samples from the array? ( I had to try that and it seems to work perfect)

Heres that .osm if anyone is curious. I included that small glitchfix on Cytos.

3 wavedisplays + Cyto fix.osm

(188.47 KiB) Downloaded 108 times

[cyto]

Cytos seems to have a redraw glitch though. Might be fixed by finetuning the buffer size or similar or maybe use a dirty fix by extracting only a section from the final farray. Simply skip the first say 16 samples from the array? ( I had to try that and it seems to work perfect)

I'm afraid it might be a little more complicated than that. I know because I've been working on stretching this thing a little further (why? I have no idea). When you get to very short window sizes, the glitch becomes even more apparent. Arrrgh!

-cyto

EDIT: I'm convinced now more than ever that this is a trigger issue. I think the glitch is an old (or a new) "shift" factor finding its way into the graph (if that makes sense). In one of my little "splinter" projects from this, I had the trigger line going to the redraw in between (in connection order) some graphs and said glitch was even more pronounced (and misaligned graph-to-graph). Fixing the connection order at least lined up the "glitch" but didn't remove it. If there were a way when dealing with the tick primitives to only allow a new tick trigger once the previous trigger has completely propagated the schematic (or definitely gotten to a certain point, say the redraw primitive), I think this could be worked out. Perhaps a certain Trigger Master might chime in

[trogluddite]

Hmmm, without understanding the assembly block, it is hard to be certain, but I'm not yet convinced that this is trigger related...

only allow a new tick trigger once the previous trigger has completely propagated the schematic (or definitely gotten to a certain point,

AFAIK, there is no way around the default behaviour - "pending" triggers are held in a queue until the schematic is free to service them. So using a trigger blocker etc. as a 'gate' would serve no purpose as (from the gate's point of view), the waiting triggers haven't arrived yet and there is nothing to block. The gate would then be opened for new triggers at precisely the time that the schematic becomes free to take the next trigger off the queue anyway.
So the system already works the way that you suggest with one critical difference - new triggers are queued while the schematic is busy rather than being dropped. OutSim have obviously made the decision (correct IMHO), that this is the right behaviour most of the time - otherwise MIDI input could go missing, and sequential logic would be highly unpredictable.
Which makes me think now - is this the purpose of the "ReDraw Limiter" primitive? It has often mystified people that, although it does prevent triggers when the plugin window is closed etc., it doesn't actually seem to reduce the trigger rate very much (certainly not to a sensible animation frame rate). But maybe its purpose it to do as you describe - to ensure that any currently pending ReDraws are complete before allowing a new one to be intiated - thus avoiding the build-up of a large trigger queue (maybe through some sort of feedback from the GDI graphics engine) - might have to contact Malc about that one.

Anyway, back on topic - we can easily test if "queuing triggers" are the problem with your schematic - remove the ticker, and replace with a manual trigger button. This ensures that we are only seeing the effect of a single trigger free from any "trigger queuing". The 'glitch' still remains.
All of the array primitives used are discretely triggered - they are all ones I have tested quite thoroughly, so I am quite certain that...
- Changes at the primitives' array/integer inputs do not cause a recalculation of any arrays.
- They do not respond to or propagate "reverse triggers"
Checking with a trigger counter also does not show any unexpected duplicate triggers - and the trigger order seems to be right. I experimented with other orders too, but apart from putting the redraw between the two graphs (with the expected "offset" between them), the results were always the same - a slightly random offset to the wrap-around of the wave.
So my suspicion is that somehow the code/mono2graph combo is not generating the correct index for the 'wrapping' of the waveform - though I dont understand the code block well enough yet to say that with any certainty.

[cyto]

Thank you, trog, for replying. Your insight is always very much appreciated. In hindsight, my (false) Eureka moment was definitely premature. Unfortunately, my obsessive/compulsive tendencies are keeping me down in this rabbit hole much longer than I probably should be. While the rest of the world moves on, I'll be fine-tuning shift factors.

-cyto

[cyto]

I had a chance to revisit this little guy tonight and and happy to report that I have solved my "glitch" problem. Instead of shifting whole blocks of data in the external arrays, I added a couple lines into the code that manipulates when the sampled values are being assigned to the exported arrays. While in there, I added a few functions to the module that don't really add any overhead but might be nice to have for analysis...

1. Ability to morph in between "envelope" graphs and "signal average" graphs (so it is equally effective at 5ms windows as it is at 15 minute windows).
2. Pause. While paused the graph is still accumulating data so that when you un-pause, there is no interruption in the display. Additionally, while paused you can export a graphic file of the scope readout (in fact, that attached png was generated by doing just that).
3. Readouts of peak values in the display (dBFS) as well as dc offset of the graphed signal.
4. Oh yeah, this is a dual-scope version, too.

this was captured after a fast "zoom out" so you can see how the scope shows different zoom factors. Yellow is average and cyan is envelope.

scopeCapture.png (20.3 KiB) Viewed 1333 times

Let me know what you all think. If anybody wants me to expound on how to access the asm memory buffers without having to rely on those read/write modules, I'd be happy to do so (this scope relies heavily on that little trick).

superScope.osm

You can make a bunch of settings from the Properties Panel.

(62.88 KiB) Downloaded 129 times

WARNING: this current version ONLY works in environments that have an ASIO buffer size of at least 256 and a whole number multiple of 256 (ie 256, 512, 768, 1024, etc.) Has NOT been tested with the Direct Sound output. See the rest of the thread for discussion of why this is.

-cyto

[nix]

mighty work,
I'll remember u guys have developed this,
ty!

[aliasant]

Cyto.
Thats quite nice!

I have a request.

Could you change it to use 1024 instead of 256?
I tried and failed but the code is not that easy to read

[cyto]

I have a request.
Could you change it to use 1024 instead of 256?

Yeah, the code is a bit cryptic. I didn't want to bore everyone with the inner workings. Lots of inter-dependent incrementors (like the gears of a clock). I'll see what I can do about expanding it to 1024. I can't make any promises. 256 is kind of the "magic number" to sync the internal arrays with the mono to graph captures. I might be able to use some of the delay techniques from your examples to accomplish it, though. Let me see what I can do.

-cyto

[aliasant]

I have a request.
Could you change it to use 1024 instead of 256?

Yeah, the code is a bit cryptic. I didn't want to bore everyone with the inner workings. Lots of inter-dependent incrementors (like the gears of a clock). I'll see what I can do about expanding it to 1024. I can't make any promises. 256 is kind of the "magic number" to sync the internal arrays with the mono to graph captures. I might be able to use some of the delay techniques from your examples to accomplish it, though. Let me see what I can do.

-cyto

Cryptic but brilliant

I was under the impression that 1024 was the magic number for stream to float stuff.
That 1024 is somehow the "native" size that works faster and it would also give a higher resolution especially if you upsize the window to see better?
Maybe a bigger chunk means a chunkier zoom as well and that might not be so good?

[tester]

Impressive!

[cyto]

I was under the impression that 1024 was the magic number for stream to float stuff.
That 1024 is somehow the "native" size that works faster and it would also give a higher resolution especially if you upsize the window to see better?
Maybe a bigger chunk means a chunkier zoom as well and that might not be so good?

You had me second guessing myself! But after doing a few more experiments, I think I can confidently say that 256 is the magic number. Here is a quick demonstration...

sizeTests.osm

(4.16 KiB) Downloaded 86 times

Read the little notes in there about what's going on and what to look for. Unless I'm missing something (which I very well could be), you can only be 100% certain of the mono to graph captures when the data is exported in cycles of 256 samples. Now, you could very well send multiple (parallel) blocks of 256 samples out, somehow "tagging" them as to their position and reconstruct the data blocks in green (which is probably what would need to be done to expand this scope to 1024).

Let me know if that demo makes sense and if you can shed anymore light on this (as I'm just beginning my experiments in this type of data manipulation).

-cyto

[aliasant]

Cyto.

That was a very interesting experiment!
That it locks to the right side is indeed quite unexpected as well.

This is perhaps related, like a distant cousin, to my own little "trick" of setting my test oscillator to 187.5hz when Im viewing signals.
At that frequency (or multiples of that like 375Hz, 562.5Hz, 750Hz...using a samplerate of 48kHz) the oscilloscopes signal is frozen perfectly, just as your experiment shows. That trick is samperate related. If I change my samplerate from 48kHz to 44.1kHz I loose the "sync"

That is not true with your signal test BUT.
Im betting your using a samplecard buffer of 256 ?
If you change it to some odd buffer like 192 you will loose the sync and again, if you change it to 1024 you will have perfect sync on the 1024 ramp and the 256 ramp.

It seems that you need bigger buffers to get less flickering....