High-resolution oscilloscope

Hints, tips and discussion about graphics and user interface elements

Moderators: electrogear, exonerate

Re: High-resolution oscilloscope

Postby tester on Fri Feb 24, 2012 9:40 pm

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?
Need to take a break? Looking for relaxing sounds? I have something right for you.
(by purchasing, you are also supporting further development of related projects).
Thank you for your contribution.
tester
smanatic
 
Posts: 765
Joined: Wed Jan 18, 2012 9:52 pm
Location: Poland, internet

Re: High-resolution oscilloscope

Postby cyto on Fri Feb 24, 2012 10:54 pm

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 217 times

-cyto
User avatar
cyto
essemilian
 
Posts: 317
Joined: Sun Nov 28, 2010 4:36 am
Location: CIN | OH | USA

Re: High-resolution oscilloscope

Postby trogluddite on Sat Feb 25, 2012 12:21 am

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

trogluddite wrote:See posting times! Boy am I quick today 3:) - think I deserve a beer or two..

...not after this many beers! >:(
Feel free to use any schematics and algorithms I post on the forum in your own designs - a credit is appreciated (but not a requirement).
Don't stagnate, mutate to create. Without randomness and serendipity the earth would be just another barren rock.
User avatar
trogluddite
smychopath
 
Posts: 3033
Joined: Mon Oct 20, 2008 3:52 pm
Location: Yorkshire, UK

Re: High-resolution oscilloscope

Postby aliasant on Sat Feb 25, 2012 10:01 am

cyto wrote: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 205 times
It's never to late to be late.....
http://martinrodensjo.smugmug.com/
User avatar
aliasant
smunatic
 
Posts: 2388
Joined: Sat Dec 30, 2006 5:49 pm
Location: Sweden

Re: High-resolution oscilloscope

Postby cyto on Sat Feb 25, 2012 7:41 pm

aliasant wrote: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 ;)
User avatar
cyto
essemilian
 
Posts: 317
Joined: Sun Nov 28, 2010 4:36 am
Location: CIN | OH | USA

Re: High-resolution oscilloscope

Postby trogluddite on Sun Feb 26, 2012 12:54 pm

Hmmm, without understanding the assembly block, it is hard to be certain, but I'm not yet convinced that this is trigger related...
cyto wrote: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.
Feel free to use any schematics and algorithms I post on the forum in your own designs - a credit is appreciated (but not a requirement).
Don't stagnate, mutate to create. Without randomness and serendipity the earth would be just another barren rock.
User avatar
trogluddite
smychopath
 
Posts: 3033
Joined: Mon Oct 20, 2008 3:52 pm
Location: Yorkshire, UK

Re: High-resolution oscilloscope

Postby cyto on Sun Feb 26, 2012 9:07 pm

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
User avatar
cyto
essemilian
 
Posts: 317
Joined: Sun Nov 28, 2010 4:36 am
Location: CIN | OH | USA

Re: High-resolution oscilloscope

Postby cyto on Wed Feb 29, 2012 3:55 am

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.

scopeCapture.png
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 2386 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 223 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
Last edited by cyto on Fri Mar 02, 2012 1:49 am, edited 1 time in total.
User avatar
cyto
essemilian
 
Posts: 317
Joined: Sun Nov 28, 2010 4:36 am
Location: CIN | OH | USA

Re: High-resolution oscilloscope

Postby nix on Wed Feb 29, 2012 4:07 am

mighty work,
I'll remember u guys have developed this,
ty!
User avatar
nix
smaniac
 
Posts: 1173
Joined: Wed Nov 02, 2005 11:25 am
Location: Australia

Re: High-resolution oscilloscope

Postby aliasant on Wed Feb 29, 2012 7:05 am

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 ;)
It's never to late to be late.....
http://martinrodensjo.smugmug.com/
User avatar
aliasant
smunatic
 
Posts: 2388
Joined: Sat Dec 30, 2006 5:49 pm
Location: Sweden

Re: High-resolution oscilloscope

Postby cyto on Wed Feb 29, 2012 7:21 am

aliasant wrote: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
User avatar
cyto
essemilian
 
Posts: 317
Joined: Sun Nov 28, 2010 4:36 am
Location: CIN | OH | USA

Re: High-resolution oscilloscope

Postby aliasant on Wed Feb 29, 2012 7:26 am

cyto wrote:
aliasant wrote: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?
It's never to late to be late.....
http://martinrodensjo.smugmug.com/
User avatar
aliasant
smunatic
 
Posts: 2388
Joined: Sat Dec 30, 2006 5:49 pm
Location: Sweden

Re: High-resolution oscilloscope

Postby tester on Wed Feb 29, 2012 10:25 am

Impressive!
Need to take a break? Looking for relaxing sounds? I have something right for you.
(by purchasing, you are also supporting further development of related projects).
Thank you for your contribution.
tester
smanatic
 
Posts: 765
Joined: Wed Jan 18, 2012 9:52 pm
Location: Poland, internet

Re: High-resolution oscilloscope

Postby cyto on Thu Mar 01, 2012 2:32 am

aliasant wrote: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 186 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
User avatar
cyto
essemilian
 
Posts: 317
Joined: Sun Nov 28, 2010 4:36 am
Location: CIN | OH | USA

Re: High-resolution oscilloscope

Postby aliasant on Thu Mar 01, 2012 9:41 am

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....
It's never to late to be late.....
http://martinrodensjo.smugmug.com/
User avatar
aliasant
smunatic
 
Posts: 2388
Joined: Sat Dec 30, 2006 5:49 pm
Location: Sweden

PreviousNext

Return to Graphics

Who is online

Users browsing this forum: No registered users and 2 guests