If you play a song with has a huge pdc, like 160ms++ , the song will start, and some time later the sound will start. So the showed position of the position bar is not correct.
Maybe this is intended, but makes absolute no sense while rendering… If i select one pattern in the sequencer for rendering it will even scroll above the end of the pattern…
Jurek: It’s kind of working as intended, the triggering of whatever you have there happens where the song cursor is, and I think it should visually stay that way.
Gova, I said it looks like intended, however scrolling more far then the end position of the render completely makes no sense. Right?
Maybe this behavior is also correlated to the other bug, which often causes the end of a song played on beginning while rendering… That bug maybe only happens if pdc is introduced.
Why not:
On live play, let it stay like it is
on live rendering, start to scroll if all latency is compensated
Doing it or not, it looks kind of fishy…
Gova, I said it looks like intended, however scrolling more far then the end position of the render completely makes no sense. Right?
Maybe this behavior is also correlated to the other bug, which often causes the end of a song played on beginning while rendering… That bug maybe only happens if pdc is introduced.
It needs to do so to play back and render out the part of the pattern which has already played back but has not yet produced audio due to the delay. In other words: it’s a visual thing only. Don’t worry unless it sounds wrong. Does it?
Regarding if the play marker should be delayed too or not:
Hard to say what’s better here. If the visual playback marker would be delayed too, you would hit start and nothing happens for a while, then the song would starts scrolling/playing - so starting/stopping would cause a “lag” too.
It needs to do so to play back and render out the part of the pattern which has already played back but has not yet produced audio due to the delay. In other words: it’s a visual thing only. Don’t worry unless it sounds wrong. Does it?
Yes totally agree, only that it does not stop at the position the rendering stops maybe looks strange…? If you do a selection in the matrix… But ok personally I don’t care.
If the visual playback marker would be delayed too, you would hit start and nothing happens for a while, then the song would starts scrolling/playing - so starting/stopping would cause a “lag” too.
This is how other DAWs I know behave.
This is how other DAWs I know behave.
No, most DAWs are pre-rolling the playback head, start playback visually a bit earlier. In Renoise this would mean that, when starting playback at some pattern in the middle of the sequence, it would start playing at the end of the previous pattern.
An idea for live editing:
What if the song was prerendered for length of the pdc amount before the play is pressed? Like you scroll somewhere, and after 500ms this buffer will be already prerendered?
Then play could happen instantly even with huge pdc. Ok for live input it wouldn’t work…ah forget it, stupid idea 
but you could pre-guess what I will play next live (quite simple here)?
couldn’t the pdc predelay always rendered in non realtime while playing/live, for speed up the lag? … Ah no, also stupid idea…
No, most DAWs are pre-rolling the playback head, start playback visually a bit earlier. In Renoise this would mean that, when starting playback at some pattern in the middle of the sequence, it would start playing at the end of the previous pattern.
As I said, I can only speak for the DAWs I personally know.