Scope understanding

[Drnkhobo]

hey guys can someone help explain this scope example?

Scope1.fsm

(213.73 KiB) Downloaded 1517 times

its a basic one but I want to know why it scrolls from right to left & how to slow it down (not with tickers). I know that it might be simple but you need to understand that i want to know how & WHY it works. So I can use and modify it.

Anyone?


Thanks

[trogluddite]

The first thing to understand is that the speed of the ticker will actually make very little difference here - so long as it is fast enough to give the illusion of movement, what you see would be pretty much the same whatever rate you choose for the ticks. (and not so fast that it gobbles up all your CPU power!)

The key to it is the little "Samples to show" box inside the scope module....
Each time there's a trigger, the Graph primitive grabs exactly that number of samples (the most recent ones of course) - which in this case is 1/4 of a second (assuming 44100 sample rate). These samples then get drawn to the GUI window - note; ONLY the samples that it just grabbed, it has no memory of what happened at the previous tick.

But the sample being played is 52011 samples long - so the 11025 samples seen in the display can't possibly show all of it at once, only the most recent quarter of a second.
Each time a new trigger comes, the 1/4 of a second "slice" that gets displayed has moved along a little bit - and this gives the illusion of scrolling.

So, to get slower scrolling, you don't change the ticker speed, you have to make it so that you can see more of the samples.
But that is not quite as simple as it sounds. Increasing the "Samples to show" value means that there will be much more data to process - much of which you won't see, because it's all crammed into a window that's only a few hundred pixels wide. Just to check I wasn't talking rubbish, I gave it a try - and my little Atom notebook gave up at about 50000 samples. Doing it this way is a serious CPU hog!!

You'll notice that earlier I said that the "slice" of samples is giving "the illusion of scrolling". Well, I suppose all animation on a screen is just an illusion of movement - but what I mean is that there is no scrolling going on - pixels aren't being shifted around; it just looks like that because of the way that you see a different "slice" of the sound each time.
If you could do it with real scrolling, that would get around the "huge data" problem - you could read just the most recent few samples; squash them down to fit the screen better, add them to the end of the graph, and shift it all along a bit.

Now, that is very interesting to me, because a little team of us did just that using SynthMaker - and as you can see from the old thread HERE, it was not very easy!
But, part of the problem we had with making that was down to some technical limitations of SM...
1) Accuracy of the tickers for getting evenly sized audio slices (Aha, Ruby can do that!)
2) Predicting the exact ASIO buffer size (Aha, FS can do that too!)
So it may just be that, using FS, a much better version of that old design could be made - that shows lots of samples AND doesn't kill everyone's CPU.

That would be quite a big job though - I don't mind helping out, as I remember the principles well from that old project - but I don't really have time at the moment to do the full works as I have quite a few other projects on the go. But maybe we could find a couple of other people interested in this and get one hell of a useful FS module made - it's not just the VST freaks that could use it, it would be pretty handy for the folks doing the robotics and data logging type stuff too, I imagine.

[Drnkhobo]

Hell yeah Trog! The idea of a collab on this would be great!

Thanks for taking the time & effort to reply, I really apprecate it man!

You know exactly what I was meaning, I didnt think/want to slow it down with tickers (as you said that just determines tha amount of 'slices' in a sec).

I tried the example you guys did on SM. It pretty good as it is! hehehe! I see you have done most of the calcs in ASM. . . man thats where i get completely lost!

I am going to have a squizz at it some more.

[trogluddite]

I tried the example you guys did on SM. It pretty good as it is! hehehe! I see you have done most of the calcs in ASM. . . man thats where i get completely lost!

Yup, I agree with that - it's tricky to learn, and very easy to crash the system with ASM - but it was previously the only way to very precisely grab and collect multiple samples.
The more I think about this, the more I think that Ruby and 'frames' should make it much easier - and also make code that would be understandable so that people could adapt it.

[Drnkhobo]

I tried to make a scope with Ruby and frames. . . it was pretty slow and I couldnt get the frame size larger than the default 256. I think its 256. . . not enough anyway.

I think if there is anyone on the forums here to try it in Ruby its you Trog. Serious.

i have noticed some bugs in SSC3.osm

Mainly gui bugs when the signal changes drastically it updates the display from left to right. . . ? wtf?
I think its like you said about the accuracy of the tickers.

Personally I think Ruby would be best for this sort of thing, even though I dont know how to do much. I do know that its better/easier in Ruby. I used to do a bit of visualization programming back in the day ( I was 13 ) and I remember doing 2-3d transformations. I saw some of your graphics posts in Ruby & i'll try dig up some code. It was in c++ I think. But the maths is fundamental so translating simple equations wont be a problem

Back to the scope. . .

Am I correct in saying that Ruby can handle this in real-time? (well, not true real-time but max 1-2ms delay)

Cause then why are we messing with stock graph components? Would it be the case to replace those with a Ruby module doing the drawing? Or does Ruby need to grab the samples as well?

[trogluddite]

Would it be the case to replace those with a Ruby module doing the drawing?

