Waveform 11.1.14 Public Beta - Announcing a new experimental engine and PDC fixes

[dRowAudio]

Hi all, as you may have heard on here we’ve been working hard over the past few months to rewrite the audio engine to fix some long standing issues.

We’re at the stage now where this is ready for some beta testing. As usual with beta software please only use this on new, test projects to avoid any issues with critical data and make sure to backup any existing data.

Firstly, download and install Waveform v11.1.14 from your Downloads page on tracktion.com. Once you’ve done that, open up the DAW and go to the “General Behaviour” settings page and enable the new “Enable experimental Engine processing” option.
To start with, use the default “Hybrid” processing algorithm (more on that below).

The main result of using this engine is that it should fix PDC in all of the situations we’ve been made aware of including:

• Across tracks

• Between multiple send/return auxes on different tracks

• Between multiple Rack instances on different tracks

• Any combination of Racks and auxes

• Within Racks with parallel branches with plugins of different latencies

• When plugins are bypassed they now maintain consistent latency

Additionally, depending on the layout of your Edit and its contents, you could see up to a 30% performance improvement from the non-experimental engine. I’d be keen to hear your feedback on this.

---

As I mentioned above, we have three different threading models we’re trialling to see what works best for different machines. Feel free to try them out and let us know how they differ on your hardware. Here’s a guide to what they mean and the behaviour we’ve seen with them.

• Signalling: Uses a signalling system for audio processing threads. This should be the least CPU intensive but has the highest jitter so the risk of dropouts is probably highest.

• Real-time: Tries to avoid any signalling primitives to give the most real-time safe operation. With this we’ve found typically ~20% higher CPU usage compared to the existing engine but a more consistent processing load so dropouts shouldn’t happen as easily.

• Hybrid: This is combination of the above two methods which should give good CPU usage whilst reducing the number of dropouts.

Although the experimental engine should sound the same as the old one, we have had to rewrite the entire playback graph so there is a chance we’ve missed something. If you notice any audio difference please let us know so we can fix them.

We hope you like the changes introduced in this release. It’s still a work in progress so any feedback is much appreciated.

Cheers!
Dave

[dayvyg]

Wow! That's a big thing to tackle in a minor release. Appreciate the effort and will give it a try when I get a chance.

Hey everybody, the more people test this and offer feedback, the better the outcome will be. Dig in!

Thanks, Dave!

d.

[astey]

Wow,wow, wow, wow wow!

[imstre]

How cool you are!
It will be great!
Thanks for the work and checking!

[UnionS8]

Just for the CPU load and sound issues comparison: if I'll turn “Enable experimental Engine processing” off, will I get the old sound engine from the previous release?

[JohnNoizz]

I'm testing now the new engine and... OH MY!!! there's a noticeable difference between the new and old engine, the new experimental engine sounds more precise, detailed and clean, made some test and I notice that with the old engine my kick, snares and claps they sound like a little "out of time", now with the new engine they sound accurate and on time, therefore they sound cleaner and more detailed in general (when you play the tracks together)!!!

Thank you thank you AND THANK YOU!!! This will help me so much on my productions (electronic music)

Something I notice too was now Waveform is more fast in general, editing audio is more fast, changing something in options is more fast, even with the experimental audio engine off, I don't know what you people did but it improved a lot!!!

Keep the hard work people!!! You're doing it GREAT!

[spoontechnique]

Monumental. Can't wait to try it out.

Unrelated Q: Waveform doesn't allow for rendering tracks with clips that are too short. Is this limitation intentional or baked in? I often do sound design with single drum hits, which rarely meet the length requirement. My workaround is to copy a hit of the drum a bit apart so it'll allow me to render the track. Extremely mild inconvenience, but curious.

[harvon]

with the old engine my kick, snares and claps they sound like a little "out of time", now with the new engine they sound accurate and on time

This "out of time" is familiar. Fast tempo tends to sound quite bad unless I convert tracks to audio and force them to precision. I've thought until now that it were a plugin matter.

[aMUSEd]

is this available for the OEM version too?

[spoontechnique]

with the old engine my kick, snares and claps they sound like a little "out of time", now with the new engine they sound accurate and on time

This "out of time" is familiar. Fast tempo tends to sound quite bad unless I convert tracks to audio and force them to precision. I've thought until now that it were a plugin matter.

In a way, it is a plugin matter. Plugins introduce varying amounts of delay. The host has to measure the amount of latency and delay the overall playback so that everything syncs. This is what Plugin Delay Compensation (PDC) is, in my layperson's understanding. It's a non-trivial task for engineers to tackle, based on how many complaints I see about most DAWs and their PDC. I suspect it's been an ordeal to implement in Waveform.

I'm not sure if it would apply to exporting, probably only playback. Although I have often noticed particularly laggy plugins can make tracks "render to a new track" noticeably out of time. Not sure if this would address that.

[PierreG]

with the old engine my kick, snares and claps they sound like a little "out of time", now with the new engine they sound accurate and on time

This "out of time" is familiar. Fast tempo tends to sound quite bad unless I convert tracks to audio and force them to precision. I've thought until now that it were a plugin matter.

With the old engine, my guess is that there were a decent amount of users who were not fully aware of the PDC issues and how they manifest in different scenarios. If you were using racks, especially multiple racks (or Aux Send / Returns) on one track, they were not being latency compensated between each other, with a delay equal to your audio buffer setting being interjected. If you were running at very low buffer settings, then you might not notice this latency, yet if you cranked buffers to 2048 or similar, you'd hear massive PDC issues, say around a full 23ms of delay happening. There was also the issue of certain single Rack scenarios not correctly compensating, and thus requiring the use of zero latency plugins to maintain PDC.

With all of this in mind, the tightness of the new engine is for sure rooted in all of this now being correctly compensated. There may well be other engine redesign factors that are helping the cause, yet I wanted to make clear what may have been happening for users without it being fully understood. I've struggled with this issue for the entire time I've used Tracktion / Waveform, which is over 16 years, so this is an epic moment, deserving of much celebrating!

[astey]

BR:
- Adjusting Look-Ahead Slider in Compressor VST (MDynamics) crashes Tracktion without warning.
- I cant open some VST3 plugins from vendors such as Fabfilter and Izotope. Tracktion marks them as "This plugin couldn't be loaded". Validating these plugins works flawlessly though.

Engine set to Hybrid. Windows 10.

[PierreG]

BR:
- Adjusting Look-Ahead Slider in Compressor VST (MDynamics) crashes Tracktion without warning.
- I cant open some VST3 plugins from vendors such as Fabfilter and Izotope. Tracktion marks them as "This plugin couldn't be loaded". Validating these plugins works flawlessly though.

Engine set to Hybrid. Windows 10.

Thanks for this BR. I had issues with VST3 scans with the latest betas, so I reverted to 11.0.21 and did a VST3 re-scan, which brought back all but Helm and Sphere vst3.dlls. All of my Voxengo VST3 plugs were giving the same error message you describe with 11.1.14 installed.

[PierreG]

VST3 scanning in 11.1.14 update: Re-installing 11.1.14 = VST3s still show up in the Plugins list, yet fail when inserted into an edit. They work in 11.0.21.

[JohnNoizz]

Well... found the first issues... now when I scan the VST2 and VST3 plugins there are many more with error messages, I have to scan again because some plugins was "missing" even if they are already there in the folder, so, after the scan they work but no very well, astey and PierreG described the same plugins that I have problems with (Voxengo and Izotope and many more)