Scrolling by pixel instead of per line… optionally of course. This would be soooo cool for low speeds, or varyying speeds. And yes, it would also eat a lot of CPU I guess.
Instead of scrolling by pixel, how about scrolling by subtick?
Hmm? You can scroll by pixel or by “subpixel” (kinda lika anti-aliasing works, this would be kinda insane). When the song has progressed enough ticks to warrant scrolling one pixel further, it scrolls one pixel further…or put differently: A line is X pixels high, and the song has such a speed so one line “lasts” for Y seconds: then that line would scroll with X pixels per Y seconds.
Simple as that, ticks don’t even enter the equation. Theoretically you could have very coarse tick resolution yet still scroll scmoothly. That’s kinda the point of smooth scrolling, that the scrolling has a higher resolution than the data.
Then again, would it?
Only when the FPS are high and the speed is low enough that one line gets shown for more than one frame - because then the pattern would be redrawn each frame, instead of only when a new line is reached.
But when the song is faster than that, it gets redrawn each frame anyway! And it wouldn’t really take much to calculate where the view should be at, and the rendering of the pattern editor would just have to be able to accept a pixel offset…
As it is right now: when the CPU load gets heavy and the scrolling stutters, it’s not really that pleasant or useful to look at anyway. So when (with smooth scrolling) the lines additionally wobble up and down (like when you look at a spinning wheel), that at least wouldn’t annoy me much… and when the FPS are high, it scrolls as smoothly as the FPS allow (it can’t scroll more smoothly than that anway 
).
Please help me see a drawback…
If you have ever tried browsing a normal webpage with smooth scrolling on or off (with a decent PC), you know it makes a lot of difference.
Aren’t subticks what Renoise’s timing system is based on now? Isn’t that how the 256 point resolution delay column was added? When are you going to have more than 256 pixels per line that scrolling with resolution independent of the timing system is going to be necessary?
The pattern scrolling stutters when you are suffering from CPU overload because the audio engine is given higher priority, and the GUI is rendered when Renoise can get to it. I’m sure that smooth scrolling wouldn’t eat up enough CPU to really make a huge difference anyways, though.
I have nothing against adding smooth scrolling to Renoise, but rendering the cursor/pattern editor display position independently of the timing engine would be ridiculous and unnecessary.
A line is as high as it is displayed on the screen…
Well yeah, point taken…
Yes and no. A line is as many pixels tall as it is pixels tall. Depending on your resolution and type of monitor, a pixel may appear larger or smaller. In Renoise, it is actually impossible to have a line that is over 256 pixels tall. (As far as I can tell, the maximum line height is considerably less than that.)
Exactly! And it is impossible to have a line with a height over 256 pixels, regardless of how big it looks to you.
What? Last time I checked, Renoise didn’t support adding custom fonts. Correct me if I’m wrong, though. I think that you might want to spend some time in the GUI preferences menu.
:edit: So I lied, Renoise does let you use your own fonts. I suppose that if you wanted to track on an unimaginably large screen at unmanageably slow tempos, smooth scrolling based on the built-in timing system might look a tad choppy. :/edit:
What are you talking about??
The height of a line in the pattern editor is the height of the font, depending on the size setting of which there are four… so what are you going on about 256 pixels?..
How would the cursor scroll between the lines in that case? Currently, when the pattern jumps from line to line, the cursor does as well.
I don’t even care whether we get smooth scrolling or not, so I’ll let someone else argue with you about why 1/256th line resolution should and will have to be good enough.
This is of course assuming that Renoise’s timing engine works the way that I think that it does. If it doesn’t, I still don’t care, but good for you.
Well, I didn’t think about applying it to editing and stuff, just to playback.
ummmmkay…
+1
Either by pixel or subtick/whatever…
Could it eat GPU instead?
I’d say the cursor (the horizontal line when pattern follow is enabled) would scroll along smoothly and when you’d stop it would stop exactly on the line as it does now.
[edit] also:
http://www.renoise.com/board/index.php?sho…ooth++scrolling
http://www.renoise.com/board/index.php?sho…ooth++scrolling
http://www.renoise.com/board/index.php?sho…ooth++scrolling
Yeah, why not eh? I can’t see any real disadvantages, and the juddery speccy-like line ‘switching’ that Renoise currently uses is a bit harsh on the eyes after a while. It may also confuse beginners who don’t see the jerky scrolling as actual scrolling at all.
The GPU can handle this no prob!
I agree with Twinbee, I’m sure it’ll take a small number of CPU cycles, and I’m willing to bet that the majority of GFX hardware will be able do most of the work nowadays. It should still be an optional thing though (although I’m not sure the devs would even bother with something that’s so aestetic and that would probably mean another checkbox in the options).
As for how much it moves - I think it can be solved by simple mathematics:
Each line has a height of (for example) 16 pixels. (PPL)
And you run the tune at 8 ticks per line. (TPL)
So for every tick, it would move along 2 pixels (PPL / TPL)
For any combination that result in fractions of pixels, I’m pretty certain that GPUs can work quckly enough in 2D to provide a nice, slick looking anti-aliased version of those sub-pixels giving us faultless smoothness.
And as for scrolling, keep it as it is for the arrow keys / mouse wheel, and I was thinking middle mouse button + wheel motion /arrow keys could provide sub-line scrolling.
Perhaps even a counter displaying pp.ll.tt (pattern, line, tick), not too disimilar from Ableton would be nice, particularly whilst scrolling through ticks.
Still the majority of this is purely cosmetic and not vital, but it might give it a nice polished look & feel. I can’t say if it would actually look or feel any better until I see it though! Besides all this, I’m guessing a lot is going to change with regards to sub-tick editing anyway, so a lot of this will probably be rendered useless! 
-1
I think this would make pattern data actually harder to read. As it is now, by staring at a fixed point you have a chance to see the notes/data ‘step’ through your vision, snapping along as the lines progress.
With smooth scrolling your eyes would be doing so much more work, you’d get dizzy.
Just do a mockup in Flash and we’d find out. 
It must be very subjective, because I believe it makes the data so much easier to read. I always look around the whole pattern and looking ahead, not just watching a fixed point, a fluid motion is easier to read in my mind… Imagine if the star wars scroller worked this jerky way
I did a mockup of this in flash long time ago, but looks like I’ve deleted it when I moved server 
I’m with mr sette. You might as well suggest the step light on an 808 sequencer smoothly fade between steps.
So? Some people need to get out and exercise. Lose some weight!!! 