I recently acquired abl3 ( audio realism 303 bassline ) , when using the midi out function to sequence other vst’s , then render to selection ( the sequenced vst slave) renoise sometimes skips the first steps when rendering to selection .
So i tried some other seq. vsts …and the same shit happens , out of ten renders , only 1 passed the test
Just wanted to say that abl3 renders perfectly , no missing steps , it only affects sequenced vsti’s (thus ) internal midi routing is used , I remember this occured a lot during beta .
Real bummer , doesn’t happen in reaper ., bitwig ( demo )
Also happens when sequencing internal instruments …
Found the old bug report during beta , there was some latency involved .
Maybe the fix introduced this new bug
Some further testing , so the first step is not rendered .
When pressing play afterwards , the first step isn’t heard either during the first pattern restart …( sequenced vsti only ) .
I do have to point out , that after rendering, the asio driver needs like a 2 sec. restart/initialize , but abl3 keeps rendering perfectly
Maybe a confirmation from one of the developers , so it canbe fixed in the next release
Tried in reaper and bitwig demo …rendering a sequenced ( slaved ) instrument never skips the’ first rendered portion .
Pretty sure it’s the internal midi routing that is causing the problem .
Waiting for a damn to be given
Important: Always provide us with a simple XRNS so we can match your settings during testing.
I only have the demo versions of ABL3 and FabFilter One to experiment with, but I didn’t manage to recreate the problem yet in my own limited testing.
Everything I’ve tried to render came out just fine, all notes in sync, no notes missing, etc.
But I’m probably missing something here, or I have completely different settings to you in Renoise, my audio device, the plugins themselves, etc.
I notice you have Reaktor loaded in your screenshots. I don’t have that installed, but is it possibly introducing some extra plugin latency to the song?
Can you also give a brief overview of your audio settings and other things that are likely unique to your system?
System , core i5 , focusrite scarlett using asio 4 all drivers , around 5ms latency , win 8 …all 64 bit , no 32 bit plugs , no pirated stuff , no porn folders ,nada
Yes reakto can cause some introduced latency when 'use satic processing buffers is on ’ …I always switch this off …so no latency from reaktor .
See screenshot , left channel is direct render of the gate output .
Pdc is off , bcause there is no delay introduced by plugins
It happens whe’n using the midi route function .
I have upgraded to reaktor 6 , the gate/trigger blocks are sample accurate
It still happens , rendering midi controlled instrument from reaktor ( as sender ) introduces a 10 ms delay .
Like I have said , this has been there since the beta .
Happened on my older notebook , and new core i5,
I have no idea how it is implemented , but there sure is an added latency when using the internal midi route in renoise , could be related to the buffer size .
It’s not happening in any other host ( reaper , bitwig demo )
And here the same thing in reaper .
Controlling charlatan from reaktor …absolutely spot on .
I think I got a bit closer to the problem.
First , when reaktor is loaded as a vst , ’ the used processing buffers is on by default ’ …this introdues a latency by default .
If I render reaktor to selection ( without pdc and use processing buffers on , this will introduce some delay in the rendered output)
There are two ways to get rid of this .
First , use pdc compensation or turn processing buffers off .
I tend to choose turn of 'use static processing buffers ’ …now whenever I render reaktor to selection …everything is spot on .
Except when using reaktor as a midi master to control a vst … renoise then magically introduces some delay in the rendered output (of the controlled vst ) ,the exact amount of delay that reaktor normally has when ’ use static processing buffers is on, except that it is turned off .