You know he’s working on it - things happen at a finite speed, is all. Problems in WaveLab are acknowledged and fixed faster than in many other major programs, with (I guess) a smaller staff than most.
My advice (from 45 years working in software development and support) is that impatience never, ever, made things happen faster or better, but not infrequently was itself the cause of problems as well as a distraction.
Paul
Hi Paul
I (mainly) agree - but some things are taking 10 or 15 years to implement - so I think that goes beyond normal levels of patience
just MO obviously
If you seriously have waited 15 years for a feature, you either misunderstood the intention to add it 15 years ago (and there was no such intention then, I’ve been with WL since v.3) or you don’t really need the feature. And there is a big difference between feature requests and fixing bugs.
With respect, I think you are the one who misunderstands. Multichannel (more than 2) audio file support (not in the montage) was talked about - and was ‘tentatively’ promised in WL8 (2012?). I’ve been with WL since version 1.5 - don’t know why that matters though ?
well, how do you know ?
oh, I didn’t know that !
Thanks for mansplaining it all to me - I now realise I (and many others) misunderstood PG intentions to add a feature we don’t even need…and it turns out I need to be told the difference between a feature request and a bug. Thanks for clearing it all up - Think we’ve wandered off topic enough.
Not really. Studio One (Presonus) usually makes hotfixes available in days (even hours) if something really nasty presents itself. I have seen them get reports on a big problem - they fix it and then roll out a package with not only a fix for the identified issue but fixes for 8 others - in 2 or 3 days. This is the reality of “agile” development. Make fixes (and enhancements) fast and furious and keep making them until it’s right.
While I admire PGs dedication to his craft - unfortunately this “one man show” thing reeks of 2006 era development processes where changes take weeks to code, test and deploy. This type of development was on the outs years ago - maybe it’s time for PG to share the load (hire some good resources) and pick up the pace here - that is if if WL is still considered a “major” app.
Here on Feb 10, 2020 - issuing just a single bug fix pack for an app released in Oct 2019 is embarrassing when compared with all other major apps out there.
VP
Hmmm … I wonder how many PT, Sonic and even Magix users would agree with that.
True, that’s why I love S1…
In Donwload Assistant Wavelab 10.0.20 is ready for Download
Also here:
PAR-4066 Paste to an existing clip insert slot shows still the former plugin GUI
PAR-4058 Playback tool plays the right channel on the left speaker
PAR-3976 Jog/Shuttle functions do not work
PAR-4057 Master Section Bypass does not follow edit history
PAR-3904 Audio CD-Import- track playback not working.
PAR-3930 Inspector width can change when switching between montage and audio editor
PAR-3938 Playback Speed Presets don’t work
PAR-4054 Spectrometer analysis of Audio Selection does not work
PAR-4050 Audio Connection mapping issue with multi channel setup
PAR-4046 Function: render multiple montage does not work
PAR-4034 Save function disabled on new audio files
PAR-4044 Montage Time Grid not painted accuratly
PAR-4053 Playback Looping sometimes does not work
PAR-4045 Montage Zooming with Wheel issue
PAR-3633 Sometimes, the waveform drawing stops at the end of the right track border - no paging.
PAR-4030 audio file silence insertion problem
PAR-3987 When moving right loop marker while playback loop in montage is active, the cursor runs beside the right loop marker and not within loop range.
PAR-4028 UAD rendering performances
PAR-4029 Rendering issue with certain VST-2 plugins used in montage with a sample rate different than 44100 Hz
PAR-4032 Rendering in real-time of selected audio track does not work
PAR-4003 CLONE - WaveLab Pro 10 cannot import AES31 files exported from Nuendo 10 successfully.
PAR-3931 Clip Tab Column Widths should auto size when adding new clips
PAR-4031 Scroll back on stop does not always work
PAR-3890 Show message when trying to undo while recording in the montage
PAR-4026 Clip colors get lost, when using Undo History.
PAR-3995 Crash when using “Import Audio File to Montage”
PAR-3903 Loudness Meta Normalizer crash
PAR-3992 Mistake with Duplication of montage with files
PAR-3993 Plugin meters sometimes freeze in loop playback
PAR-4021 GUI performance on Macs
PAR-4020 Edit/Repeat Clip sometimes broken
PAR-4010 Distortion when using automation with clip plugin with latency
PAR-4008 Possible Crash When Docking Tool Window
Here we go! Hoping this gets some positive traction this time.
Cheers!
VP
Clearly PG wants to retain a firm hand on the steering wheel and keep developments close to his chest, or perhaps he’s head of a very small development team ? I urge PG (indeed everyone here) to have a good look at the Reaper model of public beta releases, and the healthy amount of to and fro dialogue that goes on there.
Things get released in beta, perhaps intrinsically broken from minute no.1 They get noticed quickly, and fixed quickly. Nobody gets upset, no blame, no litany of complaints…this is just standard test procedure…continual prototyping, refinement, development and repairs, then rollout with the next version (typically twice or once per month, on average)
Nobody relying on Reaper to earn income or working on critical projects is going to download and use (and then criticise !) the latest beta version…it even comes with the disclaimer that it’s simply the always current ‘work-in-progress’ It results in those 1x/2x monthly updates being largely trouble free…because the beta testing user uptake is sufficiently large and always active.
Compare this with the closed-shop development mentality of PG’s modus operandum…where developments rollout at a snail’s pace, generate angst and bad publicity, and (after too long a delay) eventually get fixed…sort of ?
PG…I don’t expect you (or even believe you are capable of) adopting something like the Reaper continual beta test model in the short term…even though it would benefit Steinberg/Wavelab hugely in the short and long term. However I do urge you to consider stepping out of the comfortable, familiar yet clearly dysfunctional mode that Wavelab development has sadly evolved into
It’s time for a new development paradigm…one that embraced the user base (ie the folks who typically post here) to become positive contributors to the process.
Now…I turn my gaze upon those of us here who do indeed rely upon Wavelab to be a highly effective, income-generating tool. This, because WE are the most likely pool of beta testers, upon whom these Reaper modelled WL-beta prototypes should be tested, if my proposed test model were adopted !!
Are WE willing to take time out of our productive days to engage in long-term enthusiastic , cooperative and positive spirited testing…to help shoulder the load that PG bears ? Because that’s the other, obligatory and public service side of the complaint equation. It’s all well and good for us to criticise PG’s rollout of flawed software…but if suddenly permitted and encouraged and obligated to DO SOMETHING active and constructive…for the greater good of current and future WL users…would we put our hNds up and engage (long term)… like the Reaper testers do ?
I’m not convinced we could collectively rise out of our ‘culture of complaint’ armchairs long enough to be of concrete support ? What would it take to engage us …a discount or free upgrades, in return for valuable testing and feedback across multiple test parameters ? A “user-community based assistive culture” like Reaper has doesn’t appear overnight, it’s evolved over several years. The Wavelab user community is likely a significantly smaller one…so how could a suitable sized population of dedicated beta testers be encouraged and nurtured ?
I don’t have an answer to that…I just know that it’s the next necessary evolutionary step that must be taken, for Wavelab’s continued survival (note the word, rather than ‘success’ !)
Do I see any raised hands in favour of becoming (even just a small core: 3, 5, 10 ?) such beta testers. PG…anyone…how about it ?
Well, having opened the can of worms, I may as well pick up my fork and start eating them…as Van Morrison says, 'It’s too late to stop now ’ ! So rather than a large open- ended pool of beta testers, I’ll propose an initial small group of either self-nominated or PG invited/hand-picked contributors, ideally drawn from this forum. Maybe 5 or 6 at maximum, whose inputs would not necessarily even be shared here during ‘progress mode’
A very helpful part of the Reaper forum are 2 sub-fora: bug listings and feature requests. Bug listings are calmly listed, factual and amply detailed descriptions from users who have noticed things post-update rollout. This forum has such a listing here too. Often these are not bugs in fact, just ineffective approaches by users…and it’s often straightened out in short order by other users, with no developer intervention necessary. It happens informally here also…but perhaps a dedicated sub-section could be maintained in perpetuity ?
The feature request list ( because it can theoretically become endless, and never satisfied !) can also have a popular vote attached, so that significantly popular items can receive the attention of developers…giving some sort of focus to the process .
Maybe I’m labouring under misapprehension, and PG already has a loyal small coterie of trusted beta testers under his wing ? If so, it could be a little more public and expressive of its achievements and ambitions ? Ultimately such things devolve down to a simple numbers game…who and how many has the time to devote to continual testing and refinement of coding ?
I’m simply suggesting that consistent moves toward developer responsiveness like Reaper has enacted, results in a far happier and engaged, dynamic user-base. There are refinements in Reaper (such as Source Destination editing) which have never appeared, despite years of agitating, so the process is far from perfect. However the user-base is always growing and positively disposed to the platform, similar to the loyalty shown to WL.
Not easy to find good beta testers. They need motivation (WaveLab needs to be important for them), then they need observation and investigation skills (to identify problems when they are subtle), communications skills (to report properly), computer skills (to juggle between versions) and most importantly some time to test.
All good points PG…however, training and careful assessment of beta tester existing skills and experience could offset some of these concerns. The pool of beta testers could be selected across a variety of specific usage patterns for Wavelab, to avoid duplication and redundancy. It’s a similar task to designing a good experiment…specifying your parameters well !
I think the necessary skill set exists within some contributors to this forum, while others might be recruited from computer science backgrounds, or those who professionally use WL on a regular basis. Payment or discounted incentives could ensure active testing participation, as well as requirements for regular Skype meetings or similar feedback pipelines.
I ultimately think that, despite reservations and misgivings, formalised regular pre-release testing could work to the benefit of Steinberg/Wavelab and its continued viability in the marketplace…I just hate to see opportunities for effective, timely progress lost…due to fear, jealousy and a closed-silo mentality ? Highly effective team skills and regular communication to beta testers would be a necessary requirement of yourself PG also !
There are already beta testers for WaveLab, there is even a private forum for it, with about the same amount of contributions as this forum.
Personally, I’d hate to have continuous (beta) updates to my working software twice a month. With WL, at least you know your last working version, and if the latest release has problems in your system you can simply revert to your previous working version and wait for the new version to be updated (That’s not to say that a new version on release should be ready without major show stoppers ofcourse).
IIRC cubase used to have a public beta program a few years ago (2000-ish). Think it was during the Cubase VST 5 fiasco. worked quite well I thought, it helps keeps customers informed and engaged…bBut they silently abandoned it.
Now they call beta “final versions” and release anyway 
(same applies to WL10 initial release - sorry PG but you know it’s true)
I use WaveLab about 4 or 5 hours a day, mainly for my own artistic purposes and I primarily use it as a sound design tool. I think I’d be a great asset as a beta tester and would be willing to put time and effort in it too. My communication skills are good enough and I have a sharp eye for details and nuances that makes all the difference when tracking down pitfalls and culprits. I consider my technical skills to be excellent, I’m not a foreigner to programming parlance either. I might even go as far as to divulge a secret faiblesse of mine, that I tend to spend late night hours reading up on obscurities like Duff’s Device in C programming, just to prove a point that I grok all there is to know about that device (whatever it is, I forgot).
So. Are there any posibilities to enroll as a beta tester?
Also, I do agree with the general thoughts of RayThomas above: I think there needs to be one or two persons gathering reports from user feedback and consolidating them into nice and clear packages for PG to digest. A prime example where this works perfectly is the relationship between the developer of Directory Opus (yes, it’s more or less a one-person deal), where this other guy on their forum, Leo, functions as a conduit of sorts, channeling correspondence between users and the programmer. He coordinates all valueable feedback that he spots on the forum, confers with the dev, then communicates precisely what they’re focusing on right now. All of that leads up to a sense of participation and awareness of the current state of the app. I sense good vibes in here as well! I’m glad this is an active forum!! But I think it might be worth a thought, PG, if you consider expanding your (virtual) workforce a bit. Let a few voluntary professionals have a lifted role and help you sift through/evaluate/consolidate user feedback. I also think the forum is pretty convoluted right now. Having just one single thread for all kinds of feedback seems a bit daunting to maintain. I suggest, at least, separating it into two sections: HELP and ISSUES. That way, you’d get rid of all kinds and flavors of prepended messages such as “Feature request”, “Suggestion”, “Just a suggestion”, “My thoughts” … or “Bug”, “Issue”, “Problem”, “3 problems”, “Help me, I’m stuck”.
It really took me by surprise and I couldn’t believe it when I first heard that WaveLab is mostly developed by a single person. While this is impressing, to say the least, my concluding point of thought is, that, maybe you need to streamline and outsource communication, solicit some assistance to help make priorities and evaluate user experiences, sort out the forum, organise where and how to post issues, open up for more qualified beta testers, etc. If you are to manage all this by yourself, PG, I’m always going to feel a small degree of pain posting messages (not to mention the huge pain I’ll have posting this behemoth crapload), because I can only imagine how much time that takes away from actual coding.
(And I hope Steinberg moves to the modern Discourse forum one day.) Cheers, Henrik.
If there’s one thing that should NOT be outsourced IMO, it’s the presence of Philippe in this forum. I think it’s a great asset to an already great software to have the person in the know answer questions directly.