I posted about this bug over in the Reaper forums but it appears to be limited to the AU versions of the u-he synths, so I wanted to post here...
http://forum.cockos.com/showthread.php?p=1074541
Tracks featuring AU u-he synth which have been set to launch in a separate process or a dedicated process progressively lag when playback region is set to loop... every time playback loops back, the lag grows.
- VST versions set to launch in a separate or dedicated process don't have this problem - playback doesn't lag at all.
- AU versions which launch normally (i.e. not at a separate or dedicated process) are fine - no lag.
u-he AU synths in Reaper - bug
-
- KVRian
- 608 posts since 23 Jun, 2005
-
- KVRAF
- 4197 posts since 23 May, 2004 from Bad Vilbel, Germany
Just a thought: are you 100% sure that the loop ends exactly on the bar?
-
- KVRian
- Topic Starter
- 608 posts since 23 Jun, 2005
Yes
-
- u-he
- 30228 posts since 8 Aug, 2002 from Berlin
-
- KVRian
- Topic Starter
- 608 posts since 23 Jun, 2005
As far as I can tell, yes - bug is limited specifically to u-he AU synths set to separate or dedicated process... It's weird, change any one of those variables and the bug doesn't occur
-
- u-he
- 30228 posts since 8 Aug, 2002 from Berlin
It might be related to our plugins' 16 samples latency that we report to the host.mustgroove wrote:As far as I can tell, yes - bug is limited specifically to u-he AU synths set to separate or dedicated process... It's weird, change any one of those variables and the bug doesn't occur
Would you mind downloading and extracting this default.h2p file?
http://www.u-he.com/downloads/default.zip
Just put it in the root preset directory of any synth, e.g. MacHD/Library/Audio/Presets/u-he/Zebra2 and restart your host. Thence the 16 samples are no more, but beware that buffer size must be a multiple of 16 or else
Cheers,
Urs
-
- KVRian
- Topic Starter
- 608 posts since 23 Jun, 2005
Just tried it - doesn't fix the problem unfortunately. Tested with a buffer size of 512.
Not sure if I explained a couple of things clearly enough in my initial post:
- When I say "playback region is set to loop" I mean that a particular time selection is selected and playback looping is enabled, and the lag occurs when playback loops back through this region (as opposed to a single MIDI item which is set to loop over X number of bars):
- the amount of lag introduced at every playback loop depends on the audio device buffer size... i.e. when I set my buffer to 128 samples the lag introduced at every loop is very small, so it takes a long time for that particular track to lag behind the rest... when it's set to 512 samples the lag introduced at every playback loop is significant, and the timing offset becomes very large very quickly...
Here are some audio clips to illustrate the problem... Two instances of ACE, both playing a 1 bar MIDI clip, with that 1 bar time selection set to loop as per the screenshot above...track 1 is an AU instance of ACE (set to dedicated process) panned hard R, track 2 is a VST instance of ACE (set to load normally - no dedicated or separate process), panned hard L. The first clip is at a buffer size of 128 samples - the R channel lags behind the L channel very slowly. The second clip is at a buffer size of 512 samples - the lag kicks in very quickly.
https://dl.dropbox.com/u/7988988/128.mp3
https://dl.dropbox.com/u/7988988/512.mp3
Not sure if I explained a couple of things clearly enough in my initial post:
- When I say "playback region is set to loop" I mean that a particular time selection is selected and playback looping is enabled, and the lag occurs when playback loops back through this region (as opposed to a single MIDI item which is set to loop over X number of bars):
- the amount of lag introduced at every playback loop depends on the audio device buffer size... i.e. when I set my buffer to 128 samples the lag introduced at every loop is very small, so it takes a long time for that particular track to lag behind the rest... when it's set to 512 samples the lag introduced at every playback loop is significant, and the timing offset becomes very large very quickly...
Here are some audio clips to illustrate the problem... Two instances of ACE, both playing a 1 bar MIDI clip, with that 1 bar time selection set to loop as per the screenshot above...track 1 is an AU instance of ACE (set to dedicated process) panned hard R, track 2 is a VST instance of ACE (set to load normally - no dedicated or separate process), panned hard L. The first clip is at a buffer size of 128 samples - the R channel lags behind the L channel very slowly. The second clip is at a buffer size of 512 samples - the lag kicks in very quickly.
https://dl.dropbox.com/u/7988988/128.mp3
https://dl.dropbox.com/u/7988988/512.mp3
-
- KVRAF
- 1888 posts since 13 Aug, 2011 from Berlin
Yippi Yayeah!
Cockos fixed that problem with Reaper version 4.31! Ain't that nice?
I reproduced that bug with 4.30 and then I installed 4.31 and it's gone here. Cool.
Cockos fixed that problem with Reaper version 4.31! Ain't that nice?
I reproduced that bug with 4.30 and then I installed 4.31 and it's gone here. Cool.
-
- KVRian
- Topic Starter
- 608 posts since 23 Jun, 2005
That's not the case here unfortunately, the bug is still very much present in 4.31... in fact those clips I posted earlier were created in 4.31 
-
- u-he
- 30228 posts since 8 Aug, 2002 from Berlin
Ok, we've tried every AU demo on earth. All those that report latency exhibit the problem, all those that don't report latency don't.
If our default.h2p doesn't work then maybe it's already been cashed in Reaper.
We'll stay on the ball, but for now we recommend not to run our stuff sandboxed in Reaper.
If our default.h2p doesn't work then maybe it's already been cashed in Reaper.
We'll stay on the ball, but for now we recommend not to run our stuff sandboxed in Reaper.
-
- KVRAF
- 24451 posts since 7 Jan, 2009 from Croatia
I have to ask - why set any of u-he plugins as a separate process? They've been rock solid over here, never a single crash...
-
- KVRian
- 1209 posts since 28 Jun, 2005
Right click on "2 in 2 out" in the FX window and disable PDC on the first VST.
(If you use more than one in a channel).
I had the same problem and it solved it for me.
Did this help ?
(If you use more than one in a channel).
I had the same problem and it solved it for me.
Did this help ?
-
- u-he
- 30228 posts since 8 Aug, 2002 from Berlin
Faux Pas - !BLOCK_LATENCY_OFF=YES turns latency off, not NO. Just edit it to YES and you're good.
If you do that, the Reaper problem is gone with our AUs.