• Double Dry/Wet, Velocity Curve, and Denote are now free!
• Version 2.0 of Dual CV Source is out now, with a permanent price drop from $45 to $29, and a half-price launch discount

This will be the lowest price of Dual CV Source for a while, so be sure to grab it during the discount window!

~

This post is something of a continuation from my previous post, which talked about where I’ve been for the last couple of years (working on AAA games). In this post, I’ll start with some background on Dual CV Source version 2.0, and end by talking about why I’m releasing my other devices for free.

Work on Dual CV Source 2.0 started before 1.0 was launched. When I was writing the user manual for 1.0, I found myself writing a section on how to transpose notes. MIDI notes have values from 0 to 127, corresponding to notes C-2 to G8 (with Reason octave numbering). Reason CV maps this range to floating-point values between 0.0 and 1.0.

In order to transpose notes, you need a way to generate the value 1/127. Dual CV Source has a division operation, which is probably a little easier than remembering the number 0.007874. But, either way, you need one Dual CV Source device to generate that value, and a second one to do a multiply and the actual transposition. Not user-friendly.

It would be much easier if Dual CV Source just let you enter semitones directly. I roughly designed the feature before launching 1.0. It was fortunate that I did, because it required expanding the range of the Offset control from [-9, 9] to [-10, 10] — something that would have been impossible to change later, due to Reason’s backward-compatibility requirements.

(The device needs a way to represent the value of 1.0, so that it can pass through values unchanged for things like visualisation. With 10 octaves (offsets 0 to 9 inclusive), it can only represent values up to 120 semitones, less than the 127 required. I doubt anyone has ever looked at the Offset control and wondered why it had this seemingly unnecessary extra range. But, if you have, well, now you know.)

In version 2.0, when you change the Magnitude control to “Octave”, you enter the new semitone mode. In this mode, Offset controls the number of octaves, and the Fine control changes to a stepped Semitone control. The displays will show semitones with the following symbol:

This symbol is something that I came up with, reusing the LCD elements that already existed for displaying ♯ and ♭. It looks something like an ‘S’, and something like a stair-step: a reasonable representation of “semitones”. This ended up being far more readable than an abbreviation like “St” (S is identical to a 5) or “ht” (for half-tone), when placed adjacent to the numbers in the digital display.

With that, there is a way to represent semitones in Dual CV Source. Dual CV Source already has a button that adds the value of Channel A to Channel B, allowing transposition, but this means that the result of a transposition ends up on Channel B. In version 1.0, the note-related features — digital note display and Key Snap — were only available on Channel A. Version 2.0 adds those same features to Channel B.

The other major feature added in version 2.0, continuing the theme of note manipulation, is the new “spread” Key Snap mode. The original Key Snap mode just snaps to the nearest note in the scale. The new “spread” mode puts equal spacing between notes, giving more musical results when sweeping through a range of values.

Also in 2.0 are a number of graphical improvements. The Advanced panel looks a lot nicer, as well as clearer, with its black strips and orange switches.

Old:

New:

Far more complicated was making some display elements high-resolution. For version 1.0, I had implemented a way to render bitmap graphics in a Reason “display” element, in order to fit the functionality I wanted into a 1U-tall device. This stopped working as soon as Reason 12 came out with support for high-resolution graphics. Reason has some strict limitations on how controls and toggleable elements can be layered, and almost the entire device device is already toggleable with the Advanced panel. With some trickery, I was able to get elements like the Scale menu and the Sustain icon to display correctly and in high-resolution, in version 2.0.

Speaking of graphics-related complications, in Reason 11 and earlier on Windows, if you created 37 Dual CV Source devices, Reason itself would crash, by running out of Windows graphical resources. This ended up being caused by the way I was displaying all of the polyphony markers on the back panel. For anyone still on Reason 10 or 11, I found a different technique, and this is now fixed. Sorry it took so long!

(Shout out to PoohBear for discovering that one. He’s the sort of fellow who would create 37 copies of DCVS in earnest. Fortunately for him, we found a registry key that could increase the Windows limit.)

