Sounds like your software is sending the MIDI note regardless of whether the CC value has changed or not. Try putting in a test before sending the MIDI CC event.
It looks like the random notes were caused by a loose wire, but I still got glitches in the CC values from the analog inputs, which I solved by changing the last line in adc_read in adc.c from
return ((topbyte & 0x07) << 8) | lowbyte;
to
return ((topbyte << 8) | lowbyte) & 0x3ff;
It seems that bit 11 was set randomly, which was interfering with the code to generate CC’s. Does this make sense? I’m not sure why bit 11 was left unmasked, maybe there is a good reason for it?
Also, the code for the superfaders has overlapping CC’s (eg, fader1 0-100% sends CC 16, 50-100% sends CC 17, fader2 0-100% also sends CC 17 etc), is this the expected behavior?
Good catch! The reason it’s left unmasked was that during development it was used as a sanity test. The ADC hardware will always return bit11 as a zero, and if that wasn’t the case our SPI code or wiring would be broken and need investigation. That’s why bit 11 was left unmasked, to verify that we’re talking to the ADC unit correctly. No reason to have it there anymore.
No, another bug, recently fixed:
const uint8_t MIDI_ANALOG_NOTE = 100;
const uint8_t MIDI_ANALOG_CC = 16;
uint8_t cc_a = MIDI_ANALOG_CC + 2*i;
uint8_t cc_b = MIDI_ANALOG_CC + 2*i + 1;
uint8_t note_a = MIDI_ANALOG_NOTE + 2*i;
uint8_t note_b = MIDI_ANALOG_NOTE + 2*i + 1;
The mapping has recently been standardized so that the only moving notes are the banks and everything else has a fixed position in the MIDI map. It seems some old code crept in while trying to get Bassnectar’s custom version working.
We’ll have another Midifighter firmware update to fix these problems and provide some new features in the near future.
Great, thanks. It works great when bit 11 is masked out.
I already solved this by splitting the CC map into two: the 0-100% CC (starting at CC 16 for a total of 16 superfaders without clashing with the CC’s defined here) and the 50-100% CC (starting at CC 102, since there are another 16 undefined CC’s in that region).
Basically:
const uint8_t MIDI_ANALOG_CC = 16;
[B]const uint8_t CC_OFFSET = 102 - MIDI_ANALOG_CC;[/B]
...
midi_stream_cc([B]MIDI_ANALOG_CC + i[/B], value);
...
midi_stream_cc([B]MIDI_ANALOG_CC + i + CC_OFFSET[/B], second_cc_value);
...
I chose this solution for two reasons: most importantly, I can have 16 superfaders without clashing with predefined CC’s and also I don’t need any multiplies to calculate the second CC. I left the note on/off code unaltered.
I just find it easier to see superfaders in raw MIDI dumps if their CCs are adjacent.
Also, respect for being pretty much the first user to hack the source. May you have much win.
Thanks,Credit goes to my brother for doing the firmware!I am learning a lot too in the process!! Multiplexers,microcontrollers and serious wiring!its been fun so far!! Nearly there now with loads of photos of the build process!! Case needs a few more coats of paint and leds need wiring! Then the headache of the custom traktor mapping!!
sneak peek 
That’s excellent work. 8 analog, 16 additional digital.
Does it have additional LEDs?
4 multiplexers for 32 analog inputs, 12 for knobs/faders (4 not connected) and 20 for buttons assigned as follows:
- 4 bank buttons (rigged up to the midifighter external bank code)
- 4 buttons (the black ones on the left) are used as “global” banks and change the midi channel for all other buttons
- 1 input used for a foot pedal
- The rest are used as general buttons (only 5 are connected)
For the analog buttons, I check the ADC value against a threshold to see if it is pushed or not (with some crude transition detection code).
LEDs are driven by a PIC, connected to the digital pins over something almost SPI (3 pins are shared with the multiplexers, the spare is used as slave select). This gives me num_pic_io - 4 LED’s (17 for my 21 I/O pin PIC): green LEDs on the bank and global bank buttons, blue on the other five buttons.
The global banks are used to select the midi channel, so the buttons always have the same notes, just on a different channel.
More details & pics when I get time to write up a build log.
You know I’m always telling people that it’s not so hard to extend the Midifighter.
Tell me, was it really that difficult? Would you encourage others to have a crack at it?
It wasn’t that difficult at all but it really helped having someone who knows what he’s at do the firmware.He says it was pretty simple and you have everything well documented!
Having him there though to help with bugs and make changes as i thought of them really made a huge difference!!
I would definitely say have a go at it! It really seemed harder than it was and now i have a custom controller with amazing capabilities!!
I will be doing a build log when i get some spare time,hopefully that will help others!
that’s amazing - really shows the potential for the midifighter to be used as a midi ‘brain’ for more complex projects… nice one 
looking forward to a parts list, some code and/or a blog/instructions guide!
Wooh - sick mod ! I’d be keen to get stuck into something like this !
Good work .
The project took up most of my spare time but i will do a write up with pics and maybe a demo video as soon as i get a few final bugs fixed(and find some time) 
I cant wait to see this, i have been drafting up MF custom designs (lots), and researching how i can mod out the MF to make all my controls work.
Came across this thread … awesome, ill be working one of these soon enough, im looking to do 24 buttons, 2 faders 2 scroll/push pots and a jog wheel type device using an optical encoder… i
might have a little hold up on this 
went to flash the midifighter and all the led’s lit up like a christmas tree
seems like a pcb fail will not flash no matter what i try
And it was just about ready..Was gonna road test it at a gig on the 23rd!
Assuming you are using a PC, did you follow all the instructions on the DFU reflash page? When you knock the Midifighter into bootloader mode using the Boot/Reset keys on the PCB it enumerates over USB as a different kind of device, one that requires a driver to be loaded on the main computer to be recognized.
Did you install the Midifigher DFU Bootloader driver? Do that, then try the Boot/Reset key technique to drop into Bootloader mode (there will be no indication from the Midifighter that this has been successful) then try a reflash using Atmel Flip.
We have recently worked out what this recurring fault is and have a solution for all new Midifighters, but it’s a little technical…
The DFU driver installed previously,since the problem I just get “Unrecognised USB Device”
Atmel Filp just goes to “Could not open USB Device”
“A little technical…” sounds great compared to switching the atmel chip for a new one which was gonna be my weekend project if you had no other solution
:eek: :eek:
Thanks for your help!!
Have I mentoned yet that I’ve never done anything like this before?Luckily Im a fast learner and the internet is a good teacher!!
Anyone following my project check this out
Had an hour last night to put up a few pics in a new thread (midifighter not working is giving me a little time!!)
Fatlimey could you shine a light on this for me?Is the problem with the atmel chip or is it somewhere else?Nothing i do is bringing it back to life.I have a spare atmel chip here just incase.