I couldn't go deep into the design of the firmware until I had the manufactured PCB version of the prototype, because the contacts weren't reliable, and it was hard to debug wether something was not working because of a broken connection, or because a software problem.

My plan was to take the programmed prototype to different music nerds, and allow them to build their own sequencer and make their own transgressions to it. Specially because at that time I would be a week in new york, and then in Mexico, and after that in Chile. As from from Finland it takes about a month and a lot of money to get a shipment from U.S. suppliers (for the RGB led's and the so) I bought enough materials to make other nine of these modules while I still didn't have the firmware finished, and I would receive them in New York. In this way, I could make a workshop and receive influence from other makers in many parts of the world.

Once I started developing the arduino hardware, it was easy to get the hardware to work right. I could also do some simple user interfaces such as a midi drumkit (like the korg padKontrol) or a simple 16-step sequencer.

The led's are turned on one by one by the microcontroller. Each led leg is connected to one multiplexor output, and each button aswell. The firmware is constantly scanning the two multiplexor addresses and giving a voltage or not, according to wether each led must be on or not.

//update one pixel on one of the color channels behind the mux. Be aware that redPixel function exists
void updatePixel(byte currentPixel) {
  currentPixel += 0xf;
  //nibble A is connected to the mux address for the anodes / btn inputs
  byte nibbleA = 0xF;
  //nibble B is connected to the mux for the cathodes / btn outputs
  byte nibbleB = 0xF;
  byte currentLayer = currentPixel / 16;
  if ((layers[currentLayer-1] >> (currentPixel % 16)) & 0x1) {
    //(currentPixel>>2)&12 is the same than doing floor(currentPixel/16)*4. try it  in codechef
    nibbleA &= (currentPixel % 4) + (currentPixel >> 2 & 12); //[0-15]=0,[16-31]=4,[32-47]=8,[48-63]=12
    nibbleB &= (currentPixel / 4) % 4; //~0x10 << ((currentPixel / 4) % 4); //0,0,0,0,1,1,1,1,2,2,2,2,3,3,3,3, will happen 4 times within 64 loop
    nibbleB += 8;
    //ground & power the led. strangely still works without these lines
    digitalWrite(analogA, HIGH);
    digitalWrite(analogB, LOW);
    PORTD = (nibbleB << 4) | (nibbleA);
    switch (currentLayer) {
#if COMPENSATE_R > 0
      case 3:
        delayMicroseconds( COMPENSATE_R);
        break;
#endif
#if COMPENSATE_G > 0
      case 1:
        delayMicroseconds( COMPENSATE_G);
        break;
#endif
#if COMPENSATE_B > 0
      case 2:
        delayMicroseconds( COMPENSATE_B);
        break;
#endif
    }
  }
}
//just draw a pixel disregarding the layer information
void turnPixelOn(byte currentPixel) {
  //nibble A is connected to the mux address for the anodes / btn inputs
  byte nibbleA = 0xF;
  //nibble B is connected to the mux for the cathodes / btn outputs
  byte nibbleB = 0xF;
  byte currentLayer = currentPixel >> 4;
  //(currentPixel>>2)&12 is the same than doing floor(currentPixel/16)*4. try it  in codechef
  nibbleA &= (currentPixel % 4) + (currentPixel >> 2 & 12); //[0-15]=0,[16-31]=4,[32-47]=8,[48-63]=12
  nibbleB &= (currentPixel / 4) % 4; //~0x10 << ((currentPixel / 4) % 4); //0,0,0,0,1,1,1,1,2,2,2,2,3,3,3,3, will happen 4 times within 64 loop
  nibbleB += 8;
  //ground & power the led
  /*PORTC |= 0b1;
    PORTC &= ~0b10;*/
  PORTD = (nibbleB << 4) | (nibbleA);
}

https://github.com/autotel/thesis-prototype-zero/blob/1f0f84d950a1703086b56ecbf58f549703d09475/firmware_displayer/ledScreenDriver.ino

 This worked nice, but led to the problem that, the more the microcontroller was doing, the lower that the led's refresh rate would be.

I started experimenting a bit more with the interactions, to make more interesting transgressions to my initial 16 step sequencer; but I couldn't make any longer sequences. These were my mistakes:

• I wanted to use a whole port to address the multiplexer, and use the analog inputs to detect the button presses, as to be able to detect pressure. I used PORTD. This meant that I didn't have a hardware Serial port, and thus, with a more complex code, the MIDI started lagging in time and generating hanging notes. And yes, I became a magician of debugging without Serial.
• Reliance on persistence of view for the LED's works, but the more complex the program gets, the lower the refresh rate. When I started having a decently interesting sequencer, the LED's were flickering really bad, and it got hard to use if there was too much ambient light.

My sequencer transgression workshop would have to wait a bit more.