And that’s about it. I’m still very proud of Dual CV Source, a device that offers an enormous amount of power in just 1U of space, and has features that you won’t find anywhere else!

~

Let’s talk about my other devices, which I am now releasing for free.

In my previous post, I talked about how Reason 13 came out with a new Gain Tool that looks suspiciously like Double Dry/Wet.

I’ve since had a chance to play with Gain Tool, and what I said in that post holds true: I’d expect people to use Gain Tool before Double Dry/Wet in most “I need a quick way to mix this” scenarios. Gain Tool won’t do the fancy two-layer Dry/Wet thing that Double Dry/Wet can do, but you can construct that effect using multiple Gain Tool instances.

One big advantage of constructing it using multiple devices is that it forces you to not create loops in your audio chain, which is something that Double Dry/Wet encourages! A loop is when the audio path comes out of one device only to end up going back into that same device. This means that the returning audio ends up delayed by the audio buffer length, relative to the original input. If you don’t apply a correction for this delay, you end up with an audible comb-filter effect. To solve this problem, Double Dry/Wet has a delay-compensation feature (which I talked about back in this post).

But that button is manual and fiddly to use. It can’t remove the delay, only ensure all audio has the same delay. It also doesn’t work properly anymore! Reason 11 changed the way audio is buffered, for higher performance, and that feature in Reason must be disabled for Double Dry/Wet’s delay compensation to apply the correct amount of delay. The latest Double Dry/Wet user manual suggests a multi-device construction to avoid the issue.

I still love the effects you can create with Double Dry/Wet. But, now that Gain Tool is built-in to Reason, the amount of added value Double Dry/Wet provides is much smaller.

Then Reason 13.1 came out, with a new Note Tool…

First, it was awesome to see Ryan using my Denote device in the official video demonstrating Note Tool (timestamped link).

Denote was designed exactly for this purpose: a simple, large display for inspecting playing notes — it’s as large as possible, while being pixel-perfect. As an added bonus, you can click individual notes to mute them.

With Note Tool’s filter section, Reason now has a built-in way to display and filter notes. That part of Note Tool is not as sophisticated or readable as Denote. But the additional value that Denote provides to Reason users is now just that little bit smaller.

Given that I’ve regularly given away Denote for free in sales (hoping to drive traffic to my other devices, I am not sure how successful this has been), I feel like now is the right time to make it free permanently.

Finally, we come to Velocity Curve.

Now, Note Tool:

I don’t know about you, but that looks a lot like a curve to adjust the velocity. A “Velocity Curve”, if you will.

Along with its velocity range filter, Note Tool can do the same velocity adjustments that Velocity Curve can do. And it’s built-in to Reason. Sure, Velocity Curve has a drawing mode, but that is a fiddly-to-use, esoteric feature. So, once again, the additional value that someone would get by buying Velocity Curve is much smaller.

With Reason 13’s Gain Tool, and 13.1’s Note Tool, these three useful little devices of mine are no longer as compelling as they once were. I don’t feel I can justify charging money for them anymore. For me, making Reason Rack Extension devices is a wish-I-had-more-time-for-it hobby, and not a major source of income. So now feels like the right time for me to give them away for free. I hope you enjoy!

It does feel like Reason Studios has taken just a little bit of inspiration from my devices, here. I have no idea if that’s true or not, but it feels good to think that those propellerheads liked my devices enough to borrow some ideas, so I’m going to believe it anyway.

If you’d like to support my work, check out my devices in the Reason Shop, download the free ones, and buy a copy of Dual CV Source.

A lot has changed in 4 years. I’ve been working in AAA game development, mostly working on netcode. I got married, bought a house, lots of life stuff. I also grew a beard.

I have the ‘ok’ from my employer to work on my Rack Extensions as side-projects. Maybe I’ll ask for the ‘ok’ to do some tiny game development stuff in the future. It’s more of a “spare time” question for me, than anything else.

