Multiplexing 8 analog inputs using a CD4051B

Home :: MIDIfighter Resources and Discussion :: Multiplexing 8 analog inputs using a CD4051BReply
Multiplexing 8 analog inputs using a CD4051B
Posted on: 20.01.2011 by robert chanda
Here's a setup that allows 8 analog inputs to be read by a single analog expansion pin (plus three digital outputs). You'll need to make a few firmware changes to make it function however so it won't work out of the box, but it's not that big a change. I can make a .hex file or a new source drop available if there's enough interest.



http://goo.gl/pIX5P



http://goo.gl/0sIGD
Celina Alabed
13.01.2012
Originally Posted by Fatlimey
Using a 16-way multiplexer like the 74HC4067 it should be simple enough.

http://www.nxp.com/documents/data_sh...HC_HCT4067.pdf

The 4 digital inputs to the chip would be the 4 digital pins of the Midifighter, so if you do this you get 16 analog inputs and no digital switches. If you want 16 inputs as well as additional switches it gets a lot more complicated and relies on you setting up an SPI bus on the digital pins and serially controling a pair of devices hanging off the same bus, or setting up a software-based I2C bus and addressing devices by bus number.

At least if you do that then adding LEDs is simply another device on the chain.
Is it possible to "stack" these 16 way multiplexers on the data pins to allow 64 total analog inputs to the 4 analog input spots on the MF board? I see that's how sidetrakd got 32 analog inputs for his build using 8 way multiplexers. The design I'm contemplating would need more than 32 analog inputs though.

edit: nevermind, answered my own question: http://www.djranking s.com/community /sho...3&postcount=56
robert chanda
01.08.2011
Originally Posted by Brinx
1. Would the 16 pins be in/out mening i could hook up leds to 4 of them and control by sending midi out on those specific pins, leaving me 12 inputs for faders, buttons,knobs and such?
Yes, multiplexer pins are bidirectional so you can connect an LED to an input/output pin and control it from the CPU side, but it will only be turned on for 1/16th of the time leaving you with a not very bright LED.

Originally Posted by Brinx
2. Would it be possible to program the firmware so that the faders and knobs connected to the multiplexer also switches CC in 4 bank mode?
Absolutely. The CPU decides what each input means at any point in time and outputs MIDI as needed.

Originally Posted by Brinx
3. Would anyone care to help me program the firmware when this is done?
After connecting up the wires it's mostly a software project. Are you believeing of doing any of this project yourself?
Dara Dresen
27.12.2012		I've been trying to figure out the select code from Mayhew. The bit shift and & operation seems a bit confusing to me. Not quite sure what is being done. I tried posting this as code, how do you guys do that? Also, am I getting the posting question cause im a newbie?

http://mayhewlabs.com/code/Mux_Shiel...In_Example.pde
Dara Dresen
27.12.2012		I was working through this code, wasn't quite sure how the input select bit shift operator and & operator were working. It seems as a filter, but a bit unclear for me..






//Mux_Shield_AnalogIn_Example
//http://mayhewlabs.com/arduino-mux-shield

/*
This example shows how to read and store all 48 pins as analog inputs into arrays and print the results over serial.
Multiplexer pin inputs that do not have a voltage reading (i.e nothing connected) will have erratic values.

To simplify this code further, one might use nested for loops or function calls.
*/

//Give convenient names to the control pins
#define CONTROL0 5
#define CONTROL1 4
#define CONTROL2 3
#define CONTROL3 2

//Create arrays for data from the the MUXs
//See the Arduino Array Reference: http://www.arduino.cc/en/Reference/Array
int mux0array[16];
int mux1array[16];
int mux2array[16];

void setup()
{
//Set MUX control pins to output
pinMode(CONTROL0, OUTPUT);
pinMode(CONTROL1, OUTPUT);
pinMode(CONTROL2, OUTPUT);
pinMode(CONTROL3, OUTPUT);

//Open the serial port at 28800 bps
Serial.begin(28800);
}


