High-resolution oscilloscope

[vinxz]

Hi everybody,
I'm working on a synthmaker design which purpose is to create a high-resolution oscilloscope to observe waveforms, and especially slow-evoluting waveforms (such as modulated by a LFO, etc.)
I'd like as well, to have the trace writing in quasi-realtime from left to right.
I tried to sample the signal with a tick 100, but it's not precise enough...
I attached my design. It's nearly working, but I'm losing some buffers and some buffers are repeated... Can someone explain me what's happening ?
Thanks..

[trogluddite]

Hi there vinxz, welcome to the forum.

I wasn't able to look too far into your schematic - my internet machine only has an Atom CPU and couldn't handle it - but the problems you are having are not uncommon with SM...
Basically it is down to the way that streams (blue/white 'audio' links) and triggered data (the green/yellow bits) work - although they do obviously 'speak' to each other, there is no timing synchronisation between them, so it's not possible to create a 'chain' of data blocks that will join end to end properly.

The stream parts are easy to understand - everything happens once over for every sample, and the timing is as accurate as the sample clock in your soundcard.
Green parts, however, rely on discrete 'triggered' events - and in order not to interrupt the audio too much, have a relatively low CPU priority.. For example, a tick100 never (as far as I have seen) generates 100 triggers per second - and the rate will drop as your CPU works harder. The interval between triggers cannot be guaranteed, except for incoming MIDI events. For a better explanation of triggers, take a look at the Triggers Tutorial HERE.

Added to this is the problem that manipulating the buffered samples (float arrays and graph drawing) tends to hog the processor a while (SM tries to calculate the entire array during the time period of one sample) - so each screen drawing event makes a big spike in CPU power - further reducing the timing accuracy.

However, all is not lost - I too wanted a nice 'CRT style' scope for just this kind of long term audio monitoring - you can find the schematic HERE
It can manage multiple traces, fitted to the display any way you like - but the waveform scaling is arbitrary, so (as yet) not useful for taking absolute readings.
The timing problems I mentioned above are got around by having two overlapping buffers, and some code that keeps track of the buffer pointers when switching between them - it also uses the trick of storing previously sampled values as a bitmap 'snapshot' of the screen, which helps with the CPU hungry graphics calculations.
The wiring is probably a little bit too chaotic to understand easily, and there is much that is written in code and assembly - but I'd be happy to try and answer any questions you post.

Happy SM'ing
The Luddite

PS) One other little tip - your file opens with the audio in/out turned on - which made for screaming howlround between the crappy speakers and mic on my netbook. In some cases, it can also crash user's machines if they happen to have lousy DirectSound drivers. So it's a good idea to post files with the audio turned off to save any nasty surprises.

[tester]

So - there is no "wave display" in a way that you get in any DAW? I'm asking, because I work with slow LFOs too, and to make adjustment right - I need a few secods view of wave window, like EKG or somegthong like that.

Partial solution would be to use cool edit or something like that, because it can display "on the fly" what is being recorded (and it can record what is on playback from other app).

[infuzion]

Heartbeat with about 20FPS should work fine.

[aliasant]

Try this as an idea.
Something I made a long time ago but I had a quick look at it and its not that bad.
It has glitches though.

basicly it divides the incoming signal into 8 chunks using delays.
Then do FArray on all 8 and finally chain them back again.
It finishes with a resample down to get a smaller array to the draws.
That last part saves a lot of cycles redrawing.

Rough WaveDisplay needs work v1a.osm

(462.15 KiB) Downloaded 166 times

Would be interesting to see if anyone can fix this?

[vinxz]

Hi,
And first thank you very much trogluddite for your precious explanations & osm designs...Your work on Synthmaker is really impressive !
Actually, for some reason I really need to be able to do that in synthmaker, otherwise I would have done that in wavelab...
aliasant, I'll have a look at your design this afternoon, seems promising as well !

[trogluddite]

Would be interesting to see if anyone can fix this?

Buffering the 'old' samples is a great idea - but, sadly, also part of the problem ...

First an experiment...
When loaded, the gaps in the wave have a very definite pattern of alternate up and down steps.
Now try this...
Delete all of the trigger connections to the eight "mono to graph" primitives - remake those links in proper sequence from bottom to top (the trigger order was different to this in the original)

You should see that the waveform is now smoother, and all the gaps go in the same direction.

What is happening, is that each "Mono to Graph" takes quite a while to do its stuff - while this happens, the other ones have to wait before they can 'see' the trigger - so there is a delay of a few samples in between each M2Graph doing it's stuff. Hence the gaps - and why changing the trigger order changes the look of the graph, by putting those delays in a different order too.

Sadly, I don't think there is an easy way around this - it's the reason why the scope I made uses a complex "overlapping buffers" system. I've even had problems just getting two simple "mono2float" prim's to trigger simultaneously - the interface between green and stream works in a very odd way that is never truly synchronised. It's also important to remember that when you send a green trigger to lots of destinations, they are also not seen simultaneously - in particular, they can be delayed for many samples by large arrays calculations and loops.

Very annoying - it has put a stop to many nice graphics I'd like to do; making that 'scope was very tricky, and some more interesting things were too hard for my brain to find a work-around.

[tester]

Maybe someone knows how to make a code/ASM addon for making long-time wave display? I saw some talented users here, who could be able to make a really working piece.

