YouTube:   Music demo 1   Music demo 2   Music demo 3   Tutorial: Making music on FATCAT

Features

By comparing FATCAT to mod trackers I'm not trying to imply that it's compatible with any existing mod tracker file format or that it's an equally capable tool performance-wise. I simply mean that it has a similar number-based user interface and song data organization. It's also suitable for composing similar sounding types of music, using low resolution samples/waveforms and arpeggiated chords.

These are FATCATs main features:

• Three tracks, with preset instruments:
  1. Drum track. Uses a combination of drum samples and white noise for a four piece drumkit. Kick, snare, closed hihat and open hihat / cymbal. Each drum sound has a variation (for example soft/hard kick). The hihat has a "flam" option used for performing a quick syncopated double hit.
  2. Base track. Uses a simple square waveform. Portamento effect optional, for base "slide" between notes. 
  3. Arp track. Uses a more complex sawtooth wavetable, which allows for some variations in timbre. Can be used either as a lead instrument or for arpeggiated chords, or a combination. 
• One song can be saved to eeprom memory. The song can contain 8 patterns. Each pattern has a resolution of 16 rows.
• The song can use up to eight different arpeggiated chords, with repeating patterns of up to 16 notes. Chords can be edited by the user. Arpeggios can be performed using time signatures independent of the song itself.
• The patchbay can be used during playback for performing improvised variations on the original song. Bridging different patchbay sockets with resistors alters either the instrument sounds, the song rythm, or the order by which the song data is being played back. Certain sockets of the patchbay also connects directly to the audio output signal. These can be used for creating feedback loops with the playback engine logic, which can lead to some very interesting and unpredictable musical variations.
• The patchbay pinheader serves a secondary function as a ISP interface for the MCU. This makes it possible to update the firmware at any point after building the device. The ISP interface can also be used for transferring songs between the MCU EEPROM and a PC.
• There is currently some limited support for connecting two FATCAT devices to each other, allowing for cross-device excange of variables during playback. It might be possible for future firmware versions to support master-slave device syncing of playback tempo.

Project motivation and practical usefulness

At it's core this project is an exercise in designing a usable musical instrument that requires an absolute minimum of components, effort, and money to build. The project also explores how an effective user interface can be designed, using a very limited set of physical components. 

Often with modern instruments or software, music editing turns into a largely visual enterprise, which can sometimes stifle musical creativity. In my view, the main usefulness of FATCAT is as an antidote for that. The point with FATCAT is to give your eyeballs and mouse arm a break, and by doing so giving your ears and mind a chance to roam free. Using the device is also a way of purposefully subjecting oneself to creative limitation, which is often cited as a means for creating art that wouldn't have materialized if given infinite options and resources.  

Challenges

The main challenge lies in the balancing of limited system resources, in order to maximize musical versatility and performance. You can run out of 8k of flash real fast when trying to cram both program data and instrument wavetables in there. Also the 512 bytes of RAM and EEPROM can only be used to hold a very limited amount of song data, which requires some careful design of the data model.

A similar balancing act is also required in the design of the user interface. The device must be usable in the sense that it's UI can be learned, and can be operated effectively. But the device must also be usable as a tool for creating a dynamic, non-trivial piece of music. Finding the right mix between those two requirements has often led to slightly heart-beaking "kill-your-darlings" type situations when a cool feature has had to be sacrificed to achieve easier usability or more consistency in how the UI is structured.    

Interestingly enough I have found that creative limitation, in addition to being a reason for using the device itself, has also played a part in directing the design choices made during the project. In trying to make the device punch above it's hardware weight-class, I've ventured into some slightly unconventional techniques I would've never considered trying had I not been designing for such limited hardware. One such happy accident was in adding an option for letting the playback engine traverse song data by means of the Fibonnachi sequence instead of sequentially, which produces some quite interesting results with almost no cost in system resources.

NOTE:

The models for the 3D-printed features of FATCAT in these pictures and videos are not my original designs. See "Licenses..." text in project files section for full details.