void loop()
{
//This for loop is used to scroll through and store the 16 inputs on the FIRST multiplexer
for (int i=0; i<16; i++)
{
//The following 4 commands set the correct logic for the control pins to select the desired input
//See the Arduino Bitwise AND Reference: http://www.arduino.cc/en/Reference/BitwiseAnd
//See the Aruino Bitshift Reference: http://www.arduino.cc/en/Reference/Bitshift
digitalWrite(CONTROL0, (i&15)>>3);
digitalWrite(CONTROL1, (i&7)>>2);
digitalWrite(CONTROL2, (i&3)>>1);
digitalWrite(CONTROL3, (i&1));

//Read and store the input value at a location in the array
mux0array[i] = analogRead(0);
}

//This for loop is used to scroll through the SECOND multiplexer
for (int i=0; i<16; i++)
{
digitalWrite(CONTROL0, (i&15)>>3);
digitalWrite(CONTROL1, (i&7)>>2);
digitalWrite(CONTROL2, (i&3)>>1);
digitalWrite(CONTROL3, (i&1));
mux1array[i] = analogRead(1);
}

//This for loop is used to scroll through the THIRD multiplexer
for (int i=0; i<16; i++)
{
digitalWrite(CONTROL0, (i&15)>>3);
digitalWrite(CONTROL1, (i&7)>>2);
digitalWrite(CONTROL2, (i&3)>>1);
digitalWrite(CONTROL3, (i&1));
mux2array[i] = analogRead(2);
}

//The following lines are for printing out results of array0
Serial.print("mux0array: ");
for (int i=0; i<16; i++)
{
Serial.print(mux0array[i]);
Serial.print("-");
}
Serial.println(); //line feed

//The following lines are for printing out results of array1
Serial.print("mux1array: ");
for (int i=0; i<16; i++)
{
Serial.print(mux1array[i]);
Serial.print("-");
}
Serial.println();

//The following lines are for printing out results of array2
Serial.print("mux2array: ");
for (int i=0; i<16; i++)
{
Serial.print(mux2array[i]);
Serial.print("-");
}
Serial.println();

}
Dara Dresen
27.12.2012		Was looking at this code from Mayhew, wasn't quite sure how the bitwise operator and & functionality was working to scan through the multiple inputs...

//Mux_Shield_AnalogIn_Example
//http://mayhewlabs.com/arduino-mux-shield

/*
This example shows how to read and store all 48 pins as analog inputs into arrays and print the results over serial.
Multiplexer pin inputs that do not have a voltage reading (i.e nothing connected) will have erratic values.

To simplify this code further, one might use nested for loops or function calls.
*/

//Give convenient names to the control pins
#define CONTROL0 5
#define CONTROL1 4
#define CONTROL2 3
#define CONTROL3 2

//Create arrays for data from the the MUXs
//See the Arduino Array Reference: http://www.arduino.cc/en/Reference/Array
int mux0array[16];
int mux1array[16];
int mux2array[16];

void setup()
{
//Set MUX control pins to output
pinMode(CONTROL0, OUTPUT);
pinMode(CONTROL1, OUTPUT);
pinMode(CONTROL2, OUTPUT);
pinMode(CONTROL3, OUTPUT);

//Open the serial port at 28800 bps
Serial.begin(28800);
}