I have an update for Dual CV Source coming soon. It’s been coming soon for years, but it’s taken a long time to find space to do the dozens of tiny polish things needed to get it released. I’ll post an update when it’s ready.

I also have some plans for a tiny feature update to Denote, but I haven’t even started that yet.

In the mean time, Reason 13 has come out, with a built-in device called “Gain Tool” that looks suspiciously like Double Dry/Wet:

I haven’t tried Reason 13 yet, so I am going off some of the pre-release videos. It looks like Double Dry/Wet is still more versatile, with two-level parallel mixing, and an explicit “dry/wet” setup (basically: they have 3 knobs, I have 6). But it looks like Gain Tool reduces the utility of some of my “clever” design choices, that also let you use Double Dry/Wet as a basic crossfader or mixer tool.

Because of that, I’ve dropped the price to $9, so now is a great time to get it!

This is a device that I am incredibly proud of. What started as a simple way to get a precise fixed CV value, evolved into a feature-rich – yet tiny – general-purpose CV utility.

You can get it now from the Rack Extension shop.

When designing Dual CV Source, I set myself two rules:

Rule 1: Keep it 1U in size.

This was a real challenge, given how much functionality I wanted to pack in. But it was important for me to keep the device small, so that it wouldn’t feel like it was hogging rack space when you just want to drop in a quick static value source or attenuverter.

Rule 2: Don’t implement anything time-based.

Knowing what to cut is important. This means: no LFOs and no envelopes. Fortunately Reason’s built-in Pulsar device has those features. And keeping them out of Dual CV Source ensures that the user interface is simple and understandable, and it simplifies the implementation.

Within those two restrictions, my goal was to implement every major utility function you would find in a typical modular setup. So there’s a MIDI-to-CV, a quantizer, a sample-and-hold/track-and-hold. You can offset and multiply signals. And there’s a variety of other maths and logic functions.

I did cheat a little bit on Rule 2 by including a latched random number generator. While it would have been simple enough to just generate purely random numbers, I felt it was important that the random numbers were consistent between different playbacks, so the random number generator works from note timing and note values. So the same note in the same place will give you the same random number – no matter how you change the other notes in the song, the BPM or the sample rate.

(I felt that random number generation was such a common use-case that it needed to be a built in function, rather than having the user set up a random LFO and a latch. There’s also a built-in Velocity Hold function for the same reason.)

To mention a few more features: The whole device supports up to 4-channels of polyphony. The MIDI-to-CV is configurable (choose your note mode, retrigger and sustain options). And there’s support for the full CV range (values up to ±10,000).

Oh, and the displays are fully interactive! So if you need to enter a precise value or note, you can modify each digit individually.

There’s so much in Dual CV Source that I wrote a complete user manual, and it came in at a healthy 20 pages. I hope that the device is intuitive enough without needing the manual, but if you want to know exactly how something works, the details are there.

If you use CV in your songs, then my hope is that Dual CV Source will become an indispensable part of your workflow. And if you don’t use CV yet, then perhaps Dual CV Source – with its ability to digitally and graphically visualise CV signals – will help you get started in this exciting layer of production.

Get Dual CV Source

Version 2.0 adds two new features: Delay Compensation and CV control. The latter of which I am incredibly excited about!

Delay compensation fixes a design oversight in the original device. I’ve written a more extensive write-up about it here. The short version is this: if you form a signal loop – which the primary way to use Double Dry/Wet – you introduce a delay between the output and input sides of that loop.

This causes an unwanted comb filter effect. Now you can get rid of it by hitting the “delay compensation” button on the back panel.

CV control has been sitting in my “todo” list since the initial release, as something I’d add eventually, when the opportunity arose.

Now that I’ve added it: I should never have waited!

Having CV control has been a complete revelation! It takes Double Dry/Wet from an intuitive-yet-static signal mixer, to a modulation powerhouse. The sounds you can make, by dynamically switching between two effect chains, are wild! Hook it up to a LFO or an ASDR envelope, and you will not be disappointed.

