WL keeps losing Audio Connections

WaveLab
#16

I am on 8.5 - but honestly can’t remember if it was an issue back in the 8.04 days. Big difference too in this equation are the latest v4 RME drivers (currently @ 4.06) that most certainly will have a bit of an effect on things.

Personally tho - I am starting to doubt Wavelabs stability overall as it seems to be the only pro level app out there that consistently won’t play nice with standard vendor plugins (Piles of threads on that topic in here) and this ongoing saga with RME.

Almost seems like WL has it’s own “non standard” methods to talk to industry standard plugins and drivers- which in turn fail when you really need it to work.

With something like Studio One over here - I honestly have never actually seen a glitch, slowdown, hesitation or anything else using the same plugins and audio interface that is available to WL.

So whatever Presonus is doing in their app - maybe they can share some of that magic with PG and get WL back to stable.

VP

#17

Bruce is right about the plug-in issues. It’s kind of a double whammy since VST is pretty much a Steinberg-only thing nowadays (at least on macs), and doubles my maintenance chores (triples if I count PT, but I don’t really!). When they don’t work it makes the format issue worse.

I think it was better in 8.04, but that could be relative to soundBlade. Circa 8.01-03 I rarely used sB at all, but since 8.5 I’ve frequently used sB over WL due to better plug-in handling. It probably helps that it runs both AU and VST, so when there’s a problem you can just use whichever is working. WL can’t do that, so it gets blamed when the VST is munged, whomevers fault it may be.

#18

Bruce and Daved, I feel for you about the plugins. We’ve been very lucky to have virtually no issues at all with what we’ve been using with Wavelab since Wavelab 6: UAD, Waves, Sonnox, TC. (except an early issue with Waves transparent display I solved by swapping out the video card to another manufacturer).
I’ve wondered through all the discussions why so many people say every third party plugin they use works fine in Cubase, Reaper, Studio One, Pro Tools, Logic, etc., and I always got the feeling maybe, just maybe, those programs were possibly more tolerant about parameters and behavior they were willing to accept from a plugin that wasn’t strictly by the book. And that Wavelab was much more strict in it’s requirements. I don’t really know what I’m talking about, and someone can tell me that has nothing to do with it, but I always got that feeling.

#19

Ha … the grass is always greener. Except we know that it usually isn’t when you’re there (first big crash after set up of a new ProFools system).

#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