Yes, I think you're right, a self-contained module with the audio sampling and GUI all in one would be the best solution. As much as anything, i have found it far easier to manage screen redraws this way, not to mention the extra 'prettiness' of the new brushes and pens that we can now draw with!

it was pretty slow and I couldnt get the frame size larger than the default 256.

256 is probably the size of your soundcard buffer. It's the easiest way for FS to handle the 'frames' - using the same size as the audio card is sending and receiving.
Although it doesn't seem intuitive, this is actually what we want in order to make the scope efficient - to keep hold of more samples than that, we can just chain these small buffers into a much larger array held in the Ruby code.
And it also allows something else clever to be done...
If your display window is, say 200 pixels wide, and you are displaying many thousands of samples, not every sample is needed directly - instead you can find the average (or peak) level of each small chunk and use those to build the graph - because the display can't possibly show any more detail than that. The wave displays in sequencers are often made this way to keep the scrolling smooth as your song plays back.

That has the effect of giving the graph far fewer points to draw, and averaging the chunks is a "high speed" part of the process that could even be done in assembly before passing the data to Ruby, for better efficiency. The trick then is to choose the right size of "chunk" that suits the display size and scrolling speed.

That's why the old version got so complicated - without an accurate tick, and finding out the buffer size so difficult, managing the 'chunks' involved a whole load of extra code that, as you see in those 'glitches', wasn't always very reliable.

I used to do a bit of visualization programming back in the day ( I was 13 ) and I remember doing 2-3d transformations.

Oh, now there's some nostalgia - you have no idea how familiar that sounds!
For some reason, simple fractals seemed to be the thing back in my teens, but rotating 3D cubes were quite popular too, he he. I have to kick myself sometimes when I carp about CPU loads etc. - a Mandelbrot set on an 8bit CPU and a 256*192 8-colour display meant getting up early and setting the program running before going to school. If you were lucky it was done in time to impress your mates when you got home for tea - so long the computer hadn't overheated, and your kid brother wasn't watching cartoons on the little 12" portable TV you were using as your monitor, that is!!
Not much chance of rescuing much of my old code though - there doesn't seem to be a slot in my PC for C15 cassette tapes!

[Drnkhobo]

Although it doesn't seem intuitive, this is actually what we want in order to make the scope efficient

cant believe I never thought that it would be the perfect sample size & just increase the array of each frame to get a bigger slice! doh

That has the effect of giving the graph far fewer points to draw, and averaging the chunks is a "high speed" part of the process that could even be done in assembly before passing the data to Ruby, for better efficiency. The trick then is to choose the right size of "chunk" that suits the display size and scrolling speed

I get you here Trog, but as I said, I am completely lost in ASM

It would be nice to see it done in Ruby. I think it can be done pretty slick too!

simple fractals seemed to be the thing back in my teens, but rotating 3D cubes were quite popular too, he he.

ooh yeah, my fav fractal is the Julia set.... oooweee! - Hav you used Apophysis?

And the 3d cubes were big too I remember. I made one by drawing each point in 3d so to have colours fade & change from the inside out! Memories man! I got my stuff off DeviantArt (Thank god they keep old users accounts alive) & its used in a plugin for Winamp. Anyway, its just interesting cause I know it can be used in Ruby for drawing and it has the 3d rotations down too. It just makes me think of whats possible for Vst's with Ruby GUI's in 3d!

[trogluddite]

Hav you used Apophysis?

That looks pretty cool, I'll have to check it out. The one I've been playing with is ChaosPro - just wish I understood the maths more, as I'm working "blind" most of the time, just hoping I get something pretty out of it!

I get you here Trog, but as I said, I am completely lost in ASM
It would be nice to see it done in Ruby. I think it can be done pretty slick too!

Yes, I think Ruby would be best in the first instance - much easier to tinker with the code to get it working nicely. But audio "frames" are one part of Ruby that can really suck CPU - so converting that little bit of "front-end" code to assembly in the final version should allow some pretty good CPU savings. Definitely something to only do once the algorithm is working nicely though - even when you DO know ASM, it's a bugger to work with!

[Drnkhobo]

just wish I understood the maths more, as I'm working "blind" most of the time, just hoping I get something pretty out of it!

heheheh I know what you mean! I think its more the case that its a simple formula but with tons of tiny variables which to find out exactly what they do, you have to learn by trial & error. . . . lots of time involved!

Hey, I remember in my vis code back in the day, it had 3 basic code 'blocks' if you will. I guess like in Ruby.

Once run at init (reminds me of the init method in Ruby)
Once run at each frame
Once run at each beat

As I know u have played with Ruby's graphics a bit, does it work like that?

So you would put the main code in the 'frame' section & have variables set in 'init' & beat-synced effects in 'beat'.

Tbh I would really love the source for that program! it would be quite useful.

Time for bed

[Drnkhobo]

Alright then. . . lets get things started shall we. . .

First up is the "Get Buffer" module:

getbuffer.PNG (30.73 KiB) Viewed 31640 times

From what I gather you create a midi note that triggers the buffer length?
Via an envelope & some ASM voodoo. . ?

Is this something Ruby can handle for us now?