I am going to be having fun playing with this for a long time, and I really recommend that you try it out.

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

As some of you may know from my occasional blather on Twitter, I have been making a transition away from the game development industry. The long-story-short is as follows: making indie games at the moment is financial suicide.

To quote Jake Birkett (Gray Alien Games): “In 2013 median indie games made approx. $110K and top 25% made $590K.” So far, so good. He continues: “In 2019 median indie games made $1400, and everything below that basically $0. Top 25% made $12K, which is obviously not sustainable. You have to be in the top 5% of indie games these days to make $413K”.

And here’s Mike Rose (No More Robots) saying much the same thing. And here’s Sergey Galyonkin (Steam Spy) from two years ago, with the very salient point: around 30 games are released per day on Steam. Good luck getting noticed in that noise. There are too many games.

It was around two years ago that I started making my (surprisingly long) transition away from games. It was also at that time I started my first of many attempts at this article. I’d just finished work on River City Ransom: Underground, including spending a year in post-release support work: it was a slog, and financially it did “ok-ish”.

After River City, I tried a few other projects, some game-related and some not, mostly with RCRU Producer Daniel Crenna. (If RCRU was a technical slog for me, it was an everything-slog for Daniel, for which he deserves a lot of credit.) Unfortunately none of those projects really took off.

One of my terrible secrets from working on RCRU is that, over the course of development, I stopped playing video games. Since then I’ve tried. Steam helpfully tracks play time so I can estimate that, in the last two years, I’ve spent around 30 hours gaming. And those games were… fine.

Original versions of this article had sections dedicated to my disdain for modern games, from exploitative monetisation, to shonky asset-flips, to a demanding community. All true, of course, but all of it a self-unaware digression from the fact that I have personally lost my passion for games.

Losing my love of gaming and game programming has been confusing and a little sad. It’s something I have had with me since I was a child. But accepting it has also been incredibly freeing. It opens me up to pursuing something that I have also loved since childhood: Music.

To that end, I have started making plugins (“Rack Extensions”) for Reason, an excellent and fun DAW that I have been using since version 1.0. Reason is notable for its joyful virtual rack user-interface metaphor.

Making music software, Rack Extensions in particular, is an excellent match for my skill set. I have always been, at heart, an engine and tool programmer: I love writing tight, high-performance code (of the kind critical for real-time audio). I love making things that other people can use to have fun and create. And there’s something special and game-like about making user interfaces that aren’t just a collection of parameters.

I’m also a somewhat-competent musician. This is something that I am actively working on improving, so stay tuned for that.

In the background I have been working on making Rack Extensions. So far I’ve quietly released three onto the Reason Studios Shop – here is the belated fanfare – You can buy them right now!

I admit that these are fairly simple devices. I wanted to start small. I have several other devices in development that start to dial up the sophistication. And, of course, all of these devices have been lavished with the care and attention that I like to be known for: high quality, fast, robust code, and carefully and cleverly designed user interfaces.

If you’d like to keep track of new devices as I release them, subscribe to my RSS Feed, or follow me on Twitter.

Daniel asked me to show him how to do the kind of game-engine programming that I did on RCRU, and has been kind enough to allow those sessions to be shared on YouTube so other people can also benefit from them.

The second announcement is that I have my first open source project up on GitHub: FNA Template.

It’s a simple, cross-platform template for making FNA games (FNA is an excellent XNA reimplementation). It is the same codebase that we’re using in the GameDev Coaching series, if you want to follow along.

Watch Video

In this final episode of River City Ransom: Underground: Underground, I explain how the combat AI works out what areas are in danger of being hit, and how it lines up its attacks, as well as one last look at the move test tool.

Get River City Ransom: Underground now from Steam or Humble.

We had a few nasty bugs crop up on day 1, and we fixed the worst of them right away. It’s now been two weeks, and we’ve just rolled out the much larger fix for the infamous “multiplayer save bug”.

