Multiplexing 8 analog inputs using a CD4051B

[Fatlimey]

ok so i have multiplexers wired up and am getting some odd results,seems like im getting notes of F-1, F#-1 G-1. If i turn on midi learn in traktor it seems like its constantly scrolling through the notes.Have i missed something? Any advice?

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.

[sidetrakd]

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?

[Fatlimey]

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?

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.

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?

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.

[sidetrakd]

Good catch! .... No reason to have it there anymore.

Great, thanks. It works great when bit 11 is masked out.

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;

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;
	const uint8_t CC_OFFSET = 102 - MIDI_ANALOG_CC;
        ...
        midi_stream_cc(MIDI_ANALOG_CC + i, value);
        ...
        midi_stream_cc(MIDI_ANALOG_CC + i + CC_OFFSET, 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.

[Fatlimey]

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.

[sidetrakd]

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!!

[sidetrakd]

sneak peek

[Fatlimey]

That's excellent work. 8 analog, 16 additional digital.
Does it have additional LEDs?

[sidetrakd]

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.

[Fatlimey]

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?