High-resolution oscilloscope

[aliasant]

Been working on the zoom but Im banshing my head severly now.
Got it working in steps by changing the divide factor that goes into the MinMax

Also changed it from 8 strems to 16 to get a bigger window.

if someone can fix the zooming that would be wonderful
It needs stepless transitions so that the zooming is stepless.

aliasant Wavedraw 2c.osm

(183.93 KiB) Downloaded 77 times

LOL
Didnt realise that you MISSED the 2, 4 and 8 mono-graph prims!
You of all m8 !

[cyto]

Okay. After looking over trog's wonderful bitmap rendering thingy, I made a few (I hope) positive changes to this thing. I redid the peak detector. I was certainly over-thinking it in the earlier version. This new one doesn't have all the unnecessary "smoothing" filters in it. It simply just captures the max and min of the given range. I also rethought the "scrolling silence" mechanism (as it could potentially start to accumulate after long bouts of silence). So basically there is a little "switch" in there that alternates between +1 and -1 each time the values are captured. This switch gets sent to its own m2f which triggers the updates on the capture m2fs. I didn't dare go in and touch the bitmap generator, but I did make it so the whole module is scale-able and the capture timer should only trigger when a new pixel is actually needed. I'm sure there is plenty more to do, but this may be a more usable solution than the previous versions.

CytoScopeScrollerV2.osm

(25.84 KiB) Downloaded 81 times

-cyto

[aliasant]

Not sure about yours Cyto.
It doesnt behave as expected or?
Timing seems quite off.

Check this out just to see what it could look like but use a test osc instead. Then you can really see if it draws the waveform ok.

I fixed a "bug" with the whole zoom function. Seemed the Hop value in the first piece of code needs to correspond with the Div Factor ( 8, 16, 32 and so on).

aliasant Wavedraw 2d.osm

(210.92 KiB) Downloaded 73 times

[cyto]

Not sure about yours Cyto.
It doesnt behave as expected or?
Timing seems quite off.

Yeah, you're right. I didn't notice it when working on my 3GHz quad-core machine, but after testing on the old netbook, there certainly is a timing issue. The timing discrepancies are definitely apparent with smaller window sizes (ie. less than 10sec - I'm sure this is a trigger issue). It seems our two version compliment each other: Yours is significantly more precise (both in display and timing) but is limited to shorter windows (?) whereas mine seems better at handling longer windows (potentially several minutes or more) at the expense of precision. Perhaps there is a happy medium to be reached?

-cyto

[aliasant]

Not sure about yours Cyto.
It doesnt behave as expected or?
Timing seems quite off.

Yeah, you're right. I didn't notice it when working on my 3GHz quad-core machine, but after testing on the old netbook, there certainly is a timing issue. The timing discrepancies are definitely apparent with smaller window sizes (ie. less than 10sec - I'm sure this is a trigger issue). It seems our two version compliment each other: Yours is significantly more precise (both in display and timing) but is limited to shorter windows (?) whereas mine seems better at handling longer windows (potentially several minutes or more) at the expense of precision. Perhaps there is a happy medium to be reached?

-cyto

I wish

There might be a way to get as big a window as you like but with no delay and that is to pursue Trogluddites idea of a scrolling bitmap perhaps combined with my way.

You would need a small window, maybe just 1-4 ( mine currently has 16) streams and after the window has rendered the array, take a snapshot of that and save to a bitmap that you then start scrolling 1 pixel to the left / trigger and at the same time you scroll in the newly rendered window from the right at 1 pixel / trig.

I think you could just keep adding bitmaps til your entire frame is covered.

Trogg PLEASE Help us with this ( Maybe your already cooking for us? Smooking and puffing like the mad scientist... in the dark basement far from any distracting affections like long necked guitars and what nots...)

[tester]

@cyto - on my C2D 2GHz it shows less than 4% usage on your longviews (both versions), so is the timing on second attempt/code - a matter of CPU?

I'm curious how your version evolves into properly working long waveview, because your approach produces small and efficient (not complicated) schematics. Could you take some time on that? Stereo/dual synced version would be nice. I noticed some display-related bugs in first version, but I'm sure you noticed them too.

[trogluddite]

there certainly is a timing issue... ...ie. less than 10sec - I'm sure this is a trigger issue)

I've had a quick look, and I'm pretty sure that you are right about the triggers.
For a 10s window, the sample block size is just over 1000 samples - so the output values are changing at around 40Hz.
Even on a powerful system, a Tick100 rarely manages more than about 60Hz, and this drops dramatically when the CPU is stressed - eventually to the point where you can't guarantee that there will be a trigger during the ~25ms window between value updates. On my 'baby' Atom powered machine, the 'jerky' movement of the display is obvious without even needing to use a 'test signal'.
A larger window size (as you point out) reduces this problem - but the limit of resolution is rather arbitrary as we can't predict what machine the end-user might have.
So a system is needed to cater for the possibility of more than one data point per trigger - kind of like a 'low resolution' version of aliasant's system.... (see below)

Trogg PLEASE Help us with this

He he, thanks for the vote of confidence! Have a lot of boring chores to do today, but for the problem above, I think there may be a solution similar to what I use in my older 'CRT scope' schematic. It works something like this...

1) Write the detector output value into a 'mem' using a Wave Write and pointer.
2) When a trigger does make it through the M2F, convert mem->array..
3) Also read the array index (M2F), use this to truncate the array and to know how many pixels to scroll.
4) Draw the truncated graph and scroll.
5) Send a flag to the detector code to tell it to reset to index zero of the mem.