If you follow me (@_AndrewRussell) or the game (@rivercityransom) on Twitter, you’ll know that the change set for this clocked in at around 3.5 thousand lines of code. This represents about 1% of our total source code (and close to 2 weeks of my time). It really is a massive change.

This post is to explain how such a difficult-to-fix bug ended up being shipped in the first place.

First we need to start with a small piece of technical information: In a networked game, the amount of data we can add to the game state with a joining player is tiny. Maybe a few hundred bytes at most. When I wrote that part of the netcode, I inserted a warning when the size exceeded 64 bytes.

(Details: Our game is P2P and supports drop-in-drop-out at any time, including support for host-migration. This means that player join data can be buffered, replayed, and re-transmitted almost arbitrarily. This starts to become an issue if multiple join and leave events happen in quick succession, particularly across a host-migration.)

The reason this “player-join-data” feature was added to the netcode was specifically so we could allow players to bring their list of unlocked characters into network games, play as them, upgrade their stats, and unlock new characters. The further intention was that players could keep those changes across different network games, as well as carry them into single player.

Unfortunately, the amount of data required by the unlock list was significantly more than was safe to transmit when joining (kilobytes). And, even with substantial data packing work, impossible to fit inside the 64-byte warning limit I had set much earlier in development.

(Additionally, there is a limit on the total size of the “live” game state. And having four full unlock lists in game would have exceeded it.)

This left two other options: Simply use the unlock list of the host (the same as couch play); or allow the joining player to bring one of their characters into the game with them. For the vast majority of development, we went with the first option – as it required zero extra implementation effort. But we did keep the second option in the back of our minds, to perhaps implement when development time became available.

Then, about 4 days before we shipped, Daniel decided that this feature – in the form of the second option – was important enough for us to add at the last minute. (Meanwhile I was coming down with an extremely bad cold, made worse due to the stress and crunch time of launch.)

This was obviously too close to launch to do sufficient testing, or even to properly consider the ramifications of this change. This was further exacerbated by the fact that the change was purposely left out of patch notes (there were 3 more beta releases after the feature was added), explicitly because there were some unfixed bugs in the initial implementation. I am hazy as to whether the bugs were actually fixed before launch, but suffice to say the change never ended up being included in any beta patch notes.

Which brings me to the central thesis of this post: More is Less. By adding this feature, the menu flow when joining an online game was changed from this:

[Select game type] → [Select game to join]

[Select game type] → [Select a save] → [Select a character] → [Select game to join]

So, despite the fact we had added a feature to the game (the ability to play online as a character from your save), it was rightly perceived by players as a critical data-loss bug!

During the beta, where we did not present the save screen, no one batted an eye at the fact that we didn’t save characters in online play. But, after launch, with hundreds of players encountering the new menu flow, it immediately became our number one user complaint. (Even more than any of our actual data-loss bugs.)

So I have spent the last two weeks doing little else besides rewriting the game’s unlock system: Each character can now have their own unlock list, local multiplayer characters will share a list, that entire list comes with you into an online multiplayer game, and it is always saved back into the save file that it came from, even online.

Most of the work involved fixing the many systems that were written with the assumption that there was only a single game-wide unlock list. But there was also a great deal of work packing the data, so that the unlock list could be sent across the network at a reasonable size (238 bytes with all unlocks and no inventory). Plus I’ve fixed all of the bugs around unlocks and save games that I could find in the process.

River City Ransom: Underground just got significantly better. Especially for multiplayer. Now would be a great time to go and play it!

Watch Video

In this video I talk about how we handle local obstacle avoidance – that is, we make sure the AI doesn’t get stuck on crates and other dynamic objects.

Some minor corrections:

• A typical, modern x86 CPU L1 Cache is 64kB. But that is split into 32kB for data and 32kB for instructions.
• The local dynamic heightmap used by LOA is actually dynamically sized to be as small as possible. The 64×32 one is only used for debug display.
• This is the last in a 5-episode recording session, but episodes 3 and 4 (that is: #13 and #14) got re-recorded.