If you've been reading any of my previous project logs you might have noticed that there's a time discrepancy between the stuff discussed in the logs, and the state of the project apparent from the videos I've put in "project details". That's because I'm something like two months behind in writing the damn things. The plan was to post logs in the order I've been doing stuff and catch up to the present day work, but now I feel like skipping ahead a bit. I'll come back to the older stuff in later posts though. In future logs I'll try to mention when I'm jumping back or forth in time. 

In this log I'll be jumping right up to the most recent thing I've been working on, which is the "user operations" manual for FATCAT. Since I haven't yet covered how the sequencer interface works, this log will go into that matter a bit too.

Here's the teaser. Read more to see the whole thing!

I'll just go ahead and say it: I love making diagrams! I love it because it makes me feel like an inspired genius when I finally manage to space out all the lines, squiggles and shapes without them crossing or overlapping. Then I'll invariably realize I forgot to represent some important thing and the cycle starts over. I guess I also hate making diagrams. I hate it because it brings out something obsessive in me. Hours go by in a second while I fret about aligning pixels and straightening out slightly skewed arrows. I've finally amassed the willpower to end the process, but this single page flowchart still took an unreasonable amount of time to finish.

First attempt

Prior to entering the Hackaday contest, I'd actually already worked on a flowchart for my prototype from 2016 (which would later turn into FATCAT). This was not as much of an undertaking since it's functionality is so very basic. The chart describes the different modes of the sequencer interface, and how to navigate them using three buttons. FATCAT uses pretty much the same sequencer interface as is shown here, just with a bunch of extra stuff added on top. So by discussing this chart I'll be introducing the basic working principle of FATCATs interface too. 

"Nice. So what does it mean?"

Well, first of all, there's the little top-center picture of proto-FATCAT which tells you about its three buttons. Then there's the big grey circles which represent the different modes of operation. The squares tells you how the system responds to the user inputs. Your four user inputs are L, R, E and EH. Entering any of these will trigger some system response and might also move you into a different op mode. The left flowchart describes what the Enter button does in different modes. The five charts to the right tells you how the Left and Right buttons are used for those same modes.

Now I'll just switch gears for a second and describe how a proto-FATCAT song is organized. 

• There's only one song, which can be saved to EEPROM. It's loads automatically at system start-up.
• The song consists of 16 patterns (note: FATCAT proper has only 8), each of which consists of 16 rows. 
• Each pattern has two tracks: A drum track and a base track. 
• Musically a pattern translates to four beats (or one bar) in 4/4 time. During playback the selected pattern plays in a loop.  

So here's a little user story. You can follow along in the chart: 

Let's say you're in "Row select" mode, editing the drum track of some pattern. You decide you want to put a snare on the second beat of this pattern, which translates to row 4. The 7-segment display shows a "0", which means you're currently on row 0. So you press R four times. 