One idea came to my mind. For certain needs - why to not delay a little bit the whole playback in order to make the display right?

[cyto]

Maybe someone knows how to make a code/ASM addon for making long-time wave display? I saw some talented users here, who could be able to make a really working piece.

One idea came to my mind. For certain needs - why to not delay a little bit the whole playback in order to make the display right?

Here's a quick little sketch that may put you in the right direction for a "long" wave display. Basically, it has two (positive/negative) peak detectors in it from which "snapshots' are taken at appropriate intervals. The response of the peak detectors is dependent on the interval between the snapshots. Those snapshots are then sent to a m2f primitive and take advantage of the fact that the m2f only sends a trigger when the value changes. These values are then pushed onto a float queue (actually two) that feeds the peak graph. It's a long way from being a fully fleshed out solution and I'm sure there are many things that could be improved. But it might get you going in the right direction.

longScopeIdea.osm

(24.95 KiB) Downloaded 158 times

BTW - if you open up the properties panel, you can set the length of the display as well as the resolution of the graph (Right now i think it's 10 seconds with a 256 sample graph).

-cyto

[trogluddite]

That's excellent stuff, Cyto - the use of the M2F "Automatic trigger reduction" particularly. (I've yet to completely fathom the peak detector code - but it seems to be very effective also).

I was just working on a version using bitmap scrolling rather than array storage - and the peak detection/M2F combo of your design happens to drop into mine rather well - solves problems I was having with making the scrolling smooth at a stroke!

Anyway, here's my version - it takes the output of your peak detector, and draws only a single line representing the current data point at the right of the display (no arrays needed), then scrolls using a bitmap buffer and transform.

CytoScope Scroller.osm

(27.47 KiB) Downloaded 172 times

This may not be so useful in some cases, I'm sure, as the wave data itself is not stored in an accessible way, and the window scaling is likely less accurate - but on my little Atom CPU mashine, it offers a useful reduction in CPU usage (about 25% compared to 40% for your design).
Quite why plotting 256 data points is more CPU intensive than encoding a bitmap still baffles me - and I'd be interested to know of those CPU savings translate well to other systems.

[aliasant]

That's excellent stuff, Cyto - the use of the M2F "Automatic trigger reduction" particularly. (I've yet to completely fathom the peak detector code - but it seems to be very effective also).

I was just working on a version using bitmap scrolling rather than array storage - and the peak detection/M2F combo of your design happens to drop into mine rather well - solves problems I was having with making the scrolling smooth at a stroke!

Anyway, here's my version - it takes the output of your peak detector, and draws only a single line representing the current data point at the right of the display (no arrays needed), then scrolls using a bitmap buffer and transform.

CytoScope Scroller.osm

This may not be so useful in some cases, I'm sure, as the wave data itself is not stored in an accessible way, and the window scaling is likely less accurate - but on my little Atom CPU mashine, it offers a useful reduction in CPU usage (about 25% compared to 40% for your design).
Quite why plotting 256 data points is more CPU intensive than encoding a bitmap still baffles me - and I'd be interested to know of those CPU savings translate well to other systems.

I have been looking at scrolling bitmap too and had something that worked so and so. It got the peaks and looked ok but the resolution was far from precise... to say the least.

Looking at your mod of Cytos i noticed that your using the trigger from the Mono to float as trigger for the draws and that means that it wont redraw if theres no change in the float after the mono to float...
Set a 25 tick or similar directly to the draw part works better..

Nice work!

[trogluddite]

Looking at your mod of Cytos i noticed that your using the trigger from the Mono to float as trigger for the draws and that means that it wont redraw if theres no change in the float after the mono to float...
Set a 25 tick or similar directly to the draw part works better..

Yes - I copied that pretty much from Cyto's original. If I understand the idea correctly, using the output of the M2F keeps the scrolling nice and even - e.g. so that each pixel always represents the same number of samples, because it only updates once the peak detector has analysed a complete block of samples.
But you are quite right - an unchanging value will not scroll, and maybe I have misunderstood the logic. Possibly adding an 'update now' output from the code could fix this, while also keeping the accurate resolution?
Cyto?

[aliasant]

I pursued my 8split farray version and this one actually works glitch free and smooth.

I havnt figured out the zoom function but at least it draws smooth and consitent even at high frequencies.
Im pleased but feel free to correct me

aliasant Wavedraw.osm

(164.17 KiB) Downloaded 197 times

[cyto]

But you are quite right - an unchanging value will not scroll, and maybe I have misunderstood the logic. Possibly adding an 'update now' output from the code could fix this, while also keeping the accurate resolution?
Cyto?

I haven't had a chance to look at the new versions yet (but I'm sure they quite put mine to shame), but I just wanted to pop in and say that in the code I wrote there is a little routine that prevents duplicate outputs. You should get a new value every time. Basically, it just tests the last value sent and if it's the same, it adds a very small amount (1e-036) to it.

-cyto

[trogluddite]

I pursued my 8split farray version and this one actually works glitch free and smooth.

Sure does!

Mono to Graph * 8 !- where did that spring from? - he he, been in my toolbox all along and I never saw him!
Guess it was added for FlowStone - for synchronised data logging etc. - and solves all the timing "bugs" I posted before so easy; will be useful in many other displays I wanted to make.

You should get a new value every time... ...very small amount (1e-036) to it

Aha, the mystery of "scrolling silence" is solved!