selig wrote: ↑
29 Aug 2017
Hey there, making some progress but so far is looking like all the buttons crammed into the space - needs a better 'design' IMO.
Also, I don't follow the "replicate the software screen" approach. I instead would look at actual user workflow. What functions do you use the most, what functions will you be forced back to the keyboard/mouse to use?
For me, I use Save and Undo a LOT. No, they are not that glamorous, neither do they appear on the mixer page - and so they do not appear on your mockup. BUT they are probably some of the MOST USED functions of all when working with Reason.
Leaving these (and other important) functions off the hardware requires you to use the keyboard/mouse, or have to refer to the other screens far too often IMO. This is something I learned from working with the HUI, and later the ICON D-Command (which thoughtfully include these functions).
So rather than be strict with your idea of replacing the mixer window, instead extend your concept to building the BEST hardware controller for Reason! That's the way I approach it, fwiw - maybe not what you intended, maybe not what you want for your own purposes. But food for thought, at least.
Consider how you work with Reason. What commands do you perform the most? What functions do you need the most? I would suggest that in the most basic form, navigation is the most common function performed, either navigating to a new instrument/track/channel, navigating to find and then load a preset, navigating to a different part of the timeline, navigating to change the mode or pointer function. Taking the idea of 'navigation' to this basic level you can see that a hardware controller needs to be good at these things in order to be the most useful. With that in mind, I suggest also adding the arrow keys from the keyboard, which can be used for zoom and selection. Just because this is a mixer controller doesn't mean you can't use it when editing!
You will also need to apply Fitts Law and similar UI design concepts at some point.
For example, the way you are laying out your drawings to scale is part one. Part two requires you to already know the most common functions you typically perform when mixing - have you observed your workflow to discover this? It can be very helpful to video yourself working on a mix (with a cell phone camera) - play back the video and note which features you use the most/least. Also, if you have the chance, spend some time working with a hardware controller to see what you like/don't like, from the perspective of a user AND a designer/builder! If you look at hardware controllers that have been used for a while, you can see what buttons have the paint rubbed off, and what buttons have the most dirt around them! The play button on SSLs is the first to go, and on the ICON, the save, undo, and redo buttons have the most dirt around them! So these need to be easy to hit, and close by where your hand is at rest.
Check out this image of an ICON controller - looks very much like the one I use. Notice where the 'dirt' is - this is where the hands rest and also indicate which functions are used the most!:
My overall approach suggestions:
The first step is not to lay out the controls IMO, it is to define the device broadly. I find it helpful to write up the product description as it might appear in an ad or store page (even if you're making it just for yourself). Also define your goals (a design "spec") with regards to features, functions, costs, size, look/feel, etc. Then you can start to focus more - measure your mockups against your goals, to see if you are hitting all the marks or not. Next up is to create a feature list, then a very specific control list (checking against your goals along the way). Then you can prioritize the features/controls to determine size/location, starting with the obvious (transport buttons should be closest and should be big and feel solid, etc.).
Otherwise you'll keep changing course and starting over, rather than following a more "iteration" based design process.
Also consider the 80/20 rule as it applies to many aspects of the design process:
http://www2.latech.edu/~box/ase/papers2 ... mpaper.PDF
Anyway, just more food for thought, since any changes/mistakes with hardware are much more costly than with software (but in both cases should be minimized IMO).
First off, I really appreciate your response Selig. It's clear to me that you're after the best design possible for a physical controller for Reason--and that's certainly a shared goal here.
That said, I do agree that save/undo/redo are used a ton--I think those are the ones I use most after the transport. They're so important, that I placed them in the previous mockup as physically close to the stop/play buttons of the transport as possible, in order to minimize reach for the most often used functions. Did you miss them by chance?
It's also why I thought to move the sends and master inserts above the more often used items. I don't mess with those much, but I like to boost global reverb returns sometimes to wash a song out shoegaze-style with a quick grab of the knob. Also, and maybe this is just me, but I hate remembering which send is which--was 2 my tape echo, or was it 3? So for me it's really important to be able to glance and see it with as minimal reading as possible. Especially if bouncing between songs in a single session.
I was unfamiliar with Fitt's Law, but I really like it, thank you for sharing! When I lay out these things, I'm constantly thinking in tradeoffs--it's like a multi-dimensional chess board. On one axis you have ease-of-use. It should just feel natural. It shouldn't feel crammed or confusing. But it should also not include such symmetry that it forces you out of your creative zone into thinking about the tool rather than the work being done with the tool. A good example of this is the recent movement towards EQs to be horizontal, symmetric, and all the same knob color (like that Icon image you posted.) That's a horrible idea, IMO. Why?
Because my brain has evolved over millennia to observe color and shape asymmetry extremely quickly without thinking (along with other capabilities like peripheral vision to catch lions about to attack you from behind the bushes!) So when I look at some (not all) of the newer interfaces, it makes me sad because they've removed both the color identification of the knobs, AND they removed the asymmetry of the knob layout. Both of those design choices force me to have to translate from my thought stream during mixing of "add a little air to that channel", into "ok, which knob is the HF dB knob? Ok, looking, read the label, ok it's that one. Wait, is that Q or LF? Oh it's Q, b/c I'm in the middle two, it's the same knob position on the Icon" Meanwhile two bars have gone by so I reach back to the transport rewind and go again. That gets fatiguing after a while. With asymmetry you can even go by feel without looking at all (like those great little bumps on keyboards so you can find your way without removing your eyes.) I suppose you get muscle memory after a while with your tool, so it's something that we're good at adapting to, but I take the symmetry and monochromatic color as a drawback, not a benefit.
So, I guess the point I'm trying to make is that yes, there are almost certainly things we can do differently with new hardware controller designs that simply make the old stuff look way too heavy and unnecessary--such as the full channelstrip per channel. Back in the day, it was necessary b/c it was all analog and made the most sense from a signal flow standpoint. And now we can break from that. But there were a lot of really good design decisions in there too IMO, and I don't personally want to throw all of those out. For instance, I rather prefer the look of an API lunchbox (as geremix put it so well) for the center section--with all its side-by-side rectangular channel strips. Why? Because when the Props inevitably change some thing in Reason 11 or 12, it would be easier to just remove, say the Inserts section and put in a new one with the new features. Hardware controllers are unfortunately bound to their ever-changing software counterparts, and that puts the hardware folks at a disadvantage from a malleability standpoint.
As background, I don't have experience on an actual SSL, nor do I on the Icon. I've used Allen & Heath analog boards for a long time, and later moved to the Tascam DM3200, which has some of its own cool features (like holding down a button while pressing "select" on a channel will zero out that channel's fader). It becomes a thoughtless gesture to press and swipe across all 16 fader strips to zero out the faders without even thinking. It's those thoughtless gestures that I'm after with this.
Ok, so back to the original challenge: there are multiple axes--the first (and likely most important) is that it's easy to use, and we just covered that. Others are cost, physical size, technical feasibility and difficulty, and what I'll call "joy of use"--which is the feeling you get when you use a really fantastic tool and it just does exactly what you need. Actually now that I think about it, "joy of use" is when you nail the ease-of-use axis--it's the result of success on that axis.
So for me, this project has these axes in the following order from most important to me to least important to me:
- ease-of-use (and "joy of use")
- technical feasibility
- physical size
In other words, I really really really want it to be braindead to use. I would prefer it not to be ultra difficult on the technical side from a component or firmware standpoint, since this is still a side hobby at the moment. I do prefer physically smaller than bigger, all else being equal, but bigger isn't a dealbreaker if it's required to maintain that ease-of-use. Cost to me is the least important--I'm not optimizing for that at all right now, within reason. This is mainly because for others to make a living making controllers, they must
compromise on ease-of-use and physical size in order to hit the proper cost point to make profit and sustain. I don't want that limitation in this project--at least not yet.
There's an old adage we use at my office: "Make it work, make it right, then make it fast".
And I realize that there will inevitably be things that won't be possible b/c of limitations of Reason--for instance, it appears that there is no Reason Remote means to toggle "record enable" on a track. You can set it to auto-record-enable whenever you select a track, or you can turn it off and manually do it with the mouse. That sucks--I want a red record-enable button on each channel, next to the arm button. Also, did you know that Remote provides "Insert FX input and output" peak meters? I didn't--and don't see where they show up anywhere in Reason. Seems like it could be important from a gain-stage standpoint--especially with things like Pulverizer that overdrive easily.
Speaking of inserts, I haven't seen any mockups other than my own that include them, either as part of the channel strip, or as the master inserts. Am I the only one that uses them? FWIW, I find them super interesting for making custom-type "presets" for certain types of tracks. I have bunch of guitar ones, and some vocal ones, and drum ones. They are great to scroll through while mixing to see if there's a better fit for a track in a mix. That's why I include it, despite the size.
When I think about how I mix, I use the transport the most, then the faders to bring up rough mixes. Then I move to EQ, compression, and FX to try to make space for them to play well together. Reverbs/delays to push them to the back, EQ to make them sit in a frequency range, and compression to smack it down if it's too unwieldy from a dynamics standpoint.
I use the loop enable a ton, because there are sections that get messy from a clarity standpoint, or need help, and I get tired of always hitting the triple tap of stop-holdrewind-play. So I placed the loop set points very close to the play button too. (Was also thinking that there are a lot of opportunities for adding additional quick hotkeys with this interface, like hold down the loop L or R button while pressing the rewind or fast-forward to move the locator back or forward a bar). There are lots of opportunities for these sorts of features. (Another are markers--why oh why doesn't Reason have markers? Digital Performer had them 15 years ago. Markers could be easily added to this interface and recall them simply by sending a new song position Remote message. So much expansion/refinement possible!)
I use click a lot--sometimes for tracking, but more for seeing if a certain section drifts out of timing too much, but no click level, that's available on the sequencer transport. I also listen to returns a lot to see how reverbs tail off, so I like the ability to switch the control room source right there with the up/down buttons. For things like the mixbus compressor, I'll spend 30 seconds with it after a rough mix is made, then I'll come back and spend a couple minutes with it once a mix is close to being done. Then I don't mess with it again. If I could put it further away, I would.
I've described a lot, but the core point I'm trying to drive home is that I'm coming from a pretty specific perspective with this project. My default method right now is to run everything direct out into the digital physical mixer and just mix on that. But then I am just using Reason as a multitrack recorder. This method is fine, it sounds decent, but it's also not intuitive or inspiring. Definitely no "joy-of-use" going on! So it's like, use a mouse to mix, or menu-dive and read labels on the Tascam to get to compressors and EQs. But then they aren't saved with the song. They're saved in the Tascam mixer. Then the Tascam mixer got discontinued. <facepalm>
I think the next steps for me are to lay out the fader banks (I can see them in my head, and they're heavily
inspired by Selig's earlier mockups), and then get them printed it out and mocked up as well. Will refine button sizes, locations, and alignment later. Then it will be time to start prototyping each section on a breadboard. I will start very very very small--like just the transport first. Then perhaps channel and bank buttons, and then transport bar. Then start with input, and work down the line. As they're all being prototyped, once they prove to work, I'll order up the OSHpark prototype PCBs and put together working lego versions.
Again, thank you Selig for your comments--you brought up a lot of great points to ponder.