http://wavearts.com/downloads/version-history/
Maybe they might have exaggerated just a touch there …
Their words - not mine 
But hey - the forum here speaks for itself. Not exactly a secret that WL has its own share of issues…
VP
Sometimes it behaves as you described. But mostly when WL is put into play, its tranport and meters freeze and no sound. We have to wait until it snaps out of it. Hit play again - freeze again. Wait till it snaps out of it (maybe like 30sec). Refresh reliably solves the problem. As others have mentioned, I believe it is correlated with a change of Fs as I can see the RME control panel indicates it “wants” to be one sample rate, but has not physically made the switch. Will try to get a screen shot next time it happens.
Yes, AES.
Luck?!? Ha,ha, ha… would rather have the engineered solution from WL and/or RME.
There are lots of bugs in this version of WL. Bugs which effect some rather essential/fundamental procedures and are alarming. None the less, WL is an outstanding program for mastering and I believe PG will sort them out. I STRONGLY encourage PG to not wait too long.
This is what happens here to the letter.
VP
Totally agree. I still think that Wavelab might have more stringent rules for plugins than other apps do as part of the problem, but your call for identical code would take care of that anyway. My original thought of Wavelab difference came from the problem with Ozone, where Ozone was out of spec:
and PG said he could adjust on the Wavelab side (“the problem is on the Ozone side (the plugin’s view coordinate is out of the window). Fortunatly, I have found a way to fix it on the WaveLab side”. But Ozone probably displayed fine in Cubase, Reaper, etc, even with the out of spec view coordinate. Just made me think all the other programs might be allowing say 70mm if a spec says 50mm (or whatever unit of measurement), giving leeway, but Wavelab is not allowing any leeway. But like you said identical code would cover that, and if other programs are allowing leeway, Wavelab should too. Could be wrong, but it made sense to me at the time.
Sorry to derail this Audio Interface thread. Still no RME problem here with Wavelab 8.0.4, but I’ll try 8.5 soon to see if the problem pops up.
of course I’m making wild uninformed guesses about leeway that may or may not be true, but I’d love to be corrected with the correct information.
I think you’re right Bob. It’s been my impression in the past too, that WL is very strict in interpreting the VST standard (or adhering to the standard at all), where several plugin companies don’t take things so strictly and have no problems doing so in other DAWs that are also more lenient - including Steinberg’s own Cubase.
But there’s also the rendering approach in WL, where a copy of a plugin is taken for rendering. This also doesn’t always play nice with plugin companies’ expectations in plugin behaviour.
But whatever the causes of problems, hopefully a working solution can be found. I myself have been lucky so far, I guess, but then I also don’t use very many 3rd party plugins…
WYCA … One further thing: I have noticed that this seems to happen when I play … for the first time in a session … a file that I might have loaded up from a different drive to the session drive. Typically, a reference file at 16/44.1 that lives on another drive. So, when I switch from a session file at say 24/48 to listen to the reference file, that’s when the RME typically hangs. But I can’t reliably reproduce this. Also, once this ‘happens’ the system seems fine for the rest of the day.
So, I wonder if the different drives are a contributing factor.
If I discover any other clues I will share them. You don’t have any easy job with all those systems.
I tried Wavelab 8.5.20 with RME, on and off for a number of hours, and couldn’t get it to hang or disconnect. Switching between all different sample rate files on different drives. Switching is instantaneous. But I’m still using 4-5 year old RME driver and firmware, so that might be a factor.
Win 7 64
Wavelab 8.5.20 32
RME HDSPe AES
RME Hammerfall DSP 3.08.4
Pop your RME up to 4.06 and see if the same smooth switching is still there.
VP
I am totally fine with a “strict” implementation but not when the implementation actually stops work in progress. As soon as that occurs - I am off to another host as - at that point - I really do not care how WL is interpreting the vendor’s VST scenario - I just want to complete the job, get the invoice out the door and move on to the next one.
I can’t see how being so strict as to have the user abandon the app during a project - is a good thing.
VP
Possibly. All our systems are continually having different project drives mounted through out the day. But I don’t feel too strongly about that as a cause since there is not enough correlation. That is, I would expect freezing almost each time there is a boot up, which is not the case.
Dang, bob99, you are a trooper!
I may have neglected to specify that all the AIO and AES-32 cards in our troubled WL8.5 systems are the PCIe version with the latest drivers.
Thanks Bruce, I would, but from everybody’s experience here, I think I might wait it out.
So everyone here with problems has newer RME sw than me? And Steinberg and RME still can’t replicate?
WYCA, I went to your RME thread WL8 losing connection to RME cards (Page 1) — HDSP(e) series — RME User Forum and he mentioned “Under XP you most probably used older drivers that never reloaded the devices upon sample rate change”. Has anyone here with problems tried de-selecting “reset driver on sample rate change” in Wavelab preferences as a temporary test?
Yep. I had it both on and off and still did not help anything with my setup.
And I too have PCIe here.
VP
PCIe here too. Maybe RME and Steinberg haven’t tried this recently? Don’t really see responses indicating one way or another.
I thought that PG replied to me in an earlier thread from long ago saying that he tested WL and RME in house and had no issues?
Found it! here…
I find it odd that he has not chimed into this thread…like at all.
VP
Having “Reset driver on sample rate change” on or off has had no apparent affect on this issue on our systems.
I have been neglecting this topic over at the RME forum, where it is equally as relevant. I posted there again today with a link to this thread.
This happens to me. Running an Echo Layla 24/96. No plug ins. A single audio file - no playback in Windows (windows 7). This is a massive pain in the arse. I have to move files over to a Mac and run WL on there in order to do any processing.
Was there any resolution to this widespread problem?
Have you tried switching from ASIO to MME in the Wavelab ASIO connections?
Did this work previously in earlier versions of Wavelab or Windows or before Echo Layla?
Are you also using the Echo Layla on the Mac?