Today I published version 2.0 of Double Dry/Wet. There’s an announcement post here.

The part of this update that I am excited about is the addition of CV control, and you can read more about it there, or try it yourself.

But the main purpose of this update, and the reason I had to rewrite (!) all of the audio code, was adding delay compensation support…

A device like Double Dry/Wet needs to handle delay compensation because it is a device explicitly about forming audio loopbacks. Devices in Reason evaluate their inputs and outputs in batches, every 64 samples. If you output audio in one batch, and that signal loops back to the same device, you will not receive the result until the next batch.

This adds 64 samples of latency. If you mix together the output (send) and input (return) signal without accounting for this, then you end up with a comb filter. Normal comb filters are made this way: by combining a signal with a delayed copy of itself.

If the signals are only partly correlated, such as with a heavy effects in-between (the normal use case, here), you only get a partial comb filter. But either way this “bonus” comb filter is not what you want.

The solution is really simple: add a matching delay to the dry (output) signal at the mixing stage. Double Dry/Wet makes it easy. Just hit the “Delay Compensation” button for the channel that has a loopback, and your problems are solved!

Well… sort of.

First of all, a designed use-case of Double Dry/Wet is as a serial effect mixer. This means you can loop through Double Dry/Wet twice. So there’s a second stage to the delay compensation, in case you need an additional 64-samples of compensation.

Double Dry/Wet does all of the maths required to make sure that all of these signals line up internally, for any setting you choose. It also reports any introduced delay to Reason so its delay compensation works properly.

This solves the common use cases. And, if introducing any delay is unacceptable, there’s a new page in the user manual showing how to connect up a pair of Double Dry/Wet devices in a splitter/merger pattern to achieve the same effect without introducing any delays.

…

But there’s still a problem. You see, Reason’s own delay compensation is quite limited. It can be summed up as follows: delay compensation only happens at the mixer, on a per-channel basis. There is no delay compensation within the rack itself.

This means that if you have any parallel signals, unless they have exactly the same signal path delay, they will arrive out-of-sync to Double Dry/Wet.

It also means that some signal path delay can get “lost”, as far as Reason’s mixer is concerned. If there is a parallel signal, it only ever reads one of the parallel paths – seemingly the first available path in rack-device-position order.

When this occurs, the dreaded “Non-Standard Routing Detected” warning light comes on. It’s somewhat well-hidden in Reason. You’ll find it on the back of a mix channel device with its programmer expanded. (Hot tip: you can manually correct the delay by adding an offset here.)

As far as Double Dry/Wet is concerned, there’s no reasonable way to deal with these up-stream delays. Rack Extensions are sandboxed such that they cannot “see” the rest of the rack, or read the delay of incoming connections.

The only real solution to this would be to have the user to manually enter the delays. This is awful. First of all, it’s wrong to ask the user for information that Reason already knows. Second: it would add massive complication to a UI that is supposed to be simple and easy-to-use. Third: the delay values would have to change whenever the sample rate changes or up-stream devices change. And fourth: I’d already rewritten Double Dry/Wet when I figured all of this out, and I wasn’t about to do it again!

At first I was very cross about this. I’ve solved a very similar graph-loop-breaking problem like this for a game before. Why couldn’t Reason? (The reason? Probably because it’s a hard problem, has performance implications, and sometimes you have to arbitrarily choose the “least bad” graph and hope for the best.)

But then, I took a shower, and I came to see this problem as an opportunity. There’s sadly no way to solve this within the confines of Double Dry/Wet. It will require a separate device. And I have figured out a design for a device that can solve this problem (and, importantly, would remain useful even if Reason also eventually fixes it).

(Just so I don’t Osbourne myself: it won’t be a replacement for Double Dry/Wet, it will be a stand-alone device. Although it will work really well in combination with Double Dry/Wet!)

So, look forward to that one. I’m excited to be working on it. In the meantime: buy my products! Double Dry/Wet is still an incredibly useful mixing tool, and I hear the CV control on the updated version is particularly awesome 😉