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.
) 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 
