This rant was written in 2021. Since then the Deluge screen has been upgraded, but unfortunately little else has changed. The Polyend device turned out to be the Polyend Play, a groovebox with a simplistic sequencer, no arranger mode, and limited polyphony. Quite a disappointment. Squarp also came out with the Hapax, also a surprisingly limited sequncer given its price tag. Oxi came out with the One, also with limited polyphony and a rather restricted sequencer. At present the Deluge remains the machine to beat in the large-grid sequencer realm: but its interface also remains really, really bad.
I have since written a step-by-step rundown of how to use the Deluge's arranger as an actual linear arranger rather than a glorified song mode. I go through all the bugs, interface problems, and missing features, and how to work around them.
I want to love the Synthstrom Deluge. It’s got tons of features. It’s got the best sequencer available in hardware, with an actual DAW-style timeline Arranger mode that easily separates it from the pack. It’s got a synthesizer. It’s got a sampler. It’s got a good drum machine facility. It’s from a scrappy startup. It’s got MIDI and CV (though it’s super skimpy on both). It does so much stuff. It’s light and small and runs on battery. And it’s got almost 150 pads that light up in different colors! So awesome!
But it has a terrible interface. Like, show-stoppingly terrible.
I’m gonna get blowback for this. How can you possibly say this, I hear you say, it’s got this cool pad thingy! But the pad is not the interface. The interface is how the device, in its various modes, responds to interaction with the user. And the Deluge’s interface is, in my opinion, a hot mess.
The Deluge has an amazing feature list, but I just can't forgive its interface design. I just can’t. I build synth tools including both software and hardware sequencers. And while my own work is hardly the paragon of user interface virtue, I try to put in effort to get it right. I think that Synthstrom has not. So this is my little takedown of the Deluge interface, showcasing just a small selection of its UX failings. I mostly use the Deluge’s sequencer, so all the examples here will be from that. I don’t use the Deluge’s synthesizer, sampling, or CV all that much, but I have no doubt that further digging in those other corners of the Deluge interface would likewise reveal some nasty cockroaches.
I have some personal tenets about user interface design. I hardly think they’re controversial. Here are a few:
Everyone violates these rules here and there a little bit. Certainly I do. But the Deluge breaks all of them needlessly and in extraordinary ways. To wit:
Let’s start with the obvious one. The Deluge interface is incredibly cryptic. This stems from the Deluge having a great many operations but only a few interface widgets to handle them. Now this isn’t uncommon: 90’s synthesizers historically had just a few buttons and one big dial to handle a myriad of parameters, but these synths employed a decent screen and used menu diving to organize their parameters in a logical, if cumbersome, way. And while many grooveboxes didn’t have a screen, their options were so simple that the memorization required tended to be minimal. But the Deluge, despite having a massive feature set, has—and there’s no beating around the bush here—a terrible screen. It’s just a four-digit numeric display, not even an alphanumeric display, thus probably saving 25 cents but damning Deluge users to a hellscape of incomprehensible Martian symbols representing letters, such as ≡ for X. You’d never guess what K, M, V, and W look like. Few things scroll horizontally to reveal more information, so you’re stuck with just four glyphs. This is made even more maddening by the fact that there’s a huge pad directly below the screen which could have offered some assistance.
The Deluge splits its interface into two. For its sequencer and audio editing tools, the Deluge relies on a myriad of crazy, unmarked Konami-Code combinations of buttons, encoders, pads, and even external controller keyboard keystrokes which differ from mode to mode and which cannot be discovered except by reading a 320-page manual. There are so many of them, and they are so arbitrary, that the user community eventually developed its own extensive cheatsheet. That is not good.
For the rest of its tools, the Deluge has a completely different interface which relies on a hierarchical menu assisted by a hot-key interface. This would all be fine and good except that the labelling for the 128 hotkeys is in a microscropic font which could have been at least twice the size, and with thin criss-cross lines to group things rather than a simple color scheme. It’s so bad that there are not one but two competing vendors who make colored overlays meant to make the hot-keys readable.
The Deluge often requires completely different procedures to do nearly the same thing depending on what mode you’re in or even whether you’re doing the same task vertically versus horizontally: and usually this is for no good reason at all. This makes its already confusing array of Konami-code operations far more confusing because once you’ve learned them, you must now learn a different chordal arrangement for the same tasks in each of the other modes or scenarios. The number of memorizations is thus multiplied by three or more.
There are numerous examples of this, but let’s start simple. If you turn the ↕ knob, the screen scrolls by one row at a time. Great. But if you turn the ↔ knob in Clip or Song mode, the screen scrolls by a screenful at a time, rather than a column at a time, and for no apparent reason. This makes very difficult and awkward the task of viewing or comparing notes on both sides of a screen boundary, or changing the length of a note that crosses a screen boundary. But in Arranger mode the screen scrolls by the column (yay); yet there appears to be no way at all to precisely set the length of a clip that crosses a screen boundary.
Here’s another example: consider the task of adjusting a single element (note, Arranger clip) right or left. In Arranger mode, you press the element, then turn the ↔ knob. But in Clip mode, you must press and turn the ↔ knob. If you just turned the ↔ knob, this for some reason is bound to changing the velocity of the note. And in Arranger mode, pressing and turning ↔ does nothing at all.
But wait! In Arranger mode this operation moves the element a column at a time: but in Clip mode it moves only by a tiny “nudge” amount, and there is no by-column movement option at all. On top of this, in Clip mode you can move the element to the left or right as much as you want: but in Arranger mode for some godforsaken reason you can only move the element to the right.
Another example: often you want to zoom all the way out so as to view and increase the length of a clip or arrangement. In Clip and Song mode, when you zoom all the way out, you are shown no extra space beyond the next power of two, though you are given the option of increasing the space manually. On the other hand, in Arranger mode you are automatically given twice the extra space, but you are not given the option of increasing the space manually. The Deluge just dictates that your next placed element must be somewhere in the next half of the song.
Yet another example. A common need is to rearrange the order of tracks. To move a track up or down, in Arranger mode you press audition, then turn ↕. In Clip mode you press audition, then push and turn ↕. And in Song mode, you press a track pad, not audition, and turn ↕. Pressing audition does something else.
Finally, here’s a rarely used function but one with boss-level inconsistency. Sometimes you might need to add or remove blank space at the beginning of a clip or an arrangement. In Arranger mode it’s done by holding Shift and then turning ↔. But in Clip mode, to do exactly the same thing you must first press ↕, then while holding it down, turn ↔, taking care not to turn ↕ at the same time.
What a mess.
Let’s say you want to change the degree of probability that a given note will play. Would you have guessed that this was holding down the note and then turning the main select knob? I wouldn’t have: surely such a prominent position could have been assigned to, say, changing note velocity, thus freeing up [pad + ↕] to change note length and thus be consistent with the Arranger per previous rant. But I digress.
Anyway, the only way to discover this operation is to hunt down its magic Konami Code in the manual. While the Deluge has a menu structure for its synthesizer parameters, it entirely lacks one for its sequencer. You can change oscillator detune via a menu, but not note probability. Keep in mind that the sequencer is the most basic function of the Deluge. Why doesn’t the menu cover all the Deluge’s functionality? No idea.
There are in fact some magic codes that appear to be not documented at all. For example, to tie a clip to a MIDI keyboard controller, the documentation says that you must enter the clip, hold down an audition pad, hold down Learn/Input, then press a note on the keyboard. What it doesn’t say is that you can also do this from Song mode with an obscure set of track pad presses. This can only be discovered by searching the forum, or stumbling across it and fumbling about trying to understand its semantics.
A trap common to kitchen-sink designs like the Deluge is making very common tasks vastly harder in order to make a certain rare or useless task possible. The Deluge does this a lot. This is hinted at just by glancing at its hardware interface, with many hard-coded buttons bound to obscure functions, while common operations are buried in menus.
Here’s an absurd example I came across recently. When you interact with a sequencer, typically you do so from a single controller. In a typical sequencer, you’d specify the MIDI channel of that controller once, then arm or enter a track, press record, and start playing notes. Want to record another track? Enter or arm that track, press record, and start playing notes again.
Not so in the Deluge: it’s much harder and more error prone. You cannot tell the Deluge that you want to always use a certain controller MIDI channel. Instead, you must repeatedly teach the Deluge this MIDI channel over and over and over again for every single clip you record, and furthermore, every time you must also disable the MIDI channel from previously recorded tracks, or you will run the risk of recording note data into them at the same time, ruining them.
To someone coming from other environments and sequencers (and designing some), this is insane. Why would the Deluge require you over and over to unlearn, then relearn, a MIDI channel just to record a track? I think this is because the Deluge wants to support the ability to record from multiple controllers, and perhaps to do so simultaneously. This is cute, but I would charitably estimate that 99% of the people using a Deluge do so with a single controller at a time, and many of them have a just one controller period. By supporting this 1% oddity the way it has, the Deluge makes it extraordinarily inconvenient, frustrating, even painful, to do one of the very most common tasks a sequencer is meant to support.
The Deluge could have simply had a global default MIDI channel. If you enter a clip it is automatically armed (and the others disarmed), and when you play on that channel while recording, data is entered into the clip. Alternatively you could arm the clip in Song mode with a single pad press, by default automatically disarming other clips. You could still have some procedure to custom-arm a clip with a special MIDI channel, but if you didn’t do this, the global MIDI channel would be used. Done and done.
The Deluge often doesn’t make this easy: sometimes you have to go through an extra step, sometimes several extra steps, to hunt down a data relationship, and sometimes it’s not even possible. I’ve already mentioned the difficulty in visualizing relationships between notes that straddle screen boundaries. But here’s a nastier one...
In Clip mode there are two kinds of ways clips may be grouped. First, clips may be grouped into mute groups, to make it convenient to mute or unmute an entire set of clips simultaneously during live play. But clips can also be linked together, essentially as separate variations of the same clip which may substitute for one another in the Arranger.
While Clip mode clearly shows you which clips are in which mute groups (by coloring their Audition pads), you are not told which clips are in which link groups. The only way I know to find this out is to hold down Learn/Input and then press on various pads one by one, causing the clip and its linked clips to blink.
All this is annoying but not a disaster. But wait! It becomes a much bigger problem when we get to the Arranger. The Arranger assigns a single track for every link group. But there’s still no way to tell which track is which group. If you have 20 link groups of clips, you now have twenty unmarked Arranger tracks. Helpfully, the Arranger tracks are laid out in the same order as you had initially laid out the first clip in each link group. Unhelpfully, if you change the order of the clips while in Clip mode (very common), it’s not changed in Arranger mode to reflect this. The data relationship between the Arranger and the Clip mode is severed. The only other way to figure out which tracks are which groups is to manually press the audition pads in the Arranger and see if you recognize the synth or kit sound from the single note that is played. Let’s hope you don’t have multiple linked groups that use the same synth sound.
Yuck. I suspect the reason for all this is that while there are two different kinds of groups, the Deluge only colors the pads of one column (audition) to reflect grouping, because it reserves the mute column pads solely to display mute/unmute. So no colors are allowed to denote linked groups or separate clips!
But in fact there is a fairly simple solution: just color the mute pads as well. You won’t lose anything. At present the mute pads need to display only five state values: (1) muted [red] (2) unmuted [green] (3) scheduled to be muted [blinking green] (4) scheduled to be unmuted [blinking red] (5) Unused (off). There are also three overlaid states: (6) soloed [blue] and (7) scheduled to be soloed [blinking blue], and (8) scheduled to be un-soloed [um, also blinking blue?]
Instead, the mute pad colors could reflect the link group. The five mute state values would then be: (1) muted [dim] (2) unmuted [bright] (3) scheduled to be muted [blinking bright] (4) scheduled to be unmuted [blinking dim] (5) Unused [off]. You could keep the overlaid solo states as they are, though I would change the solo color to white so blue could be used to describe a group. Done! You’d not be able to determine group colors when soloed, but that typically only happens during live play in Song mode anyway, not arrangement.
Now in Arranger mode, the mute pads (which for some reason are green and yellow, not green and red as in Song mode, hello consistency?) or the audition pads could be colored to reflect the corresponding linked group.
This past year at Superbooth (2021) there was a leaked photo of a Polyend device which looks just like a Deluge, but with many more encoders, and with an actual screen. I suspect this leak was not an accident. Polyend may be about to release a Deluge Done Right, and may have been hoping to get some press buzz.
In response, while there’s not much Synthstrom can do about the Deluge’s awful screen and its overreliance on crazy encoder-button combinations, it can address many of the interface issues discussed here. If I were running Synthstrom, I’d have a flag day, stopping everything and going through with a fine-tooth comb to rethink every encoder combination, the silk-screening of the front panel, and the use of colors and pads to reflect data and relationships between screens and modes. I’d redo all the encoder mappings, aiming for maintaining consistency across modes, reserving the simplest combinations for the most common tasks, adding a menu for all operations, and maybe even suggesting shortcut combos on-screen after the user selects a menu item. And I’d do it soon and fast, because I think Polyend might be about to eat Synthstrom’s lunch.