The current behavior makes sure the cursor is always in the visible part of the pattern. Say, you have positioned it on the master track, and then scroll left. The cursor moves along with the visible window and it ends up on another track, the rightmost visible one. Most often this irritates me quite a lot, as it ends up somewhere I neither expect nor need it to be.
I suggest it stays on whatever track it is, visible or not, until explicitly moved to another. What do you think?
hmm this should at least be optional like the “pattern following”, which is basically the “vertical” version of what you are asking. what I don’t get is why you need such a thing: would you like to perform some sort of “blind editing”?
It’s useful when you want to edit some notes, but are not sure of the key or chords going on at the same time, cause the other instruments are out of the view at the same time. So I need to scroll to those instruments, see the notes and scroll back.
My workaround (or actually quite right thing to do) for this is to move related tracks closer to eachother so I can see all times what I am dealing with. But yes, if cursor would stay in the same place it would be easier from time to time.
Indeed, as Suva said, it’s helpful when you need to edit something on a track that is related to the contents of another track that’s out of view. Be it notes, or pattern commands that have to correspond to events from another track (i.e., resetting a one-shot LFO to perform some fake sidechaining).
Moving the tracks does the trick, that’s how I do it as well, but it’s a hassle.
This is why IT for example had two views of tracks, another where all of them were shown in order they are and another where you could choose what tracks to view. I used to use it all the time. Why not to have something like this in Renoise too, maybe not limited to two different views? Divided pattern editor view with adjustable width and selectable tracks for defined extra views? Maybe ability to hide and show them separately or all together?
I was already about to post this suggestion but thought that track grouping would replace the need, but dunno if it is to be implemented and how long would it take.