void loop()
{
//This for loop is used to scroll through and store the 16 inputs on the FIRST multiplexer
for (int i=0; i<16; i++)
{
//The following 4 commands set the correct logic for the control pins to select the desired input
//See the Arduino Bitwise AND Reference: http://www.arduino.cc/en/Reference/BitwiseAnd
//See the Aruino Bitshift Reference: http://www.arduino.cc/en/Reference/Bitshift
digitalWrite(CONTROL0, (i&15)>>3);
digitalWrite(CONTROL1, (i&7)>>2);
digitalWrite(CONTROL2, (i&3)>>1);
digitalWrite(CONTROL3, (i&1));

//Read and store the input value at a location in the array
mux0array[i] = analogRead(0);
}

//This for loop is used to scroll through the SECOND multiplexer
for (int i=0; i<16; i++)
{
digitalWrite(CONTROL0, (i&15)>>3);
digitalWrite(CONTROL1, (i&7)>>2);
digitalWrite(CONTROL2, (i&3)>>1);
digitalWrite(CONTROL3, (i&1));
mux1array[i] = analogRead(1);
}

//This for loop is used to scroll through the THIRD multiplexer
for (int i=0; i<16; i++)
{
digitalWrite(CONTROL0, (i&15)>>3);
digitalWrite(CONTROL1, (i&7)>>2);
digitalWrite(CONTROL2, (i&3)>>1);
digitalWrite(CONTROL3, (i&1));
mux2array[i] = analogRead(2);
}

//The following lines are for printing out results of array0
Serial.print("mux0array: ");
for (int i=0; i<16; i++)
{
Serial.print(mux0array[i]);
Serial.print("-");
}
Serial.println(); //line feed

//The following lines are for printing out results of array1
Serial.print("mux1array: ");
for (int i=0; i<16; i++)
{
Serial.print(mux1array[i]);
Serial.print("-");
}
Serial.println();

//The following lines are for printing out results of array2
Serial.print("mux2array: ");
for (int i=0; i<16; i++)
{
Serial.print(mux2array[i]);
Serial.print("-");
}
Serial.println();

}
Kimberly Lewark
27.12.2012		Hi awacs,

Not sure if fatlimey has teensy code or where it is (too lazy to search), but what are you trying to do? I may be able to lend a hand. Not sure if I have any multiplexers handy, but I have a couple of teensy's and I remember the CD4051B being incredibly simple to use.

Actually, they really are not hard to use once you have them wired up correctly:

They have three digital inputs, a common in/out and a number of multiplexed in/out pins (8 I believe it was?). Connect the common in/out to one of the teensy's analogue pins. Connect the multiplexed pins to the faders. Connect the three digital pins to three of the teensy's general purpose pins. Configure the analogue pin as an input and the three digital pins as outputs.

Now your teensyduino code looks something like this (untested and off the top of my head, so please excuse typos and memory lapses):

Code:
int readFader (int fader_number) {
    // Select the fader from the multiplexer
    digitalWrite(MUX_DIGITAL_1, fader_number & 0x1 != 0);
    digitalWrite(MUX_DIGITAL_2, fader_number & 0x2 != 0);
    digitalWrite(MUX_DIGITAL_3, fader_number & 0x4 != 0);
    // Read the analogue value
    return analogRead(MUX_ANALOG_PIN);
}
And to use:

Code:
for (int fader = 0; fader < 8; fader++) {
    Serial.print("Fader ");
    Serial.print(fader + 1);
    Serial.print(" = ");
    Serial.println(readFader(fader));
}
Hope that helps!
Dara Dresen
27.12.2012		Hi guys,

New to the community . Very interesting topic, I was working on a multi-fader controller with Teensy and the multiplexer IC. I saw mention of Limey's Teensy code on here. Is that public anywhere? Would love to play around with it if it is
Celina Alabed
13.01.2012
Originally Posted by Fatlimey
Using a 16-way multiplexer like the 74HC4067 it should be simple enough.

http://www.nxp.com/documents/data_sh...HC_HCT4067.pdf

The 4 digital inputs to the chip would be the 4 digital pins of the Midifighter, so if you do this you get 16 analog inputs and no digital switches. If you want 16 inputs as well as additional switches it gets a lot more complicated and relies on you setting up an SPI bus on the digital pins and serially controling a pair of devices hanging off the same bus, or setting up a software-based I2C bus and addressing devices by bus number.

