WL keeps losing Audio Connections

WaveLab
#20

My gut says it’s the other way around - WL uses some substandard oddball way of loading/using/talking to industry standard plugs and the other guys do it right.

The never ending graphics issues with plugins in WL etc etc have been happening for a long while. In the past I have even spoke to developers of specific plugs I use - like WaveArts for example - and even they say that WL has a very strange plugin pipeline and that it’s one of the only apps to consistently kick out errors and issues.

Honestly - it blows my mind that a supposedly “Steinberg” product - whose development team should have access to most detailed VST specs and standards possible (Since Steinberg invented VST) - end up being the one app out there that barfs on plugins (and now audio drivers) the most?

It begs the question - does PG ever trade notes with the Cubase or Nuendo devs? Why is it that Nuendo is rock solid in the plugin and driver department and clunky ole WL is left bringing up the rear?

Seems to me that all three apps FROM Steinberg (Nuendo, Cubase AND Wavelab) - should all use the same identical code to load and use VST plugins correctly.

VP

#21

http://wavearts.com/downloads/version-history/

Maybe they might have exaggerated just a touch there …

#22

Their words - not mine :slight_smile:

But hey - the forum here speaks for itself. Not exactly a secret that WL has its own share of issues…

VP

#23

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.

#24

This is what happens here to the letter.

VP

#25

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:
http://www.steinberg.net/forums/viewtopic.php?f=189&t=44376&start=50
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.

#26

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.

#27

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…

#28

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.

#29

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

#30

Pop your RME up to 4.06 and see if the same smooth switching is still there.

VP

#31

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

#32

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.

#33

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.

#34

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 https://www.forum.rme-audio.de/viewtopic.php?id=21691 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?

#35

Yep. I had it both on and off and still did not help anything with my setup.

And I too have PCIe here.

VP

#36

PCIe here too. Maybe RME and Steinberg haven’t tried this recently? Don’t really see responses indicating one way or another.

#37

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…

http://www.steinberg.net/forums/viewtopic.php?f=189&t=76371

I find it odd that he has not chimed into this thread…like at all.

VP

#38

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.

#39

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?