First of all, I must say that I love the Waveform Editor! For some reason, operating on a monochrome pixelated waveform feels like a game and fills me with joy.
However, I often find myself struggling with simple tasks, making the same errors again and again. Which made me—a new user with a fresh look—think about how the Waveform Editor can be improved. I didn’t use any other sampler before so my mind is clear and free of biases:) Of course it may be that I didn’t understand the machine’s philosophy yet but I believe that my input could still be valuable for the developers and may bring a better understanding of how the machine is used in real life.
My objective with this post is to find the operation principles which will allow the user to build muscle memory and do routine tasks almost automatically, without much thinking. I believe that the biggest problem while using interfaces is frequent context switching. It distracts, kills the flow and should be avoided.
I find the following particularly troublesome:
Too many different controls. Moving faders, rotating the encoder, pressing the buttons, then pressing the encoder button — all of these feel differently, require different muscles, different kinds of motion and different forces. The goal should be to keep different control types to a minimum while executing a single task.
Moving hands from one area to another. There’s the Shift button, the sliders, the encoder, the <<</>>> buttons and the keypad (with the Enter button being too far from the F1-F3 row!). Understandably, the goal should be to minimize the user’s hand movements, allowing them to execute a single task while keeping their hands in a single position.
There’s also the problem of having too many options at once . Like, with the looping activated, there are 6 options of what can be edited. All good, but such an approach requires the user either to keep all of these options in mind, which may be overwhelming, or to revise them frequently, which is stressful. I believe the best solution is to find a healthy compromise between “horizontal” and “vertical” structures, i.e. not to give all the options at once, but also not to force the user to “zoom in and out” too much (not too much menu diving).
The last workflow deficiency, in my opinion, is the lack of visual feedback . Like, it would make the workflow so much smoother to have the display show the state without having to move the controls first! Also, editing the start and the end points with faders always confuses me because I cannot relate the position of the dash line to the positions of the sliders.
But enough theory. I came up with the some practical suggestions which, I believe, could help improve the workflow and would like to share them with you and hear your thoughts and comments. Here they are:
— Adding simple toggling between the start and the end points. I believe that switching between two opposite options is much more easy for the user than switching between 3 (or 6!) modes, especially when these two options are used most of the time. I suggest using the F2 for quick toggling between the start and the end points (if some other option is selected, pressing the F2 should immediately select the start point). This will allow the user to quickly edit the slice while keeping their left hand on the first F-button row and the right hand on the encoder. The current function of the F2 could be moved to the F9.
— Controlling zoom with the encoder while holding a button. This is a tricky one as it will require another button. Maybe a long press on the F2 could be used for this? Maybe holding the F1 and the F3? In any case, holding a button and moving the encoder will definitely feel smoother than clicking on the same button multiple times.
— Pre-selecting the start point when the Waveform Editor is first opened. Is it just me or does everyone start the editing with the start point? Also, when editing a new unedited slice, the start point could always be pre-selected, no matter which mode was last active in the previous slice.
— Highlighting the selected dash line. This will help users to better see which line will be moved with the encoder and make fewer wrong moves. Highlighting the time field is great but not visual enough. It requires more attention from the user to be recognized. Maybe some triangle or square ends could be added to the line to indicate editing?
— Allow lines to move each other. By this I mean that when one line is moving past another, that another line should move with it and not prevent the first line from moving. Here’s why: when initially editing the slices I, logically, start with the start point. Some slices, however, are positioned far off due to the automatic pre-slicing and have to be moved to a completely different position. And that’s where I always stumble over this mechanism which prevents the start point from moving past the end point. I have to select the end point, move it, then go back to the start point, move it too, listen to the result, then repeat the whole thing over and over again until I find the start of the slice. Without the mechanism it could have been just scrolling forward and backward! I understand why it’s implemented the way it is but maybe a setting disabling this behavior could be added for those users who would like to take the risk?
— Adding “Move to the next/previous zero-crossing” option. Zero-crossings are often found inside transients. In order to move to the previous zero-crossing, I scroll the start point to the left and press the F5 again. This often results in finding the same zero-crossing making me repeat the process until I find the new one. Automating the procedure would be great! Maybe long pressing the F4/F6 could be used for this?
That’s all for now. Sorry for so much text. Hope at least some of it makes sense and can be used to start a productive discussion.