Something I’ve noticed for quite a while (n-Track Windows), is that after stopping playback and editing a track (usually Remove Part and add a new part in its place I think), when I continue playback the cursor runs off the end of the track window, and the window doesn’t scroll to follow it. Sometimes it eventually catches up, but usually the only way to get it to work again is to reset to the start of the song and start playback from there.
It’s not something that has bothered me too much up until now, but last night I was replacing parts as I went and had to rely on stopping it by ear and scrolling to the point where I wanted to replace the next part, which got a bit tedious.
what do you mean that it eventually catches up, after some time or after some action? After you did some editing or dragged on the time axis the timeline stops following the cursor for a few seconds (from memory around 5 to 10), to allow editing without having the timeline that jumps below the mouse. After those few seconds it should resume following. If that’s not what’s happening please post a short video showing what’s happening.
I think I know what happens, the parts I am replacing are quite long, so the cursor doesn’t “catch up” until the end of the part I’ve just replaced. It’s quite frustrating when the next part I want to replace follows straight after it. The parts I am inserting are usually about the same length as the ones I removed, I can understand a small delay when you have moved a part, but this can go on for 20 seconds or more, which is the length these parts often are.
I’ll do some more experiments to see exactly what causes this and check that my theory about the part lengh is correct, and when I’ve worked out exactly what’s happening I’ll try and record a video.
Thanks for sending the video. The time for the auto scrolling to resume should be 5 seconds, while in the video it appears to be around 25 seconds. Does it make any difference if you toggle ‘Fast time window refresh’ in Settings → Preferences → Appearance (and restarting n-Track after changing the setting)?
Does the issue also appear with a simple test song with just one audio track and no effects?
One possible cause of this is if the song is complex and the cpu is struggling to process the song in realtime, it may skip some updates/frames of the user interface, and currently the check to resume the autoscrolling is based on how many frames have happened. We’ll switch to instead checking the absolute time in the next version, which should fix the issue in this scenario.
Hi Flavio, initially changing the “Fast time window refresh” to 10 (I’m not sure what units they are?) didn’t seem to have any effect, even after closing and reopening n-Track. But I then closed the song and created one with just a single track as you suggested, and the follow response was much quicker. I’ve now reopened the first song again and it seems to follow in a much shorter time now, so this may have done the trick, I guess only time will tell when I get into heavier editing.
Just as an update, I’ve been doing some more intensive editing lately and the “5 second” rule now seems to be persisting, so autoscroll is now useable again.