Yes, hurry up with that patch. Its creating more work and hassle for us mastering studios.
I have found however that the 7.1 is better, meaning, I get less dropouts…one is too many though. I’m still super edgy about it which isn’t a good feeling.
Are you kidding? That should be a superfast, nearly sameday patch.
Otherwise it would be just a big shame for Steinberg, to let professional users wait “for the next version” - unless the “next version” is released only a few days later …
So hurry up Steinberg and deliver what we have ALREADY paid for! NOW!!
We shall deliver a WaveLab 7.11 in june, with this fix and others. The exact date can’t be given now, because there are several parallel ongoing projects at Steinberg.
Thanks for a quick reply.
My answer to this:
Steinberg should prioritize properly - not focusing too strong on new products/features for making money fast, but on excellent customer service. Especially regarding products, that are used by demanding professionals who have to rely 100% on their software. Finally it’s only a matter of quantity vs. quality. I really hope, the latter one is what counts most for Steinberg. As it surely does for engineers all around the world.
Yes, and also the number of people having this problem are a certain quantity. Not saying this problem got the right priority (apparently not for you), but you make it sound like no-one is able to use WL up till now. I can, and many more users can.
Luck, Arjan
If you had seriously read the complete thread, you would have seen my posting from 16 Feb 2011, 12:41.
When you look at the date, THAT alone should lead Steinberg to be ashamed of the poor aftersales customer service.
Wavelabs original function is to be a mastering-software. And the External Gear-feature is one (if not THE) unique feature of Wavelab. Many companies/engineers bought the software only for this function (including me), because nearly everything else can be done with other products also. Not so the comfortable external gear-thing. Sure: you can workaround with two instances (play/record), different programs (here Sony CD Architect, Nuendo and more) or simply two computers for the same purpose. But that leaves THE unique feature, which makes working with analogue external gear comfortable and time-saving, useless.
So don’t tell me anything else. It is simply ridiculous that this feature does not work for many engineers since the new version of Wavelab, that has been paid since. Or do you accept giving it back because it does not work 100% as advertised, like it is common practice in ALL other economical branches, but the software-industry? I really don’t need Wavelab explicitly - except for the External Gear-feature.
BTW: Did you take into account that many (amateur and semiprofessional) engineers or musicians, who use WL, did/do not even hear the dropouts, since they are sometimes more and sometimes less severe, and in the latter case really a good ear is needed to detect them? Read some posts before, where exactly this was a problem, when an engineer gave his result to a customer who then again gave him feedback about faulty audio with dropouts.
I stand by it: This needs to be fixed. NOW!
Because correct audio output is the CORE-feature of ANY audio editor. NO discussion.
Chill out
You know what: you - and you only - are totally 100% right.
Luck, Arjan
Yes, there’s a bug; no it doesn’t show the same for everyone because the severity varies with the system; yes, PG has had one go at fixing it which improved it but was not sufficient; yes, he is going to deliver a more fundamental fix soon; yes, the patched program will go through regression testing before release, because you really, really don’t want something else to break in the hurry, right?
If you have ever worked with software you would know that this is a reasonable sequence, in a reasonable timescale - shouting about how bad it is doesn’t make fixing faults any easier, in this field, the same as any other.
Paul
To pick that up: I’m really a little chilled about Steinbergs products. Even more about their customer support. Sorry, but I have to say that. Remember dropping of Direct X-support in Nuendo? That says it all. Rendered a lot of plugins worthless for us and we had to buy them as VST again. Should not happen.
At this point, I would say: yes! Do you really want to discuss, that delivering error-free audio output (in mere terms of counts of samples) is the foremost priority for a digital audio editor? OK, feel free to do that. I’d say, that everything else could go wrong in the software/GUI, but not that. If you have to check by ear, whether the output of a digital system on the mere technical basis is correct, then you nearly can dump the whole software - or you entitle it as “vintage” (that’s my portion of irony/sarcasm at this point 
).
If I work with software (what I did and do) I do intensive testing before I slap it out. Sure there can be little cosmetical problems, I would agree to that. But rendering audio material with dropouts is one of the most severe faults, an audio editor can have. If everything else goes wrong - that at least should work 100% flawlessly.
I think you would agree, right?
As said earlier: You can make a fault (as that is only human), but don’t do it twice.
I appreciate, that Steinberg recognized the problem at least and is working on a solution. What I don’t understand is, that it did not strike to anybody at Steinberg BEFORE releasing the software. That makes me suspicious and leads me to the (I think legitimate) question, where the priorities of the developers/testers are. I can add to this, that I wrote to Steinberg, that the sound of a rendered DDP-image is (now: was) not the same as the original sound in the project window, even if I had ticked the checkbox “don’t use master section” (and had no processors in the chain), hence should have been 100% the same output (with no recalculation). Guess what? I never got an answer from the support. And if you now look at the list of changes for the newest version, they write that there was a (obviously now corrected) bug with exactly this (the audio went through the master-section though that was switched off). I did not use DDP-rendering after my findings, since I don’t want the software to alter my work in a not intended and unwanted way. Can I now? That is the question.
So I ask it again: What should be the top priority for an audio editor? The count of features or the quality of the software? Can we trust Steinberg to have the right priorities?
Maybe I’m too demanding, OK. I’d agree to that. But what else leads to improvement?
Yes, of course I agree; and I would hope that PG is aware of design techniques that help to minimise the likelihood of introducing errors. But none the less, errors can still happen; testing inherently cannot be complete and perfect. Any particular error may only happen in rather specific circumstances - as another example, consider the early Pentium processors that were manufactured with a fault in the floating-point divide instruction: this was a blatant and readily demonstrable fault, yet one that even the resources of Intel managed to miss in testing. In any case, given an actual fault for whatever reason, a sufficiently measured response should be made, to minimise the possibility of some other error being made by rushing the job.
Paul
Yes, I know about the Pentium-calculation-error. But that was hardware-immanent and therefore not as easy to sort out as it is with software.
In the end I resented the statement of PG: “The exact date can’t be given now, because there are several parallel ongoing projects at Steinberg.”
The “exact” date can’t be given, OK. But the following reason is kind of silly for such an important thing like dropouts in audio. What are the parallel ongoing projects? Sure, there will be a lot. But are they as important as this bug? Are they important enough, to leave this bug in the software for several months? Are they important enough to justify a phrase like “The fix will be included in the next version”. When we all now, that the release of “a new version” is normally some weeks - if not months - in the future? That is the point.
Remember: the bug exists since day one of Wavelab 7. The first post of this thread is from 28 Jan 2011. Several months ago, therefore. That is inacceptable - simply put after a lot of words.
You still don’t seem to understand that a bug that’s a major one for you, doesn’t have to be any problem for the next guy. Like me, for instance. Hope it gets fixed soon anyway…
Luck, Arjan
I’m well aware of different rating of the importance of different bugs by different users. And of course: that bug, that affects you most is - naturally - the most important bug …
But aside from that personal estimation and seriously now, there are some things that simply are a no go’s. Example: New car. Somebody would not have a big problem with blisters in the finishing, others would have. But (I “guess”) ALL would find it faulty that the seats are not built into their car (tip as a workaround: use folding-camp-chairs until the manufacturer delivers the leather furniture) or the back-rests are missing (workaround: use some slab of wood and fix it with florist wire - alternatively: Gaffa-tape). 
All those, who use that part of WL extensively, are massively restricted with this bug now, not only a little. It’s not a matter of personal taste. Because we are forced to alter the whole workflow (like described in an earlier post), and older projects cannot be used/reopened without heavy, time consuming changes. Hence this part of the program is completely unusable.
So, after rethinking: would you agree, that this IS a most important bug, that needs to be fixed as fast as possible, even if YOU don’t use that part?
If not, please let me know examples of other as-important bugs or Steiny-development work, and I will think about it. Otherwise your posting is not much of use, because you claim something, but the substantiation and the example is missing. I’m curious.
PG said the next version (where this bug is fixed) comes in June so what is the point of this “discussion”…
There is no discussion. Planetgroove cannot understand that people not using external gear have no problem whatsoever with dropouts in WL7 - and subsequently wants Steinberg’s full attention and all resources going towards this bug, and only to this bug.
Luck, Arjan
Hence the apostrophes…
My work around is recording the input again to a new file but just right now i had a track that i rendered (i forgot i had the extrenal gear in line) like supposed to and i noticed something strange. .
The first attack of the sound was missing even if the original file has a small silent pre-gap in the beginning.
When i playback the original file with all pluginns it’s ok and you can even hear the small pre-gap but when rendered the pre-gap is gone and also the first couple of miliseconds of the audio are gone. I didn’t notice this with the 7.01 version and since i useually don’t use the render any more i never noticed before.
Looks like there is something going on with the latency of the external gear pluginn when rendering?
The first attack of the sound was missing even if the original file has a small silent pre-gap in the beginning.
When i playback the original file with all pluginns it’s ok and you can even hear the small pre-gap but when rendered the pre-gap is gone and also the first couple of miliseconds of the audio are gone. I didn’t notice this with the 7.01 version and since i useually don’t use the render any more i never noticed before.
Check Options > Audio Streaming Settings…
“Perform short fade-in/out when starting/stopping playback”
try toggle this setting
regards S-EH
That is another bug I informed Steinberg about via support-form long ago. The automatic latency detection of External Gear-function seems to be out of order at his time …
So it seems, Steinberg forgot testing External Gear completely, when slapping out the new version.