sorry to say this , but the bug is still there.
The added latency is 5.6 ms regardless of driver latency
Tested with thesis ,era , cream
Try rendering it several times .
Press renoise stop button twice to reset
With sugarbyetes 'thesis ’ every second render , the latency is added to the file
In the xrn , all the rendered files files are done quickly after each other , one good render , one bad , one good etc …
Altough the added latency stays in acceptable limits , e.g. a driver latency of 100 ms will not add 100 ms ( as in the first bug )
With sonic bytes , they are all bad .
Do you have an example for us, a XRNS file? This unfortunately is a bit vague - and pretty complex too.
EDIT: Ah, seems you forgot to attach. Could you please attach the XRNS file again?
Btw:There are also two new forums which deal with the 3.1 beta.
taktik , I posted an example during the first example ,the now closed bug thread .
It’s essentialy the same , altough the added latency is always around 5ms .
Renoise should be reset( stop button) , and then render the eacample multiple times .
or just create a midi plug etc…;
Can not replicate this here. Are you running “Thesis” bridged, in a plugin server, or have you manually enabled the “Use static processing buffer” option for “Thesis”? That could explain the 5ms delay as this is the delay which is caused by the buffering.
I did some more tests .
My soundcard is able to record/resample the output internally, directly in renoise .
Left channel =midi plug controlled
Right channel= pattern editor controlled
Even then there is a 5ms delay to the recorded output of a midi controlled plugin.
Could you please shed some light on how the internal midi routing is implemented , is it some kind of reroute ?
picture below shows rendered output