A HA! Ok, so the SoftwareSerial library turns off interrupts while it's writing to its tx pin.

So when I do this:

soundgin.write(27); //Soundgin Command
  soundgin.write(88); //Osc A1
  soundgin.write(note);

  soundgin.write(27); //Soundgin Command
  soundgin.write(89); //Osc A2
  soundgin.write(note);

  soundgin.write(27); //Soundgin Command
  soundgin.write(90); //Osc A3
  soundgin.write(note);

  soundgin.write(27); //Soundgin Command
  soundgin.write(120); //Osc B1
  soundgin.write(note);

  soundgin.write(27); //Soundgin Command
  soundgin.write(121); //Osc B2
  soundgin.write(note);

  soundgin.write(27); //Soundgin Command
  soundgin.write(122); //Osc B3
  soundgin.write(note);

We are potentially losing a whole bunch of MIDI messages while it's doing all those soundgin.write() calls. However, commenting everything except Osc A1 out doesn't seem to make it any better... hmm.

 

Can you show that piece of code?

 

Sure, here's the code:

void SoftwareSerial::print(uint8_t b)
{
  if (_baudRate == 0)
    return;
   
  int bitDelay = _bitPeriod - clockCyclesToMicroseconds(50); // a digitalWrite is about 50 cycles
  byte mask;

  digitalWrite(_transmitPin, LOW);
  delayMicroseconds(bitDelay);

  for (mask = 0x01; mask; mask <<= 1) {
    if (b & mask){ // choose bit
      digitalWrite(_transmitPin,HIGH); // send 1
    }
    else{
      digitalWrite(_transmitPin,LOW); // send 1
    }
    delayMicroseconds(bitDelay);
  }

  digitalWrite(_transmitPin, HIGH);
  delayMicroseconds(bitDelay);
}

And it can be found in https://code.google.com/p/arduino/s...ries/SoftwareSerial/SoftwareSerial.cpp?r=1119

The problem, I think, is that the delayMicroseconds while we're talking to the soundgin prevents interrupts, so any time during the 10 bit transmission we could have gotten a new midi message and missed it.

 

Well then it is not based on a timer and its interrupt, but on delay loops which are busy-waititing in a loop.
You would want to have a timer interrupt at 9600Hz that will put out each bit, instead of waiting in a looop.

 

Ok, so if I'm understanding this correctly, since none of the other software serial libraries would work with this board, my choices are to either scrap the board and remake as a shield for the MEGA so I can get 2 more hardware serial ports, or else implement my own software serial port from scratch? And that would involve keeping a buffer in RAM and assigning a timer interrupt to send a byte out from that buffer every 1/9600 of a second?

 

It would send 1 bit every 1/9600 second, but otherwise you are correct. What I would probably do is get an arduino board with a better microcontroller, or ditch arduino altogether and get an adaptor board for the smd quad pack packages and write your own code.

 

So, just for giggles, I downloaded Arduino 1.0.3, which is the one he used in the video, and also the old version of the MIDI library. The original firmware with no modifications compiles and uploads just fine, but the behavior is still b0rken. So... yeah. Even the retro-compiler can't save me now. Guess it's time to start designing a shield for the Mega.

 

Sure, here's the code:
...
And it can be found in https://code.google.com/p/arduino/s...ries/SoftwareSerial/SoftwareSerial.cpp?r=1119

The problem, I think, is that the delayMicroseconds while we're talking to the soundgin prevents interrupts, so any time during the 10 bit transmission we could have gotten a new midi message and missed it.

I thought there was a new software serial interface in Arduino based on interrupts from the "NewSoftSerial library by Mikal Hart." Why aren't you using that one?

https://www.arduino.cc/en/Reference/SoftwareSerial

 

That's what this one is. It's been the standard SoftwareSerial library in the Arduino IDE since 1.0. They just renamed it SoftwareSerial instead of NewSoftSerial.

 

New, lower cost idea: I could replace the atmega with a Teensy3.2 held sideways in the slot that the DIP socket used to be... that would get me dual hardware UARTs without adding a giant hunk of Mega on top.

EDIT: No, that wouldn't work... the Teensy is 3.3v.

 

Hahahaha ok so a coworker said he still thought the opto was the problem, so I replaced the opto section with the values I got from the updated notes and volts midi input circuit page... and everything works great! HELLS YEAH! Thanks to everyone for your help on this!

 

Good to know it now does what it says on the tin!

 

Yup! Next steps, add a filter and make a version with a SID chip for all the NES/C64-philes out there...