At 12:43 AM 10/9/2006 -0000, djbrow54 wrote:
>Yea, fuzzing, that's what I was doing. I just didn't want to appear
>to be too sophisticated by citing my use of advanced digital testing
>methodologies. I thought it might go over everyone's head. And, of
>course, instead of using the more traditional structured queues of
>fuzzy data, I wrote a real-time midi random event fuzzing generator.
>Now, of course, the use of fuzzing is controversial because of invalid
>input data. However, I wanted to ensure that the MOTM-650 would
>withstand a midi data stream security attack. You can rest assured
>that your MOTM-650 is being subjected to the most advanced and
>rigorous testing methodologies and the result will be advanced
>security in hostile midi environments. Yea, that's what I was doing.
As one of the 650's firmware developers, I think that's great. I welcome the torture test. The 650 should be able to respond predictably to any midi data, whether valid or invalid. Do your worst. ;)
As for the observed problem - it turns out the 650 WILL choke on a valid note #, 127 (7fh), but ONLY when the sustain pedal is used. This is due to a bad decision I made 10 years ago when designing the firmware for a synth that could only respond to 64 notes. I chose to use the msbit to hold the sustain status, because I was trying to save as many bytes of RAM as possible. Using the msbit works fine for notes 0-126. For #127, when a note is sustained, it looks like just like an unused note (to the note release section of the code, that is). Hence the hung notes. :(
So, I am faced with either rewriting a lot of code, or just ignoring note #127. I've chosen the latter, and that'll be in RC2 (hopefully tomorrow). To those who own 128 key keyboards, and to those who transpose their music up so their dogs can enjoy it, I apologize. ;) If enough people complain, I'll consider a rewrite. I seriously doubt anyone else will notice note #127 is gone, though.
Jeffrey