At least if you do that then adding LEDs is simply another device on the chain.
Is it possible to "stack" these 16 way multiplexers on the data pins to allow 64 total analog inputs to the 4 analog input spots on the MF board? I see that's how sidetrakd got 32 analog inputs for his build using 8 way multiplexers. The design I'm contemplating would need more than 32 analog inputs though.

edit: nevermind, answered my own question: http://www.djranking s.com/community /sho...3&postcount=56
Lakeisha Allaway
04.08.2011		@ Guywithknife

Thank you so much!
This will be extremely helpful when i get to the programming part!
Im very interested in the instant midi channel changing part of your script.
Kimberly Lewark
02.08.2011		The source to our (Sidetrakd and me) mod is here. It does a lot of what you want: multiplexed analog inputs, additional buttons, LEDs. Unlike fatlimeys suggestion, we do not bitbang SPI for our "digital" inputs as we don't really use digital inputs at all - instead we read the buttons as analog inputs instead where a value greater than some threshold (don't remember what I used offhand) is treated as a button being pressed.

Adding additional LEDs is more complicated, though, and does require SPI to connect to LED drivers. Again, we did not bitbang it, instead we connected our LED driver (actually, we made our own out of a PIC24H, definitely not cost effective, just we happened to have one handy) to the existing SPI pins (mk3 MF boards have solder points for these), but while the analog input/multiplexer code is all in midifighter.c, the code for the LEDs is scattered around spi.c and mod.c, so would take quite a lot more effort to get working for your mod.

In any case, I hope the code gives you some ideas to work from. Sadly I'm super busy right now, so don't really have time to give a hand.
Adolf Hit
01.08.2011
Im going to have alot of questions when it comes to the code, but im in no rush, so il try to figure out as much as possible myself!
That's the right attitude!
Lakeisha Allaway
01.08.2011		Thanks for answering my questions!

Im going to design it and build it myself, yes.
I have a design for it and some pretty good knowledge of soldering and i will build the case out of wallnut myself. Top plate will be aluminum.

When it comes to programming and altering the firmware i have no experience . I have done some super easy stuff on the arduino and thats about it.

I guess the main work would be in the programming so i guess im gonna have to learn that then

Im going to have alot of questions when it comes to the code, but im in no rush, so il try to figure out as much as possible myself!

Thx for the help!
robert chanda
01.08.2011
Originally Posted by Brinx
1. Would the 16 pins be in/out mening i could hook up leds to 4 of them and control by sending midi out on those specific pins, leaving me 12 inputs for faders, buttons,knobs and such?
Yes, multiplexer pins are bidirectional so you can connect an LED to an input/output pin and control it from the CPU side, but it will only be turned on for 1/16th of the time leaving you with a not very bright LED.

Originally Posted by Brinx
2. Would it be possible to program the firmware so that the faders and knobs connected to the multiplexer also switches CC in 4 bank mode?
Absolutely. The CPU decides what each input means at any point in time and outputs MIDI as needed.

Originally Posted by Brinx
3. Would anyone care to help me program the firmware when this is done?
After connecting up the wires it's mostly a software project. Are you believeing of doing any of this project yourself?
Lakeisha Allaway
01.08.2011		Thx Limey!

Couple of further questions:

1. Would the 16 pins be in/out mening i could hook up leds to 4 of them and control by sending midi out on those specific pins, leaving me 12 inputs for faders, buttons,knobs and such?

2. Would it be possible to program the firmware so that the faders and knobs connected to the multiplexer also switches CC in 4 bank mode?

3. Would anyone care to help me program the firmware when this is done?

Thx!

Btw. Djranking s community rocks! You guys are helpful geniuses!
robert chanda
02.08.2011		Using a 16-way multiplexer like the 74HC4067 it should be simple enough.

http://www.nxp.com/documents/data_sh...HC_HCT4067.pdf

