R2D2 touchscreen

The R2D2 controller is different. It’s considerably distinct from the type of devices I usually build in that it is digital. It’s a small microprocessor with touch-screen interface There are 3 manual controls on the top that send some secondary parameters to the microprocessor via ADC inputs but the real business is all conducted by interacting with the touchscreen during performance. The outputs are MIDI commands with a parallel control voltage and gate outputs, via hardware connectors on the back of the instrument. Before I describe the control functions. I feel compelled to explain the Star-Wars reference in the name. It’s not clever at all, pretty disappointing really … It’s just that every time I look at the little thing, in my mind, I see R2D2 looking up at me. I didn’t have any other ideas and so this unlikely association just stuck.

I fully realize that R2D2 is domed and cylindrical and this gizmo is square & angular – oh well! square peg/round hole- story of my life.

The touchscreen has 3 regions:

The top row has 4 buttons that control various chores

The middle row is a ‘tempo bar’ slider that controls the rate at which the screen will be read and squirted to the outputs .

The rest of the screen is an area on which the player ‘fingerpaints’ dots or lines in yellow. There is a blue cursor that sweeps across the painted figures at a rate set by the tempo bar and interprets the painted figures as: Pitch (vertical offset from the bottom) and, Duration (horizontal presence or absence of a yellow pixel). Describing this in text is very awkward but the reality is very intuitive which is why I included a video at the bottom.

In detail:

The Button Row: (from left)

the leftmost button is a ‘momentary’ action that clears the entire painted area and resets the cursor.

The 2nd button is a set/clear action (set by touch inside the box, cleared by touch just to the left, outside the box) It turns on a horizontal ‘stutter’ function that randomizes the rate of the cursor’s travel. The likelihood of the randomization is set by the left hardware slider on the top of the instrument.

The 3rd button is a set/clear action. It turns on quantization function that quantizes the pitch outputs to either pentatonic, or diatonic intervals . The scale is set by the switch on the top of the instrument.

The 4th button is a set/clear action. It turns on a pitch randomization function that adds or subtracts a random offset from the pitch derived from the vertical position of the yellow pixels. The width of the potential offset is set by the right hardware slider on the top of the instrument.

If the slider is pushed all the way to the top of its travel a blue LED will light up and ‘Freak Out Mode’ is invoked. All quantization is ignored, and the controller will ignore the vertical dimension of the yellow pixels completely and improvise a random pitch over the whole vertical range of the controller.

The Tempo Bar:

The tempo bar sets the base rate at which the cursor loops left->right & plays the ‘finger-painted’ yellow figures. The bar changes color to indicate the rate set by the last touch. (the decision to use this display style vs. (ie) a histogram is discussed in the ‘Why’ section)

The Finger-Paint Canvas:

This area is normally black. A blue vertical cursor loops from left to right across it at the rate set by the Tempo Bar (+ any optional Stutter set by the 2nd button) Touching the screen will ‘paint’ yellow pixels. The blue cursor’s passage over these pixels generates the controllers outputs. If this area is empty no output is produced.

Hey doc, why didn’t you…?

As mentioned before, this kind of a project is not the kind of thing I normally build. One overarching reason for this is that, in my day job I write software, lots & lots of it. So by the time I get home from work to my REAL avocation, I’m pretty much psychologically DONE with coding for the day. After all, music-control software that does this kind of thing (ie Ableton Live) is profuse & commonplace nowadays. There are even smartphone apps that will do this type of task. I decided to develop this controller using an extremely primitive 8-bit(!) platform. I did this because I am very old and when I entered the software profession the hardware was profoundly constrained by present (2019) standards. These draconian limitations forced the designer to exercise a lot of creativity in order to squeeze the maximum performance out of the minimum resources. I was nostalgic for those challenges. I see no evidence that the skills of programmers have improved because the sophistication of the platforms has improved.

Two examples of why this thing works ‘funny’:

1-I could have designed a histogram slider display to show the state of the tempo bar. But since I used an extremely simple processor, every line of code executed slows down the real-time response of the whole application. But the touchscreen had a ‘Fill(color)’ command that would fill a rectangle with any solid color in only one refresh-cycle. So rather than slow the whole boat down just to draw a display, I used the ‘freebie’ color-fill feature . I’m very attuned to color and so I designed it to map the speed to the natural spectrum.

2-My first prototype for this gadget did not use the tiny 8-bit platform. It used a 32-bit platform that allowed for multi-threaded processing. To oversimplify a bit, this meant I could run two ‘programs’ simultaneously; one to scan the touchscreen, and another separate program to process the inputs from the screen-scan program and squirt-out the outputs. It worked very well, but that design was just too much like my stultifying day-job . In a sense, it was too easy. So I changed paths to the tiny 8-bit processor. This meant that as I slowed the ‘tempo’ down the touchscreen would react commensurately slower to the players touches. This limitation caused me to reject the 8-bit platform approach at first. But I decided to try it anyway and when I played the two prototypes side-by-side, even though the 32-bit version worked ‘better’, it was just not substantially distinct from some free Android app I could find anywhere. The 32-bit version just did what I expected it to do. Ho-friggin’ HUM!

On the other hand, the quirks of the 8-bit app at very slow tempos immediately created serendipitous outputs that sounded way better than just a robot following my commands with perfect undeviating conformance. Sure there are some compromises, but to my ear, there was NO comparison. The quirky 8-bit version wins hands-down!

Y’know…

Robotics companies are disconcertingly close to creating robots for sex. I’m sure the designers of the software for these creations have much more skill than I do. But I respectfully and humbly submit that they might want to take a lesson from the story of my development of this insignificant project, specifically regarding the fact that nothing is LESS gratifying than a device that gives you exactly what you want.