Once the display shows "4" you hear the hihat sound being played back. That means the row is currently occupied by a different sound. (You're still in "Row select" mode by the way.) You press E, and since the question "Drum is on?" can be answered in the affirmative, the hihat on row 4 is now turned off. Now, by pressing E a second time you'll get transported into "Drum select" mode, since there's no longer any drum on that row. In this mode L and R will cycle between the three different drum sounds. You select the snare with E and now you're back in "Row select". 

To save your progress, you press EH, which transports you to "Func menu". The message "PLAY" is flashed in 7-seg letters. That's the first menu item. If you press E at this point the current pattern will start playing. But you press L instead, to get to the menu item one step up. Now the message "SAVE" gets flashed. You press E which saves the current state of the song, and takes you back to "Row select" again.

The good and the bad

When taking a second look at this old chart I found there's some things that works well, and also some room for improvement:

The chart does a great job of telling you how the system responds to inputs. But it's not telling the whole story on the UI output. The picture of proto-FATCAT doesn't show that the hardware UI has a discrete LED diode or that there's a LED segment "dot" on the 7-segment display, both of which serves important functions. In the user story example, when we got to row 4, the chart doesn't indicate that the LED lights up to reflect the fact that that row is occupied, or that it starts blinking when we enter the "Drum select" and "Func menu" modes.

The UI uses the message "NOISE" when it means "drums", since you can't really write the letter "M" on a 7-seg display. It might be a good idea to be consistent and use the same term throughout the chart. "Noise" is probably closer to the truth anyway given the resolution of the samples.

The chart is a bit pedantic about explaining stuff that the user can easily figure out by just experimenting. Most of what the L and R buttons does is pretty self-explanatory once you're actually using the device.

A lapse in conceptual consistency: "Drum solo" and "Base solo" are represented as modes, but are in actuality states within the "Play & pattern select" mode.

The ugly

The chart isn't very pretty. It doesn't look awful either, it just doesn't have any personality to it. The left flowchart is also a bit to busy and could benefit from being split up into separate parts.

Getting inspired

Back when I was a spotty-faced teen in the 90's, my parents (not well off) were nice enough to buy me two pretty expensive pieces of music equipment: A Roland SC-55 and a BOSS DR-660. Together with my Atari ST these were my most beloved possessions. Like a stupid idiot I've since sold all of that stuff, but I remember I used to love thumbing through the user manuals of those things even though I already knew every function by heart. There was just something beautiful about how they were put together, and the economy and clarity of the illustrations. 

I decided to try to get a little inspiration from the visual style used in those manuals, so before starting on the new and improved FATCAT flowchart, I took a trip down memory lane and googled the PDFs. I also looked at some manuals for older Roland devices like the TR-808. 

Suffice is to say that ultimately my flowchart didn't really end up resembling Rolands visual style all that much. Still I feel it may have gained something from this exercise. Maybe it's just that it made me think about stuff like balancing of visual elements and paying attention to detail without focusing on details. 

Starting over

I ditched my old chart and started sketching on a new one. I'd used LibreOffice Draw for the old one but that software never really clicked with me. I started working with draw.io just to try out some ideas, thinking I'd switch to something else later. I'd tried it for some UML modeling before, and hadn't been overly impressed then. But for this type of diagram it turned out to be pretty much perfect, so I just carried on using it. Also it probably helped that I bothered to learn how to use it properly this time. 

It's all in your mind

Since FATCATs UI output is so sparse, it's required of the user to keep a mental image of some aspects of the system state. In particular, the user must always be aware of which op mode he's in, since the constituent components of the UI output hardware (a single LED diode, a 7-segment display digit and its "dot") are used for conveying completely different information for each mode. These days we're pretty used to having our devices spoon-feed us info. And that's great, don't get me wrong. But often when editing music on a PC, I at least, tend to get lost in the visual representation of the music and forget to use my ears. So when it comes to music, working with a minimal UI might not be all bad, is what I'm trying to say.

At any time when using FATCAT, major parts of the editors state needs to stay buffered inside your head. So I wanted to design the chart components so that they lend themselves to get easily implanted into the users mental imagery. There should be clear visual parallels between the devices physical UI outputs and the squiggles printed on the chart. For that reason I've tried to use concrete, intuitive symbols as much as possible. And I've tried to keep the amount of textual information to a minimum.

"You sure seem to have plenty of thoughts about this stuff, huh. Did you end up actually making the new thing then?"

Yup. Here it is. I'll carry on for a bit longer below though. 

I've put quite a bit of effort into getting the chart to have a distinct style. And for it to look, if not beautiful, at least not amateurish.

I've represented the typical workflow as progressing from top of the page (powering the device on) onto editing a track, and from there going through the menu into "PLAY" mode, at the bottom of the page. I've also introduced the concept of nested modes. Top-level modes have sub-modes inside, which in turn adheres to a similar top to bottom workflow representation. All modes and sub-modes are now represented as either squares or rectangles. The system responses are dashed squares. The hexagons represents states inside a mode. 

I'm thinking I should maybe reserve the term "mode" for the top-level boxes "CHORD EDIT", "TRACK EDIT", "MENU" and "PLAY". I'd have to think of a different term for the sub-modes. Like maybe "activity". I'll keep using "sub-mode" in this post though.

I've tried to described the hardware UI output components more clearly (diagram top-left). The LED diode and the 7-seg "dot" are now clearly marked. To let the user know what type of UI output to expect from different modes/sub-modes, I've introduced a number of decorators that can be added to different corners of those shapes. Other shapes can also have certain decorators—indicating changes within a mode, or what the UI output state will be when entering a mode. 

Modes with missing decorators indicate that those certain outputs vary depending on some variable within the mode. (The LED could be either on or off depending on if a row is occupied or not for example.) Any top-level mode decorators carry over to all its sub-modes. I've also placed little hints in the empty spaces between the top-level modes, stating what the different decorators symbolize.

I've omitted the Left and Right button inputs for most of the modes, for reasons discussed earlier.

One thing I'm still not 100% satisfied with is the "Pattern Select" sub-mode inside the "PLAY" mode. It doesn't have the same shape or size as the other sub-modes because it needs to contain state symbols. So it's not that clear that it symbolizes the same type of thing. Also the placement of its name might make it look like it's associated with the "No Solo" state specifically. But right now I'm not quite sure about how to fix those issues.

Turning a page

I'd probably want make one more page for the manual—for printing on the back side of the current one—at some point. It should state explicitly what every type of shape is supposed to represent and also cover some stuff about the interface that's better expressed in writing.  

Next step is to make a tutorial video where I'll cover the basics on how to edit a song. I think this flowchart will be really useful to include in it, as a visual aid.