The 4 digital inputs to the chip would be the 4 digital pins of the Midifighter, so if you do this you get 16 analog inputs and no digital switches. If you want 16 inputs as well as additional switches it gets a lot more complicated and relies on you setting up an SPI bus on the digital pins and serially controling a pair of devices hanging off the same bus, or setting up a software-based I2C bus and addressing devices by bus number.

At least if you do that then adding LEDs is simply another device on the chain.
Lakeisha Allaway
02.08.2011		I started a new thread with this question but realised it would be better suited here, so here it goes:

So i have a Midi Fighter classic wich i want to modify with a new case and a couple of extra faders, knobs and buttons (16 in total). Would it be possible to multiplex the inputs to 16 using one of theese?

http://www.electrokit.se/moduler-sty...bkort_41003469

And also how complex would the firmware editing be?
Im planing on using the Midi fighter in 4 bank mode.

Any help is highly appreciated!
Hunter Renslow
02.05.2011		Cool thanks!I assume this will be have been done with my new pcb?
No hope for the old one since i "modded" it!!
robert chanda
01.05.2011		The trick is kill the SPIEN fuse (See page 245 of the AT90USB162 datasheet) at programming time. If you have a JTAG programmer this is easy to do.

Set this bit and no more failures (we've tried glitching boards every second for 48 hours straight and no failures).
Hunter Renslow
29.04.2011		Hi Fatlimey, New pcb is on the way so I was wondering is there a way to avoid this problem happening again?Have no need for a second midifighter clock on my wall
Hunter Renslow
08.04.2011
Originally Posted by Fatlimey
We have recently worked out what this recurring fault is and have a solution for all new Midifighters, but it's a little technical...
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.
Hunter Renslow
09.04.2011		Anyone following my project check this out

http://www.djranking s.com/community /showthread.php?t=28014

Had an hour last evening to put up a few pics in a new thread (midifighter not working is giving me a little time!!)
Hunter Renslow
07.04.2011
Originally Posted by Fatlimey
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.
.
The DFU driver installed previously,since the problem I just get "Unrecognised USB Device"
Atmel Filp just goes to "Could not open USB Device"


Originally Posted by Fatlimey
We have recently worked out what this recurring fault is and have a solution for all new Midifighters, but it's a little technical...
"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!!
robert chanda
06.04.2011		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...
Hunter Renslow
06.04.2011		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!
Sherri Seick
06.04.2011		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
Hunter Renslow
06.04.2011
Originally Posted by MiL0
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!
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)
Lorelei Przybylowicz
27.03.2011
Originally Posted by sidetrakd

sneak peek
Originally Posted by 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.
Wooh - sick mod ! I'd be keen to get stuck into something like this !

Good work .
Arcelia Siebeneck
19.03.2011		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!
Hunter Renslow
11.03.2011		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!
robert chanda
11.03.2011		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?
Hunter Renslow
10.03.2011		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.
robert chanda
10.03.2011		That's excellent work. 8 analog, 16 additional digital.
Does it have additional LEDs?
Hunter Renslow
09.03.2011



sneak peek
Hunter Renslow
05.03.2011
Originally Posted by Fatlimey
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!!
robert chanda
03.03.2011		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.
Hunter Renslow
03.03.2011
Originally Posted by Fatlimey
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:
Code:
                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:
Code:
        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.
robert chanda
02.03.2011
Originally Posted by sidetrakd
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.

Originally Posted by sidetrakd
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:
Code:
                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.
Hunter Renslow
02.03.2011		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
Code:
return ((topbyte & 0x07) << 8) | lowbyte;
to
Code:
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?
robert chanda
01.03.2011
Originally Posted by sidetrakd
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.
Hunter Renslow
28.02.2011		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?

<< Back to MIDIfighter Resources and DiscussionReply
  • Page:
  • 1
  • 2
  • >>
  • Total: 58

Copyright 2012-2023
DJRANKINGS.ORG n.g.o.
Chuo-ku, Osaka, Japan

Created by Ajaxel CMS

Terms & Privacy