Waveform automation comparison by AdmiralBumblebee didn't turn out well (last place)

[vitocorleone123]

http://admiralbumblebee.com/music/2019/ ... form-10026

Is this a bug, or at least something that can be improved upon in Waveform?

tempo to 120bpm and created a fade from the start of the project to bar 2. Then I rendered 2 full bars

#1 Digital Perfomer 10.0 audio fades very nicely


#13 at last place Waveform 10.0.26

[DrApostropheX]

Is that actually audible though? I'm really loving the workflow in Tracktion. There are some minor annoyances that point me back to Reaper, but every time I fire up Reaper with its hundreds of pulldowns with thousands of options each and with its tiny Windows98 text (or at least that's how it feels to me) I just feel old and tired and move back to Waveform until I find something else I can't live with (sometimes I switch DAWs several times a day because I'm nitpicky and fickle).

There is a perfect version of Tracktion out there in the DAW ether, though, and I know that the devs will hit upon it eventually without losing what makes the app so special.

[dRowAudio]

It looks like a bug that we can hopefully fix.
(When we get a chance to look at it though...)

[Robert Randolph]

Is that actually audible though?

Yep.

After you A/B with a clean modulation it's pretty easy to notice.

It's one of those things that you need to learn to listen for, but when you do... you can't unhear it.

I'm really loving the workflow in Tracktion. There are some minor annoyances that point me back to Reaper, but every time I fire up Reaper with its hundreds of pulldowns with thousands of options each and with its tiny Windows98 text (or at least that's how it feels to me) I just feel old and tired and move back to Waveform until I find something else I can't live with (sometimes I switch DAWs several times a day because I'm nitpicky and fickle).

There is a perfect version of Tracktion out there in the DAW ether, though, and I know that the devs will hit upon it eventually without losing what makes the app so special.

Like I say in the video, I wouldn't switch DAWs over this. Every product has benefits that far outweigh things like this.

I happily use Waveform for all of my personal work as I think it has some workflow benefits that are overwhelmingly beneficial.

This video series exists to show objective differences between products, because I hate the "All DAWs sound the same" or "All DAWs are essentially the same..." mantra that gets repeated ad nauseum.

The sooner people realize that products are different, the sooner people can 'pressure' the software developers to make better choices in their allotment of development time.

It looks like a bug that we can hopefully fix.
(When we get a chance to look at it though...)

You know my e-mail if you need any details, data or want to yell at me

I'll happily do follow-up videos/content on any DAW that responds by improving... (especially if it happens before I start my Waveform 10 review )

[vitocorleone123]

Is that actually audible though?

Crap. With all the pasting I was doing I left off my question I had in mind: "This doesn't seem critical, and how audible is this in real life?"

Totally the right questioning.

I also love Waveform and use it pretty much daily (though it's been kinda crashy for me lately this isn't unusual for this state after a new release before it gets better).

[vitocorleone123]

..

[spoontechnique]

Even if you don't notice these artifacts on just a clean volume automation, I'm pretty sure you'll notice them after processing.

[dRowAudio]

So I've looked in to this in detail and can confirm the artefacts come from the fact that as an optimisation stage we flatten automation curves in to 1/100th second sections and use the closest one when reading automation.
If we didn't do this we'd have some very complex bezier maths calculation in the audio thread we want to avoid.

There are a couple of ways around this and I'd like to get your take on them.
1) We could simply take the performance hit and not do this optimisation step which could increase CPU load
2) We could do the optimisation during playback but render without it to provide higher resolution
3) We could possibly provide these as an option for those that prefer accuracy over performance

I can discuss all this because all the code is open source and viewable by anyone. Software development is often about these trade-offs so I'd be keen to know how serious everyone thinks this is? Bearing in mind it'd been like this for ~20 years and no one has brought it up yet

I'd also like to point out that it's only really possible to get a completely clean signal like this if you render at the source file's sample rate and bit depth. As soon as you start time-stretching, resampling or changing bit depth you're going to get some artefacts, that's just how digital audio works...

[fde101]

3) We could possibly provide these as an option for those that prefer accuracy over performance

Choices are good...

I would suggest a checkbox somewhere in preferences to "Evaluate optimization curves at high resolution during playback" (or similar) which would be off by default, and a checkbox in the "render" windows to "Render optimization curves at high resolution" (or similar) which would be on by default.

[dRowAudio]

The problem is that the more choices you provide the more complex the software becomes and the more confusing it is for people.
Having a setting in the settings pages I can kind of deal with, but adding one to the render dialog feels a bit overkill.

Maybe the settings page one should be multiple choice?

[fde101]

Evaluate optimization curves at high resolution: (drop-down list): Never, When Rendering, Always

[fde101]

err, optimization curves -> automation curves... ugh...

[DrApostropheX]

I'm all for making it an option in the settings menu, but I would probably forget to check it before rendering out the file if it's something I had to turn on and off. If there's going to be more of these other weird math things down the line, maybe bundle them up as part of a "HQ Maths (Increases CPU)" option in the settings (with the drop down never/always/while rendering).

[Steve Bolivar]

The problem is that the more choices you provide the more complex the software becomes and the more confusing it is for people.
Having a setting in the settings pages I can kind of deal with, but adding one to the render dialog feels a bit overkill.

Maybe the settings page one should be multiple choice?

Yes, definitely have the options in just one place.
Maybe "optimisation during playback" with radio buttons for on/off
and "optimisation during render" with same options.

[fde101]

Maybe "optimisation during playback" with radio buttons for on/off
and "optimisation during render" with same options.

That would be a checkbox. Radio buttons for on/off would be a simple waste of space unless there was a third option.

This also leaves open the question of what you are optimizing for: quality, or speed? If you define "optimization" to be improving performance by reducing the load on the system, then turning the optimization on would give the current behavior, and off would give the new behavior.

If you define "optimization" to be improving the performance by using the higher-quality data at the expense of higher system load, then turning the optimization off would give the current behavior, and on would give the newer behavior.


If you really wanted to use radio buttons for this for some reason, it would be better to label them for what they actually do:

Playback optimization: ( ) for reduced system load ( ) for higher audio fidelity
Render optimization: ( ) for faster render times ( ) for higher audio fidelity


That said, I can't think of a reason why you would want to render at a lower audio quality than what is used for playback, so I think that three options are sufficient:

Optimizations:
( ) reduced playback load and faster rendering
( ) reduced playback load with highest quality renders
( ) highest playback and render quality

This would be a more generic way of wording the options I had suggested above.


That said, I don't know that I agree with generically ganging performance options together. Maybe optimizations related to automation curves, but if you then lump in other unrelated optimizations you wind up in a situation where you are increasing the system load for automation curves when they are not a problem, in order to get some other improvement that you actually need, compounding the added load such that if you are already riding on the edge you wind up pushing the system past its limits.