Smooth scrolling option in Pattern Editor

Ideas & suggestions
1

Hi Everyone, newbie here.

I am evaluating various Trackers, and my list is now reduced to Renoise and OpenMPT.

So far I like Renoise best (coming from Reaper in terms of features), but one single thing I very much prefer in OpenMPT: there’s an option for smooth scrolling while playing a pattern.

It hurts my eyes when I play a pattern in Renoise. In OpenMPT the scrolling is smooth and far less straining compared. I use a screen pivoted in portrait mode with both Trackers, and the smooth scrolling is very relaxing to the eyes and easier to follow without all the mini jumps from row to row. And it worsens when I increase the vertical padding between rows and/or font size.

I hunted down a similar option in the preferences, but came up short. I posted this identical question on the Renoise Reddit, and the simple answer is “no”. (The scroll lock is helpful, but of course not quite the same. I prefer scrolling as do many others I gather.)

Aside from that, and the classic file tree manager in OpenMPT, Renoise gets my vote (by far). The GUI scaling by itself is a decisive factor, let alone the additional features.

The tree manager I can live without. The smooth scrolling is a real pain point, however. It’s very hard on my eyes: in particular when playing the pattern editor on a portrait screen.

The person responding on Reddit linked to an identical request back in '09:

At the time the main detractors assumed a smooth scolling option in the pattern editor would be “dizzying”. I can assure you the opposite: a smooth scrolling pattern editor is very easy and calming on the eyes, and also (much) easier to track. Proof is in the pudding: fire up OpenMPT and test it for yourselves:

Open one of the demo files. View menu–>Setup. The “Smooth Pattern Scrolling” option is located in the General tab. Play the pattern.

One of the obvious advantages: it is easy to read the notes in smooth scrolling mode. It is impossible to read those without smooth scrolling. That alone should be a valid reason.

It would be great if smooth scrolling would be implemented at some point in Renoise.

7 Likes
2

+1 million - That has been my most wanted GUI feature for about 15 years so I have little hope

And welcome to the Renoise club, it’s the best tracker out there :slight_smile:

Edit: Make that 20 years ago

3 Likes
3

From an ergonomic point of view I would very much welcome this! I mostly use the alternate visual mode where only a playcursor move. But this mode increase the visual ergonomics, but has some other disadvantages against.

From developer sight a big grow of CPU time consumption could be prevented, when this work is doing by graphics card. The trick is to implement pixelscrolling for different songspeeds. For this it would need a transistion function that measure frame scrolling timewindows for smooth scrolling on the different speeds. The good thing is, this is not need to be 100% exactly. For the smoothness you can pay with some latency/inaccuracies in the graphically paintings. The visuals can come some microseconds later too without lost good visual ergonomics that pixelscrolling would bring in. I think Radium Tracker uses an similar way to realize his pixelscrolling.

2 Likes
4

Yes, please, but then also a constant framerate needs to be ensured.

5

@Garf Thanks!

I used Soundtracker and OctaMED back in Amiga days. For the past few months I’ve been playing around with OpenMPT and wasn’t even aware that Renoise existed until someone mentioned it to me.

Cheers!

6

I know very little about programming on this level so I’m a bit curious…

If the Renoise graphics engine is immediate mode, it doesn’t matter in terms of CPU consumption if the content is visually updated or not? But maybe it’s not… it would just be some parameters in some gui functions that were more fine grained.

And regarding the timing transformation, maybe it would be much easier to implement if the scrolling was tied to song ticks (to get one of the variables for the expression that calculates pixel distance). It’s a compromise but still a big leap forward. The tick abstraction is already there and in perfect sync with what’s expected to be shown on the screen.

It seems a very simple modification with just a division and rounding, unless the current code is already very ad-hoc and difficult to change.

7

There are different way’s to implement smooth scrolling.

For best visual results the pixel distance is always 1

I dont know the Renoise code and concrete implementation, and i dont have internal knowing about Renoise Timingshema/Timingroutines. I only give a idea for a possible way to do this. My way would be more focus on visuality. (Pixel distance is always 1)
But there are other options with pixel distance is changed and/or mixed one’s with pixel distance is floating in some ranged area. This options would have not a so calm image flow, but are some possible compromise like you mean.

8

Rather, it’s more dependant on framerate? As ffx was pointing towards.

(Maybe my “simple approach” would be way too jittery. With the cyclic rounding errors that would occur, I can imagine that the brain could pick up on that pattern sometimes. Or weird interferences with the framerate. A suboptimal routine perhaps could make things worse.)

9

I have my Renoise fps limited to 60 Hz because my older office monitors are limited to this and i personally are good with it. So i would leave and calculate always with 60 fps. On extrem slow songs with slow scrolling it doesent’s fits a role and for extrem speed songs with ridicoulus speedy patternscrolling you would have to explore the limits in visuality. But I also doubt that anyone will complain about linesrolling with songs like this. When your entire pattern is jizzing in less then a quarter or eighth second out of the screen you no longer consciously grasp the content of the notes information anyway.

//Edit But yes, there will be sure people that want have higher framerates too

10

Ah, btw… This is from the OpenMPT wiki:

Smooth pattern scrolling

Scrolls patterns tick by tick rather than row by row during playback. Pattern scrolling will look smoother at the expense of increased CPU load.

Most common tick values used in oldschool are 3, 4, 5, 6… In Renoise the default is 12. Whether CPU load would increase would depend on the gui engine and its caching I suppose. OpenMPT is GDI (possibly with patterntracks rendered as images) so it’s a different scheme obviously.