When developing software under time pressure (the only way it ever happens in reality), there’s often many conflicting requirements that need to be weighed against each other, such as getting features out quickly, fixing bugs quickly, and, uh… just anything quickly!
When it comes to developing the Redshift 6 firmware, there’s a number of principles we’ve tried to stick to, and I’d like to write a little bit about them, and how they’ve lead to certain choices in the order and pace that we’re adding features.
From the beginning, we’ve known that the Redshift 6 will probably never be “finished”, in the sense that we will continue updating and adding features as long as we have new ideas, and right now it seems that there’s enough ideas to keep us busy for years even after completing all the features announced this far. To keep that from becoming a problem when it comes to old presets, one of the big principles is that we will never break preset backward compatibility on purpose. In other words, a newer firmware can always load presets saved with an older firmware, and the preset will sound the same as it did on the older firmware. We hold to this strictly for stable releases (except if fixing clearly buggy behavior absolutely requires letting the sound change), in beta releases we do our best, but reserve the right to change sound relative to an earlier beta of the same cycle if there’s a good reason. Even in beta, you will always be able to load old presets, barring bugs (of which there were some during the 1.3 beta cycle).
Another principle is that what we release should be easy to use (relative to its inherent complexity) and fit coherently to the whole and to features that are planned in the future. That doesn’t mean bug free (we wish it would, but that’s just not realistic), nor does it mean that all possible features are there, but that things don’t feel broken, don’t overlap too much, and don’t prevent future expansions. One of the detailed implementations of the easy to use principle is that there are no “page 2″s, i.e. there’s always just one page behind every physical button (although that page may depend on the selected engine).
Holding on to these principles comes with a cost though: just before releasing the synth, the firmware had many more features than the eventual release 1.0 had, and many of those features are not back yet. The problem was that some of these features were not in their right place, or not completely thought through, or somehow felt lacking. We did have lengthy internal discussions about keeping them and improving on them later, as we had ourselves used them to good effect on the launch video. However, the ultimate problem was that once we add any feature, we can never remove it, or change it (too much, small changes can be compensated by automatically adjusting old presets when loading them), as that would break preset backward compatibility, so we would not necessarily be able to improve what’s already out there. Even if it didn’t break preset compatibility, it would be against the second principle, as the unfinished features would not have felt like a part of the whole.
Of course, all these features will come back in one form or another once we have finalized them. Let me list some of the things which we had, and for some of which actually code exists in the current firmware, but they’re not accessible in the UI yet:
Engine switching:
This is implemented on the voice side and works well. However, the implementation we had on the UI side was basically hacks piled on top of hacks, and there was no feedback to the user to see which engines are available etc. This needs to be rewritten on the UI side before we bring back more engines.
“Demon Core” oscillator engine:
An oscillator engine more or less replicating the functionality of our Demon Core module. Primary features are that you could choose only one waveform for the whole stack, but on the other hand you could spread them on octaves (or other intervals) for a kind of a transistor organ’ish sound. The phase sync features were also there. Since there’s no noise osc, this engine could use the full 16 waveforms for stacking, and on the other hand since the minimum stack size is one (the dual osc always has at least two plus noise) this engine could have up to 16 paraphonic voices.
This engine was left out at release because of several reasons: it overlapped with the planned dedicated Phase Sync and Partials engines, the parameters were spread out over two pages breaking the no page 2 rule, and we just weren’t sure if this is a good cohesive combination of features for a polysynth. Indeed, the idea for the Phase Sync and Partials engines basically came out of splitting the two main use cases of the Demon Core engine into dedicated and better targeted engines.
Most use cases for this engine will be possible again once we have the two new engines mentioned above. Whether some version of this engine itself will make a come back one day depends on if we feel that something important was still left out after implementing the new engines.
Oscillator “phase sync” in DCO:Dual oscillator engine:
The Dual Osc engine had the possibility to reset all the oscillators on note on, which we’ve called phase sync, in analogy to the same feature in the Demon Core Oscillator. In addition, it was possible to shift the sync time, i.e. synchronize them such that they would hit perfect sync some prescribed time after or before note on, which gave rise to all manner of phasey, burpy, and snappy sounds.
The sync features were removed primarily because they added six more controls to the oscillator, inevitably leaking out to a second page. There was also two more controls for fine tuning the tone of the noise generator, which took up the top two slots.
The phase sync features will be enabled in a much more advanced form in the Phase Sync engine, but we are also bringing back a very simplified version of them to DCO:Dual in firmware v1.4. The noise tone controls are likely to make a come back at least in a drum oscillator engine. In principle they would fit the currently free top two slots, but we’re reserving them for at least a while more in case we come back with a better use for those slots. Remember, if we use the slots for the noise controls, then we can never take them away since that would break preset compatibility (we could move them, but where to if not page 2, which is forbidden?).
Phaser filter engine:
This engine configures the filter as two deep notches, i.e. a four pole phaser, with control over the notch separation, notch width, and “skew”, which basically deforms the notches turning the shape from a phaser to more like a combination of a phaser and a high or low shelf, with resonant peaks next to the notches.
The reason this was left out was that there were some design issues to consider, and we couldn’t go back on these decisions if we got them wrong:
- What does “Resonance” do in a phaser? Probably notch width, but then should it work in a way that it’s technically resonance, in which case max resonance has the smallest notch width, i.e. smallest effect. So in terms of effect strength it would work opposite to the normal. On the other hand, if widest notches were at max resonance, that would mean it would be common to use the phaser with resonance turned up to the max, which sets you up for a nasty surprise when switching to an engine that’s self-oscillating.
- The “Skew” control: is this too weird for what we’re calling a “phaser”, or is it just perfect? It would be the logical control to map to the dedicated Mode control, as it has a similar effect to Mode in the Classic filter engine
Both of these are quite tractable questions though, so the phaser engine is likely among the first to make a come back once we get the engine switching reimplemented, and implement visualization for the phaser response.
Formant filter engine:
The formant filter is a relatively simple affair, using two resonance peaks to implement five different formants, and allowing interpolation between them. Mode controls the overall shape from low to band to highpass. Having only two peaks means that it’s not really super effective in talking synth applications, but it’s more than effective enough to do a very nice synth choir, for example.
Again, there were some design decisions that we didn’t have time to resolve to our satisfaction:
- Resonance: for a formant filter, resonance should basically do what is says. However, the proper range of the control is not that obvious. If the resonance actually goes to zero, then it’s not really a formant filter, so should there be a lower limit on the resonance? On the other hand, the control range where it’s clearly a formant filter is relatively narrow, which might feel broken, since it’s expected that resonance is usually one of the more dramatic controls. Should the formant filter be allowed to self-oscillate?
- The formants are arranged circularly, similar to how the characters are, which means the interpolations are between fixed pairs. Should that be adjustable? If yes, how?
Again, both questions certainly have answers, so the formant filter also won’t be long in the making once we have engine switching. Visualizing the shapes is probably the biggest work (or maybe we should visualize the vowels corresponding to the formants instead?).
Pole mixing filter engine:
This is basically an implementation of the classic pole mixing responses, as made famous in Oberheim Xpander and Matrix 12 (though apparently the Siel Mono Synth was the first commercial synth to have one). We don’t actually have any resistor networks to sum the intermediate responses, but we can use the shaping VCA’s in our filter to achieve the same responses and a few more. Here’s the complete list: Lp1, Lp2, Lp3, Lp4, Hp1Lp3, Hp1Lp2, Bp4, Hp2Lp1, Hp3Lp1, Hp4, Hp3, Hp2, Hp1, Bp2, Notch, Hp1Notch, Lp1Notch, Hp1Lp1NotchTopTilt, Hp1Lp1NotchBottomTilt. I’ll leave it to you to decipher the abbreviations!
This is actually quite straightforward and workable as is. However, there’s a few extra features that we’re considering, and which change the sound, so again can’t be done after the filter engine is released:
- The responses could be interpolatable. That takes a bit of work to make sure the intermediate states make sense, or at least are interesting.
- Currently the response shapes don’t depend on Character in this engine (through gain staging, detuning etc do, so Character is by no means disabled). There are however some ideas to make them respond to Character in interesting ways, but that would require a little bit of work, and some testing to make sure everything sounds good.
- There’s two different ways to implement the interaction between resonance and selected shape here, we implemented one but would like to try the other and hear how it sounds.
This engine could see the light of day relatively quickly, if we just decide to put it out without Character dependence, interpolation and with the current resonance behaviour (maybe paving the way for an “Advanced Pole Mixing Engine”?), or it might take a while if we explore all the options. The latter is more in accord with our principles though, since having two engines that only differ by one being better than the other is confusing and suboptimal.
Effects
The DSP pipeline and mechanism to swap out different effects engines exists in the voice code. A straightforward digital stereo delay also exists, but is not implemented in the UI. Once again, time pressure prevented us from finessing the control set of the delay (the biggest question being what input pan / balance options to offer), and having just a delay seemed more incomplete than no effects at all.
As for the upcoming effects, we also have a running code for a good sounding reverb, licensed from Signalsmith, which just needs to be integrated to our effects framework. For the chorus, the basic idea is really just modulating a delay which is simple, though we do intend to do quite some work to make it sound more like a classic analog synth chorus rather than a straightforward digital chorus.
The distant future
Note that the above listed things are (mostly) what we have existing proof-of-concept code for, and that has in some form already existed in the firmware. Once we complete those, and other remaining front-panel features, there’s a ton of exciting ideas in the works for both oscillator and filter engines, and a few thoughts for effects engines too. More about those once we have proofs-of-concepts implemented. If you’re impatient to hear about those, we have leaked some of the ideas in our Discord, and are always open to hearing any ideas you might have!