The previous post attempted to explain -- or at least guess at -- the inner workings of Dr. Wave.
I mentioned several times that this was among my favorite of all the synthesis methods currently provided by the OP-1; this is not to say that Dr. Wave is without flaws, as there are some UI quirks of varying severity which I think could stand to be addressed in some way.
Let us therefore turn a critical eye towards Dr. Wave...
Visual System
As I remarked in the previous post, the graphical aspect of Dr. Wave is both powerful and beautiful. The fact that the user is presented directly with the literal results of their actions allows one to learn the actions of each parameter very quickly and intuitively -- no mean feat considering that those same parameters are quite complex and involved, as attested to by the length of that aforementioned post!
In fact, the graphical interface of Dr. Wave is so effective and utterly excellent that one wonders whether one or more of the other synths would benefit from a similarly functional approach; Dr. Wave's gloriously useable visual feedback definitely puts most of the other synth engines to shame.
However, for all of its excellence, there remains one very markedly annoying aspect of Dr. Wave's graphical behaviour, which is frankly somewhat incomprehensible: when the synth isn't making a sound (that is, no keys are depressed), the display fails to update!
This bewildering decision results in a recurrence of the following usage pattern: I play some notes, and decide that I should e.g adjust the waveform from sawtooth to square. Therefore I turn the Blue encoder CW... but I see no visual change! I play some notes and the display suddenly jumps to reflect my previous adjustment -- and I find that I previously turned the encoder too far and as a result the waveshape is now midway through the triangle wave, rather than the square that I wanted.
Even worse, occasionally I forget this quirky (a less polite term would be aggravating) nuance and wonder whether the encoders have ceased to function! Then I find that I have unwittingly over-corrected a particular parameter, and I curse whoever implemented this particular fiendishly un-user-friendly behaviour.
As far as I can tell, there is no functional reason or useful purpose to this behaviour; visual feedback is simply being denied to the user. I'm unsure if this is in fact a bug, or merely an oversight.
It certainly can't be some sort of DSP-saving decision because in the worst case, the user might hold a key down forever -- therefore requiring the display to be constantly updated. This means that the cost of always refreshing the display must be currently factored into the CPU budget, so the current behaviour is simply wasting idle cycles for no apparently benefit -- and in fact a quite substantial useability penalty results. I really hope TE rectifies this in future versions of the software.
Anyway, it speaks volumes that, to my mind, this is really the only solid complaint that can be lodged against Dr. Wave's graphical appearance.
Unfortunately, other areas of the synth -- the parameters specifically -- are not as immune to criticism.
Parameters: Blue
Like most of Dr. Wave's parameters, Blue is continuously variable, smoothly wrapping around from minimum to maximum to provide an endless cyclical parameter space. As interesting and novel as this behaviour is, it does create the awkward UI result that if there is currently some amount of samplerate reduction (henceforth SRR) dialed in, the user is unable to determine a priori whether a CW or CCW rotation will produce a greater or lesser amount of SRR. There's literally no way to tell which direction the knob should be turned to affect a particular desired change -- it depends on whether you moved into the SRR region by previously turning CW or CCW, and whether you have passed the peak of this region where SRR is at a maximum; this is a frustrating user experience.
Whether or not it's worth spoiling the austere minimal simplicity of the current visual interface to provide some sort of feedback that would help disambiguate such cases is debatable; regardless, it's an annoyance.
Another annoyance, perhaps more minor, is that currently when sweeping continuously CW or CCW, you pass through two identical sawtooth waves; this is the region of the control space where SRR is inactive and the waveforms are at maximum smoothness. This seems somewhat redundant and awkward.
Moreover, the way in which waveshape and SRR amount are inextricably linked -- you cannot adjust one without also adjusting the other -- is a limitation that is perhaps needless.
One possible alternate approach to providing independent control over waveshape and SRR amount using a single encoder would be to separate the parameter space into three adjacent regions: [variable samplerate, fixed waveshape sawtooth] <-> [fixed (maximum) samplerate, variable waveshape sawtooth/square/triangle] <-> [variable samplerate, fixed waveshape square]. This would provide the user with independent control over waveshape and samplerate; additionally, this non-wrapping layout would ensure that it was always obvious to the user where they currently are in the parameter space, and thus which direction they should turn the knob to affect a desired movement.
Finally, the location of the SRR region relative to the waveshapes is perhaps less than ideal; currently the point of maximum quantization/SRR is located directly at the point where the waveshape is a perfect sawtooth. (At least, this is AFAICT -- the high amount of samplerate reduction makes it quite difficult to determine precisely the pre-SRR waveshape as it's rendered as only two or three samples.)
The result is that there is no point in the cyclical parameter space of Blue where the user can dial in a variable amount of SRR on a sawtooth wave -- the most harmonically rich (and therefore likely to be interesting when SRR'd) waveform. Instead the user can only select between pristine a sawtooth with no SRR, or an unrecognizably mangled sawtooth with maximum SRR applied.
I realize that this criticism might be utter hubris -- clearly Teenage Engineering are a thoughtful bunch and are thus likely to have tried all three waveforms as candidates for the position that sawtooth currently occupies, and selected the one they deemed best -- but nevertheless I wonder whether it might not be better to bury the triangle at the point of maximum SRR rather than the sawtooth, since the triangle is perhaps a less interesting as a candidate for variable SRR. (This is also the motivation for the above proposal of a three-region system where variable SRR is available on both sawtooth and square waves.)
Obviously, the ideal scenario would be independent control over both waveshape and SRR amount, but unless the current UI paradigm is drastically changed -- e.g pressed encoders or shift+encoder are introduced -- it remains an open problem how to accommodate such a control scheme.
One final thought is that it's somewhat unintuitive that the first parameter is controlling two variables, each at opposite ends of the signal chain. I can't see an easy solution to this, and it's not a big problem, but I do find it slightly unintuitive the way that the initial step (waveshape) and second-last step (resampling rate) are ganged together. Aside from Blue, the parameters are wonderfully layed out in a series whose order matches that of the signal chain; it's a nice little touch.
Anyway, I think that on the whole Blue is a very solid parameter whose design is more or less unproblematic, and these various criticisms I raise are definitely minor and subtle, and relatively unimportant.
Parameter: Green
I don't actually have anything specific to say about Green; I think that the way that TE have set up this control is wonderful. It's simple, it's intuitive, it's powerful, it's great.
Obviously, as with Blue, it would be nice to have some control over e.g the resonance of the filter -- it would greatly expand the palette currently offered. However it's unclear how this could be achieved without relying on a more complex interface (i.e the good old "press encoder" or "shift+encoder").
When SRR is active, the action of the filter can be somewhat lost -- drowned out or muffled. Changing the highpass cutoff is especially subtle and more or less moot when SRR is dialed in; possibly this is inherent in the realities of sampling and Nyquist frequencies -- it's inevitable that high-frequency changes will be inaudible and lost due to a low samplerate. Being able to boost the resonance (thus making the action of the filter more obvious and pronounced) might help counteract this somewhat, but a more interesting (and useful) approach would be to provide the user with the option to apply SRR (and Phase control, if it is applied at the same time in a single "resampling" step) before the filter rather than only after the filter.
Potentially this is impossible due to how the filter is implemented; given the discrete sample-based nature of much of Dr. Wave, it's possible that rather than calculating the filtering in realtime, TE have simply generated a matrix of [waveshape] x [filter] single-cycle waveforms -- precalculating lookup tables to replace realtime calculations. (I have no idea whether this is the case or even if it would be feasible; while a single-cycle sample might take up relatively little space, there are several dozen values for both waveshape and filter parameters, which means that hundreds if not thousands of such samples would be needed.)
Regardless, my proposal is simply that Green could be made to cycle twice instead of once -- similar to how Blue cycles through waveshapes three times (with SRR cycling once) before wrapping around to the start of its parameter space.
The first cycle would be the current setup: waveshape -> filter -> SRR, while the second cycle could be one in which SRR is applied pre-filter: waveshape -> SRR -> filter. In both cases the current behaviour of Green would be preserved -- i.e lowpass cutoff sweep followed by highpass cutoff sweep. This would be completely analogous to the way that Blue combines both waveshape and SRR controls together.
Because of the way that Green wraps around with highpass frequency sweeping upwards to eventually filter out the entirety of the input, this means that such a discontinuous change (swapping positions of SRR in the signal chain) could be hidden by having it occur in that inaudible gap between the maximum highpass cutoff and the minimum lowpass cutoff.
It's an idea anyway.
Parameter: White
We come now to what is, aside from the "graphics are frozen if synth is silent" behaviour, my least-favorite decision regarding Dr. Wave's UI: the mirroring of the White parameter.
Internally, the White parameter has a minimum and maximum value; let's say that -1 corresponds to maximum phase accumulator sweep speed with wrapping off (i.e the "pulsewidth" behaviour) while +1 corresponds to maximum phase accumulator sweep speed with wrapping on (i.e the "sync" behaviour). A value of 0 corresponds to "unity": the phase accumulator is at its slowest possible speed, taking a full interval (1/440 seconds in the case of a 440hz tone) to sweep across the single-cycle waveshape sample.
(Please refer to the previous post if you have no idea what I'm talking about! Also I apologize in advance if I'm talking out of my ass here and this is nothing at all like what's actually going on in Dr. Wave.)
Continuously turning the White encoder in either direction will result in the internal parameter moving either positive or negative, until it reaches -1 or +1 at which point it reverses direction -- all while the user is turning continuously in a single direction.
This "mirroring" has the terrible side-effect that the control has now become modal: the user can't know whether turning CW or CCW will result in movement towards +1 or -1, without knowing the previous history of the control. In other words, it's not enough to know the current setting, the user must also know "how they got there"; this previous state is hidden and inaccessible to users.
Not knowing which direction a parameter will move when a knob is turned seems like a terrible UI/UX decision, and it's not clear to me what the benefit of such a decision; frankly I can't see any benefit, especially where there are two perfectly viable alternate solutions: wrap the parameter (as with Blue and Green) or clamp the parameter (as with Orange).
It's possible that wrapping was decided against since it would result in a discontinuity; this might be avoidable by forcing the transition from +1 to -1 to take place during an inaudible state, just as Green manages to switch from lowpass to highpass continuously by having the highpass cutoff frequency sweep up past the top of the audible range. Perhaps allowing both Green and White to generate inaudible states was too ugly and awkward for TE -- this is understandable.
I'm not sure that wrapping is really a good decision anyway; it seems like simply clamping the parameters in the regular way -- the way that Orange and AFAIK all of the other parameters of all of the other synths are clamped -- would make for a much nicer user experience without adding any negative side-effects, consequences or limitations. Am I missing something?
Parameter: Orange
The final parameter to fall under the OP-101 microscope is Orange/Chorus.
It's a very un-subtle effect, and while it sounds great in many cases, it's also so distinct and so powerful that it tends to drown out all the other parameters when it's active, overpowering all but the most extreme changes to Blue, Green, and White. As a result, Chorus greatly undermines those controls and in doing so -- if you'll permit me to be abstract and metaphorical -- shrinks the parameter/possibility space.
Basically, once you turn Orange CW, Dr. Wave turns into Dr. Chorus.
The obvious solution, if indeed the strength of Chorus' character and the distinctive edge and movement it generates can be considered problematic, would be to somehow allow the user to control not just the rate of the modulation, but also the depth of that modulation. The current fixed depth sounds to be close to 80-90%, if you consider 100% to be the point at which the peak of the LFO's wave shape -- triangle or sine -- causes the pitch-shifted signal to be 180 degrees out-of-phase with the original signal and thus completely cancels it out.
This is a significant UI challenge and no trivial solution seems to exist; as with previous parameters, were TE to throw open the floodgates and allow encoder-pressing or shift+encoder to be among the interface options (the latter is currently used in OP-1s two samplers), this would be an obvious and seemingly simple solution. Unlike the other "new parameters" suggested above (filter resonance, direct independent control over SRR), adding control to the depth of Chorus modulation would require some new additional visualization to communicate this new state to the user. So, it's a bit of a can of worms.
Still, the fact that the current modulation depth is so pronounced is a bit awkward. Sometimes you want a bit of movement without necessarily wanting the heavy pumping/beating that currently happens.
One potential idea would be to add a second "half" of parameter space -- similar to how Orange works in the Pulse synthesis engine -- so that the Chorus parameter became bi-directional. Under this scheme, what is currently the minimum/CCW value would be the center of the parameter space: Chorus is off/LFO rate is at 0hz. Turning CW from this center point would behave exactly as it currently does -- the LFO rate is increased while the modulation depth is set to a fixed high value. But turning CCW from the center point could introduce a more subtle version -- basically the user would be controlling LFO rate as usual but the modulation depth would be set to a fixed but much lower value on this CCW half of the parameter space.
Anyway, it's an idea; as much as I love Chorus, and it certainly is very musical, useful, and distinct, it does tend to really jump out and overpower things, and I think simply allowing some way to dial down the modulation depth (so that the two detuned waves are only ever slightly out of phase with each other) would be a very useful capability.
Conclusion
That's just about everything I have to say about Dr. Wave. I do love it dearly, and I would be perfectly content to use it as-is for as long as my OP-1 is operational.
However, as with all of the synth engines, I think that there's always room for improvement, especially if such improvements are simple and relatively cheap/quick to implement.
In the case of Dr. Wave, while the graphical aspect is basically perfect (barring that irksome "freezing" behaviour), several of the choices made concerning the way parameters behave and change may not be optimal.
At least some of these UI decisions could stand being reevaluated in terms of useability: does each choice provide benefits sufficient to offset the awkward UI burden that is placed on users? It is my sincere hope that the fine folks at Teenage Engineering will challenge their existing designs and decisions, pushing things from excellent to super-amazingly-insane-excellentastic.
Anyway, that's it. I'm pretty beat -- Dr. Wave is a complex beast! Thanks for reading :)
If you have any comments or corrections, or anything at all to say about Dr. Wave and/or this article, please stop by this thread on the forums -- let's chat! http://ohpeewon.com/discussion/229/op-101-dr.-wave