But this still leaves a problem... some samples may pass before the 'reset' flag is seen by the code (it can't be sent until the mem to array operation is done, and green->stream is not sample synchronised). This is why my earlier 'CRT scope' schematic uses two alternating (and slightly overlapping IIRC) buffers. TBH, it's so long since I made that, that I can't quite remember the logic that I used, but I will try to take a look and see if it can be adapted (and hopefully improved).

I think that by juggling the detector block size and the mem array size, this might make a good start for a "dynamic" system. You would be able to juggle between the Draw Graph doing most of the work (to show detail), and the 'scroller' taking over when 'zoomed out' to the the long term 'envelope' - and using Cyto's "block" method should mean that scrolling is always in whole pixels, getting around the 'anti-aliasing' fuzziness problem that I had when I tried this before.

[trogluddite]

OK - Here's a first rough attempt at bringing together everyone's ideas so far...

Scrolly Scope 01.osm

(96.41 KiB) Downloaded 95 times

After some thinking, I realised that the stitching together could be done using a single circular buffer.
Here's a quick description of what's happening...

1) Min, Max detector similar to Cyto's - finds the min-max for a block of samples; each block to be represented by one pixel width in the display.
2) Mins and Maxes are stored to a psuedo-circular buffer (mem)
3) Ticks can come in at any arbitrary rate - if there is no new block since the last trigger (i.e. index not changed), there's no change at the M2F that reads the buffer index, and that trigger will be skipped because there is no new information to display.
If there is new information...
4) Convert buffer into a float array
5) Extract from the array only the new data (between the last index read and the current one)
6) Scroll the bitmap buffer by the number of new data points since the last animation frame
7( Draw the new data at the right hand side
8) Capture a new bitmap buffer for the next frame.

There are a few "fiddle factors" here and there - these were added to make 'slices' overlap by one pixel - there are two reasons why the overlap is needed.
- To avoid weird vertical lines in the display - the graph draw does not seem to quite fill the given area.
- Draw Graph must be given at least two data points - a single point draws nothing as the graph module draws lines, and a line must have two ends!

CPU seems reasonable - at the uploaded size, I get about 3-4% CPU on my Q6700. The animation is still a little 'lumpy' - the size on screen seems consistent (1px per sample block), so I think it is just due to the need for scrolling in whole pixels that makes the movement a little uneven.

EDIT) Tested on my Atom netbook also - works just as effectively for about 25-30% CPU.

[aliasant]

Nice work Trog!
I knew you could do it!

On my new machine cpu usage is around 0

One anoying thing is the need for drawing the Min and Max seperatly getting that line at zero
In mine I convert the -1 to +1 range to 0-1 and then back again before the Draw.
Tried to do this with yours but I couldnt get that to work.

Its also a bit choppy if you use say 10000 Samples per Pixel.
Thats probably something that needs a fix if possible at least for those who wants to use it for long big fancy windows.

Its perfect for me though, not needing them long times.

[trogluddite]

Its also a bit choppy if you use say 10000 Samples per Pixel

Damned nit-pickers!

Scrolly Scope 02 SupaSlow.osm

(106.78 KiB) Downloaded 91 times

Re: Min and Max graphs
I think there are two different approaches here depending on the time scale...

-For the long-time - the max and min are essential to be able to see the upper and lower limits over a period of time (sound envelope)
-For short-time (i.e. looking at wave shapes) you just want to see the value of the samples (likeyour method with the mono to graphs) - so min/max is probably not so useful. A better way might be to find the average (or max absolute amplitude) for the block of samples - then have only mono mem - one array - one Draw Graph; so that there is only a single line.

NB) the little 'seam' at the centre line is another effect of the Draw Graph not filling the area completely that I mentioned in the other post - maybe another of SM's strange anti-aliasing artefacts (or maybe anti-aliasant?! )

[aliasant]

Its also a bit choppy if you use say 10000 Samples per Pixel

Damned nit-pickers!

Scrolly Scope 02 SupaSlow.osm

hehehe

Thats my speciality! and you know what?

It works.

You fixed it!. I didnt think it was possible even but you did it in what? An hour?
Amazing. This works GREAT!!! Thanx m8

[aliasant]

Heres a PIMPED version with a Zoom control

[trogluddite]

My turn to nit-pick!

Can you re-up your pimped scope with audio disabled - I can only download onto my Atom machine (big machine is not online) - CPU freezes when SM tries to load the toolbox while audio is running on your schematic.

PS) Crossed lines! - see my previous post for edits I did while you were posting.

You fixed it!. I didnt think it was possible even but you did it in what? An hour?

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

[aliasant]

You deserve a full box of Obans!
That is if you do the single malts..

Heres a pimped version with no audio in or out.
The last one had only a ASIO out but it was not active. Odd.

Edit:

Reread your post now.
Would be nice to have a switch to go between Min/Max and Average perhaps?
Im still amazed at the speed you did this in.

When you were working on the goniometer I was trying to achieve this but failed since I simply dont understand the whole buffer thing but i did get something that looked like it could have worked. I, as many here, do SM in periods and I think I started that at an end of a period. Typical... And again. You did it in the same time it takes me to boot my pc and get some coffe..

[philter5]

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