Purpose of the digital pins on the Midi Fighter?

Home :: MIDIfighter Resources and Discussion :: Purpose of the digital pins on the Midi Fighter?Reply
Purpose of the digital pins on the Midi Fighter?
Posted on: 13.01.2012 by Celina Alabed
First I thought they were for additional buttons (my believeing being that since buttons are on-off or 1-0 then they were digital), but then I saw sidetrakd's writeup and he used analog inputs for additional arcade buttons.

Now in his case, 3 of the digital pins are being used for the analog multiplexer. But what other uses do they have, or what kinds of things were they intended for? Using those multiplexers leaves only one digital pin left, but what would I need that one for?

I'm believeing up my custom MF design right now, and I'm interested in adding potentially a large number of components, possibly more than 32 faders/pots/buttons. I came across another post that mentioned a 16 way multiplexer that would use all 4 data pins. Assuming those multiplexers could be stacked on the data pins like the one's sidetrakd is using, that would enable the use of 64 analog components from one MF board! Unless having access to more data pins is useful for something. In that case I would have to go with 2 MF boards.
Kimberly Lewark
14.01.2012
Originally Posted by einsteinx2
I can't thank you enough for all the feedback!! I have a much firmer understanding of how this project is going to pan out now. I'll do some more research and get a game plan in writing plus some layout mockups, then I'll start a build log thread. I'll definitely be bugging you for more info later!
No problem and good luck.

Originally Posted by einsteinx2
Btw, I forked your repo on GitHub, so maybe at some point we can merge my new code back into your branch, generalize any project specific stuff, and then release it as an official custom firmware for the MF platform. My goal for that being a firmware that can be flashed to any MF not just customized ones so that any our non-custom component enhancements can be used by people with just regular MFs, and potentially be merged upstream to the official MF firmware releases to make it easier for people to customize their own MFs without messing with the firmware code themselves.
Sounds good. That's what open source is all about, after all.
Celina Alabed
14.01.2012
Originally Posted by guywithknife
Another way that I've seen...
Great idea. I'll give that Wikipedia article a thorough read over as soon as I get a minute.

I can't thank you enough for all the feedback!! I have a much firmer understanding of how this project is going to pan out now. I'll do some more research and get a game plan in writing plus some layout mockups, then I'll start a build log thread. I'll definitely be bugging you for more info later!

Btw, I forked your repo on GitHub, so maybe at some point we can merge my new code back into your branch, generalize any project specific stuff, and then release it as an official custom firmware for the MF platform. My goal for that being a firmware that can be flashed to any MF not just customized ones so that any our non-custom component enhancements can be used by people with just regular MFs, and potentially be merged upstream to the official MF firmware releases to make it easier for people to customize their own MFs without messing with the firmware code themselves.
Kimberly Lewark
14.01.2012
Originally Posted by einsteinx2
OK that makes more sense. I had actually taken a quick look at that Wikipedia page, but didn't have time yet to read it in depth.

Please excuse another ignorant question has I haven't RTFMed yet, but does that mean that if you have controls, say buttons or faders, connected to an SPI slave, the SPI master would need to run a loop to continually check each slave, one after another to see if it has new input? E.g. each slave keeps a buffer of output bytes, then the master just runs through each slave, activating it's chip select pin, sending some kind of null data (unless there is some output data buffered to send), and reading in whatever data that controller has in it's buffer, operating on that data, then moving to the next chip, etc?
Yes, that's a common way of doing it. For example, the first byte might tell the master how many data bytes are waiting and then the master does that many transfers.

Another way that I've seen used by various chips (most recently, an RF transceiver module) is the use of a fifth IRQ pin which is set by the slave when it has data for the master to read. You could even share this pin between all slaves if you want to signal "one of the slaves has data" rather than "slave N has data". Its now as quick and easy as checking the state of one pin to see if you need to do any SPI transfers at all. This is very briefly mentioned in the wikipedia article under the "interrupts" heading.
Kimberly Lewark
14.01.2012
Originally Posted by einsteinx2
Wow, we really are on the same page. Before editing my last post for length, I had originally included a whole paragraph about how my original plan was to have this controller handle Traktor + Ableton, but that it's making more sense given all the functions I want to build a separate or add-on controller for Ableton instead of integrating it all.
... SNIP ...
This sounds a lot like what we are planning - feeding Traktor through Ableton and using Ableton for effects, samples and so on. I am also starting to get into max4live to customize Ableton to our needs using Max/MSP.
One thing we are doing is connecting a bunch of external devices to eg let us control lighting or converting sensors to MIDI. Ableton lets us basically create super faders and max4live can talk to devices that cannot do MIDI.


Originally Posted by einsteinx2
This is very very interesting... The unlimited flexibility is very tempting, especially since it would allow me to use just one board (though I don't even know if it would cost any less given the extra PICs to buy, etc).
Exactly, though at the cost of extra complexity both in the circuitry and the software. Still, for a large complex design, it is probably worth it.
Microcontrollers are cheap - a PIC costs between $2 and $10 depending on model and size, but you will probably need some tools as I mention below. If you do use PIC24 (instead of multiple MF's or instead of atmel or other micros), I would suggest a PIC24H (PIC24HJ32GP202 costs $4.23 for a surface mount one and about $4.40 for a DIP one on mouser) as I found them easier to get working properly, though the PIC24F's seem to be slightly cheaper.

Originally Posted by einsteinx2
I've looked through your code (specifically spi.c) and it actually looks fairly straightforward. If I'm understanding it correctly, you would connect the SPI links using the dedicated SPI pins on the MF. Then you could have 4 SPI slaves connected one each to the 4 data pins, using the data pins as chip selects. Each SPI slave could be a PIC that has full control over any number of additional components or controllers. To communicate out to the controllers, the code would be as simple as something like (rough pseudocode):
... code omitted ...

Then whatever implementation is necessary would be written into the code for each PIC (in my case, preferably using controllers that can be programmed in C).
Yes, exactly. Though you may want to put the spi slave install calls into main to avoid running them again in case the usb disconnects and reconnects without resetting the midifighter (not sure if this can happen and not the end of the world anyway, but whatever).
You could also use an atmel micro instead of a PIC if you want everything to use the same toolchain. Either way, you may need to buy a hardware programmer as the micros may not come pre-flashed with a usb bootloader.

For a PIC, I'd suggest getting a PICKit on ebay (I have both a 2 and 3 - a 3 is needed for some chips, but the 2 has built a in UART tool and logic analyzer. Having two is useful for testing communication between two PICs too as you can then run both with the in circuit debugger).

Originally Posted by einsteinx2
Now that I've thought it out, it actually sounds reasonably straightforward. What I'm not seeing though is how is the reverse communication handled? Has that code just not been added to the firmware yet?
SPI is a bidirectional (full duplex) protocol - when you send a byte, you also receive a byte. I didn't need this as my LED driver PIC never sent anything back.
Code:
data_received = spi_transmit(data_to_send);
Originally Posted by einsteinx2
Am I correct in assuming that the chip select can come from both sides? So the reverse communication would be handled in expansion.c? E.g. in exp_buffer_digital_inputs read which pin is active and handle a read... somehow. Though wouldn't that cause problems when you're setting a chip select pin to send out data and a different chip is trying to return data? I feel like I'm missing something there.
No, SPI is a master-slave protocol. You have one master and multiple slaves - which slave is chosen by the chip select (also commonly called slave select or SS). Take a look at the Wikipedia article[1] for more details and examples of a few ways of connecting multiple slaves.
The great thing about SPI is its a very simple protocol so is easy to implement in software should you ever need to, has a pretty high transfer rate and only uses 3 pins + one SS per slave.

[1] [ame="http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus"]Serial Peripheral Interface Bus - Wikipedia, the free encyclopedia[/ame]


EDIT: why is the community messing up the links??
Kimberly Lewark
14.01.2012
Originally Posted by einsteinx2
Sorry I should have prefaced all this with some background, I know what it's like trying to talk tech when you don't know what level to speak on. My full time job (or really two full time jobs considering the amount of hours I work ) is software development. I mainly use Objective-C and Java, but my iOS app has a some code in C and C++ because it deals with audio streaming and playback (shameless plug: isubapp.com ). I've taken a few quick looks at the MF firmware code and it looks very well organized and commented, so I should be able to add whatever features are needed. I took at look at your PIC code and assembly is not something I have any experience with, but that is also very well commented (thanks again for that!) and is not a lot of code, so I should be able to figure out what I need to with enough reading when the time comes.

I have quite a bit of experience soldering as I used to do a lot of Xbox modding back in the day and have a mid grade soldering station + all the paraphernalia. What I'm not very experienced with is actual hardware design, electrical schematics, etc, hence my noobish questions about the MF pins.
Excellent, that makes things a lot easier. I usually default to assuming that whoever I'm talking to isn't a programmer, but obviously that's not always true. You shouldn't have a problem with the Midifighter code, its pretty logically designed and reasonably straightforward.

Originally Posted by einsteinx2
I took at look at your PIC code and assembly is not something I have any experience with
Well, you may not need a PIC at all. Like I said, I used one because I had one at hand, but using an actual LED driver would make more sense. Secondly, if you do need another microcontroller and you choose a PIC24 (you could use another atmel for example), you can (and probably should) use C - I only used assembly because I wanted an excuse to learn the PIC24 architecture better.

(note PIC24 is the 16bit line of PIC micro, PIC16 is the more common 8bit micro and it seems these typically are programmed in assembly, but the assembly for those is slightly different from the PIC24)

Originally Posted by einsteinx2
Regarding my overall plan for this project, the idea I'm kicking around is to make a "super" controller for Traktor that handles all functions necessary for 2 decks + 8 sample decks + effects without using different banks or shift keys. Just one-to-one button to function. The main reason for that is I want to be able to press any particular button or use any fader without having to believe about what state it's in. That would allow me to really develop a muscle memory for the board.

... SNIP ...

Sounds good, I just dug through the code before posting this and saw the function, looks pretty straightforward.

Thanks for all the input and sorry for the wall of text!
Sounds interesting. We are slowly working on a from-scratch controller with similar ideas (though we do have some mode selection) so that it works exactly 100% how we want/need it. It won't be done for a long time yet though since we're still experimenting (eg with ableton live as well as traktor) to see what works best and what exactly we want out of a controller.

Now, my original plan, before I decided to do the entire thing from scratch, was to use the Midifighter only for its 16 buttons, the USB device and MIDI processing unit. Everything else was going to be connected to it over the expansion pins using SPI. This way I can daisy chain as many devices on as I need (with some limitations: eventually latency would be a problem). For example, I could connect shift registers to a micro and have as many buttons as I want, or I could attach twenty multiplexers to a PIC or whatever. This would also allow you to connect LED drivers (including for multicoloured LED's), encoders, LCD's or whatever else. You would then use the Midifighter to convert between your internal data format and MIDI and have it tell the connected devices what to do (and poll them for fader/button state).

This gives you a lot more flexibility in regards to what and how many peripherals you can support without needing two midifighters to talk to each other, but it will also mean you will potentially have a lot of microcontroller learning to do (hint: even though it often doesn't seem like it, most answers are found in the microcontrollers datasheet - but it may take some time to decipher.. at least for me).


I'm having a friend that works in a metal shop CNC me an aluminum case that would cover both MF boards, and inside I would have them attached to a USB hub with just one female USB port visible on the outside of the case. My mapping would deal with handling the appropriate functions on each MF board, but conceptually it would be one single controller.
A reasonable plan. Split your design into two (or more) pieces and treat each piece as a separate controller, each using its own midifighter. Then put it all into one case with a usb hub and nobody needs to know its not a single controller inside and deal with that in the mappings.

You're right - this is certainly the easier approach!

The real question is how badly I need LED feedback. I can believe of a few cool uses for it, but not sure if it's really necessary since I have the laptop screen in front of me. On the MF mappings it's mostly used to show what mode you're in and I won't have modes on this controller. The only really useful thing I could need them for would be on toggle effects.
True. Besides lighting when you press a button (which you can achieve by connecting the LED directly to the button), the rest seems to mainly be for handling states. Even in our mod, the LEDs are only used for
  1. lighting when a button is pressed (can be achieved by wiring to button)
  2. showing what banks you're in (displaying what state the controller is in)
Kimberly Lewark
13.01.2012
Originally Posted by einsteinx2
From re-reading your thread, it looks like you're using that 4th pin to control the LEDs.
We use the AT90USB162 (the microcontroller which the midifighter uses) hardware SPI to talk to an LED driver (actually a PIC24 microcontroller, but only because I happened do already have one here - its totally overkill using one instead of an actual LED driver). SPI is a four wire protocol (send, receive, chip select and clock) - we used the fourth digital pin as the chip select, since we need to manually set this. For the other three pins, we used the same pins which the Midifighter uses to talk to its LED driver and analog to digital converter - it turned out that these pins are exposed as solder points in the middle of the board (these solder points were not there in earlier versions of the Midifighter circuit boards). You could also bitbang software SPI (ie do it manually instead of using the micro's built in support), in which case you can use the three other digital pins for the three remaining SPI pins (actually, we only need two: clock and send, since we only communicate one way). This way digital 4 is used as chip select and the other digitals are used for both the multiplexers AND to communicate with the LED driver.

This works because the LED driver only reacts to those pins if chip select is set. If its not set, like when the analogs are being read, the LED driver ignores whatever you do with the pins. Since you won't be reading the analogs while sending data to the LED driver, it doesn't matter that the multiplexers are also seeing the digital data. I was originally doing it this way and swapped to the other approach so I could use the hardware SPI after we got a board with the new solder points.


Originally Posted by einsteinx2
I'll need to get a second MF board
Sorry, I don't understand where a second board fits into this. Can you explain what you want to do with it and why you need a second board?

Originally Posted by einsteinx2
full LED control.
If you mean that you want to be able to control the LED's through MIDI, you will need to modify the firmware to do this. I don't know offhand what you will need to make this work - I don't believe I ever fully implemented this in our mod because we haven't needed it. We really only needed to be able to control the LED's from the Midifighter firmware so that we can visually display what bank your on (our Midifighter mod has buttons that act like external four banks mode with leds highlighting the selected bank; it also has a "global" bank which basically changes the MIDI channel, this also has an LED to show which bank is selected)

Originally Posted by einsteinx2
1. Would it be possible to control all LEDs on the board using just one midi fighter (allowing for 32 extra buttons/faders/pots to connect to one of the boards) or does the midi fighter getting the LED midi messages need to be the same one that has the button/fader/pot that the LED corresponds to?
If you have more than one board, they will show up in traktor as two MIDI controllers. You will also need to connect both to your computer through USB. Communicating between the two would also be problematic.

Originally Posted by einsteinx2
2. Does the mf currently sync the state of it's CC controls back to Traktor without having to first move the fader/pot? For example, I have a Numark Mixtrack, and when I first start up Traktor, I have to literally move very single control on the board to get it to sync it's position up to Traktor.
I'm guessing that the general way those faders/pots are used is that they only send a midi message on a change. So I'm believeing I just need to add a function to the firmware to send the value of all CC controls when it is first connected. Does the MF already do this or something similar, and if not, does the idea sound correct?
It only sends a CC when its values changes and there is no sync. There's an "on usb connect" function in the firmware. Your best bet would be to write a sync function like you said and call it from there.

Sorry if some of the above is too simplified or too complicated. I wasn't sure what level of experience (eg with programming) you have so didn't know how detailed or simplified my explanation should be. For example, if something isn't readily available, you will need to add it in the firmware - I don't know if this is a problem for you or not.
Celina Alabed
13.01.2012		First I thought they were for additional buttons (my believeing being that since buttons are on-off or 1-0 then they were digital), but then I saw sidetrakd's writeup and he used analog inputs for additional arcade buttons.

Now in his case, 3 of the digital pins are being used for the analog multiplexer. But what other uses do they have, or what kinds of things were they intended for? Using those multiplexers leaves only one digital pin left, but what would I need that one for?

I'm believeing up my custom MF design right now, and I'm interested in adding potentially a large number of components, possibly more than 32 faders/pots/buttons. I came across another post that mentioned a 16 way multiplexer that would use all 4 data pins. Assuming those multiplexers could be stacked on the data pins like the one's sidetrakd is using, that would enable the use of 64 analog components from one MF board! Unless having access to more data pins is useful for something. In that case I would have to go with 2 MF boards.
Kimberly Lewark
14.01.2012
Originally Posted by einsteinx2
I can't thank you enough for all the feedback!! I have a much firmer understanding of how this project is going to pan out now. I'll do some more research and get a game plan in writing plus some layout mockups, then I'll start a build log thread. I'll definitely be bugging you for more info later!
No problem and good luck.

Originally Posted by einsteinx2
Btw, I forked your repo on GitHub, so maybe at some point we can merge my new code back into your branch, generalize any project specific stuff, and then release it as an official custom firmware for the MF platform. My goal for that being a firmware that can be flashed to any MF not just customized ones so that any our non-custom component enhancements can be used by people with just regular MFs, and potentially be merged upstream to the official MF firmware releases to make it easier for people to customize their own MFs without messing with the firmware code themselves.
Sounds good. That's what open source is all about, after all.
Celina Alabed
14.01.2012
Originally Posted by guywithknife
Another way that I've seen...
Great idea. I'll give that Wikipedia article a thorough read over as soon as I get a minute.

I can't thank you enough for all the feedback!! I have a much firmer understanding of how this project is going to pan out now. I'll do some more research and get a game plan in writing plus some layout mockups, then I'll start a build log thread. I'll definitely be bugging you for more info later!

Btw, I forked your repo on GitHub, so maybe at some point we can merge my new code back into your branch, generalize any project specific stuff, and then release it as an official custom firmware for the MF platform. My goal for that being a firmware that can be flashed to any MF not just customized ones so that any our non-custom component enhancements can be used by people with just regular MFs, and potentially be merged upstream to the official MF firmware releases to make it easier for people to customize their own MFs without messing with the firmware code themselves.
Kimberly Lewark
14.01.2012
Originally Posted by einsteinx2
OK that makes more sense. I had actually taken a quick look at that Wikipedia page, but didn't have time yet to read it in depth.

Please excuse another ignorant question has I haven't RTFMed yet, but does that mean that if you have controls, say buttons or faders, connected to an SPI slave, the SPI master would need to run a loop to continually check each slave, one after another to see if it has new input? E.g. each slave keeps a buffer of output bytes, then the master just runs through each slave, activating it's chip select pin, sending some kind of null data (unless there is some output data buffered to send), and reading in whatever data that controller has in it's buffer, operating on that data, then moving to the next chip, etc?
Yes, that's a common way of doing it. For example, the first byte might tell the master how many data bytes are waiting and then the master does that many transfers.

Another way that I've seen used by various chips (most recently, an RF transceiver module) is the use of a fifth IRQ pin which is set by the slave when it has data for the master to read. You could even share this pin between all slaves if you want to signal "one of the slaves has data" rather than "slave N has data". Its now as quick and easy as checking the state of one pin to see if you need to do any SPI transfers at all. This is very briefly mentioned in the wikipedia article under the "interrupts" heading.
Celina Alabed
14.01.2012
Originally Posted by guywithknife
No, SPI is a master-slave protocol....
OK that makes more sense. I had actually taken a quick look at that Wikipedia page, but didn't have time yet to read it in depth.

Please excuse another ignorant question has I haven't RTFMed yet, but does that mean that if you have controls, say buttons or faders, connected to an SPI slave, the SPI master would need to run a loop to continually check each slave, one after another to see if it has new input? E.g. each slave keeps a buffer of output bytes, then the master just runs through each slave, activating it's chip select pin, sending some kind of null data (unless there is some output data buffered to send), and reading in whatever data that controller has in it's buffer, operating on that data, then moving to the next chip, etc?
Kimberly Lewark
14.01.2012
Originally Posted by einsteinx2
Wow, we really are on the same page. Before editing my last post for length, I had originally included a whole paragraph about how my original plan was to have this controller handle Traktor + Ableton, but that it's making more sense given all the functions I want to build a separate or add-on controller for Ableton instead of integrating it all.
... SNIP ...
This sounds a lot like what we are planning - feeding Traktor through Ableton and using Ableton for effects, samples and so on. I am also starting to get into max4live to customize Ableton to our needs using Max/MSP.
One thing we are doing is connecting a bunch of external devices to eg let us control lighting or converting sensors to MIDI. Ableton lets us basically create super faders and max4live can talk to devices that cannot do MIDI.


Originally Posted by einsteinx2
This is very very interesting... The unlimited flexibility is very tempting, especially since it would allow me to use just one board (though I don't even know if it would cost any less given the extra PICs to buy, etc).
Exactly, though at the cost of extra complexity both in the circuitry and the software. Still, for a large complex design, it is probably worth it.
Microcontrollers are cheap - a PIC costs between $2 and $10 depending on model and size, but you will probably need some tools as I mention below. If you do use PIC24 (instead of multiple MF's or instead of atmel or other micros), I would suggest a PIC24H (PIC24HJ32GP202 costs $4.23 for a surface mount one and about $4.40 for a DIP one on mouser) as I found them easier to get working properly, though the PIC24F's seem to be slightly cheaper.

Originally Posted by einsteinx2
I've looked through your code (specifically spi.c) and it actually looks fairly straightforward. If I'm understanding it correctly, you would connect the SPI links using the dedicated SPI pins on the MF. Then you could have 4 SPI slaves connected one each to the 4 data pins, using the data pins as chip selects. Each SPI slave could be a PIC that has full control over any number of additional components or controllers. To communicate out to the controllers, the code would be as simple as something like (rough pseudocode):
... code omitted ...

Then whatever implementation is necessary would be written into the code for each PIC (in my case, preferably using controllers that can be programmed in C).
Yes, exactly. Though you may want to put the spi slave install calls into main to avoid running them again in case the usb disconnects and reconnects without resetting the midifighter (not sure if this can happen and not the end of the world anyway, but whatever).
You could also use an atmel micro instead of a PIC if you want everything to use the same toolchain. Either way, you may need to buy a hardware programmer as the micros may not come pre-flashed with a usb bootloader.

For a PIC, I'd suggest getting a PICKit on ebay (I have both a 2 and 3 - a 3 is needed for some chips, but the 2 has built a in UART tool and logic analyzer. Having two is useful for testing communication between two PICs too as you can then run both with the in circuit debugger).

Originally Posted by einsteinx2
Now that I've thought it out, it actually sounds reasonably straightforward. What I'm not seeing though is how is the reverse communication handled? Has that code just not been added to the firmware yet?
SPI is a bidirectional (full duplex) protocol - when you send a byte, you also receive a byte. I didn't need this as my LED driver PIC never sent anything back.
Code:
data_received = spi_transmit(data_to_send);
Originally Posted by einsteinx2
Am I correct in assuming that the chip select can come from both sides? So the reverse communication would be handled in expansion.c? E.g. in exp_buffer_digital_inputs read which pin is active and handle a read... somehow. Though wouldn't that cause problems when you're setting a chip select pin to send out data and a different chip is trying to return data? I feel like I'm missing something there.
No, SPI is a master-slave protocol. You have one master and multiple slaves - which slave is chosen by the chip select (also commonly called slave select or SS). Take a look at the Wikipedia article[1] for more details and examples of a few ways of connecting multiple slaves.
The great thing about SPI is its a very simple protocol so is easy to implement in software should you ever need to, has a pretty high transfer rate and only uses 3 pins + one SS per slave.

[1] [ame="http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus"]Serial Peripheral Interface Bus - Wikipedia, the free encyclopedia[/ame]


EDIT: why is the community messing up the links??
Celina Alabed
14.01.2012
Originally Posted by guywithknife
I usually default to assuming that whoever I'm talking to isn't a programmer, but obviously that's not always true.
Not an unreasonably assumption as more often then not you'd be correct

Originally Posted by guywithknife
Sounds interesting. We are slowly working on a from-scratch controller with similar ideas (though we do have some mode selection) so that it works exactly 100% how we want/need it. It won't be done for a long time yet though since we're still experimenting (eg with ableton live as well as traktor) to see what works best and what exactly we want out of a controller.
Wow, we really are on the same page. Before editing my last post for length, I had originally included a whole paragraph about how my original plan was to have this controller handle Traktor + Ableton, but that it's making more sense given all the functions I want to build a separate or add-on controller for Ableton instead of integrating it all.

My eventual goal is to route the 4 Traktor decks to 4 channels in Ableton so that each deck can have it's own effects rack and I would do all the actual mixer functionality in Ableton. The big limitation in Traktor right now is that there are only 4 (or 12 depending on the layout) effects slots. So there could be situations where I want to use 2 mutually exclusive effects or the same effect on 2 or more decks with different parameters. Using Ableton for that side of things would give unlimited flexibility.

Also, I like the ability in Ableton to have essentially unlimited sample slots, versus the maximum of 16 in Traktor. Plus, I have a x0xb0x (TB-303 clone) that I'm in the process of soldering together that I would love to hook into a 5th channel in Ableton to include as part of my sets. Then I could do sick acid buildups on the fly without using samples, and can have it connected to the master clock using midi. Also looking to build a SID based synth as well. Eventually I see having essentially a full live music rig included in my DJ setup to allow me to play a combination of my own premade music, other's premade music, and live music on the fly.

I come from a pretty traditional DJing background, started on vinyl when CDJs were just getting popular, learned mostly with real vinyl, then got Serato so I could buy tracks digitally, and practiced on CDJ1000's a lot because that's what I played out at the clubs. Got out of DJing altogether a few years ago and just started getting into it again. To be honest, traditional track to track mixing kinda bores me. I know how to beatmatch, so there's nothing to prove there, but just "beatmatch, eq, beatmatch, eq, rinse, repeat" for hours on end doesn't really do it for me anymore. I'm really interested in creating new music on the fly, so my sets are truly unique. Still getting comfortable on Traktor, but once I can develop some muscle memory for it I'm really looking forward to incorporating Abletone Live. My biggest issue now is my cramped controller space, so hopefully this project fixes that. I used to have perfect muscle memory for the DJM-600 and CDJ-1000s, so I could always put my hand in the right place and tweak the right thing at the right time. I want to be able to do that with my controller.

Originally Posted by guywithknife
Now, my original plan, before I decided to do the entire thing from scratch, was to use the Midifighter only for its 16 buttons, the USB device and MIDI processing unit. Everything else was going to be connected to it over the expansion pins using SPI. This way I can daisy chain as many devices on as I need (with some limitations: eventually latency would be a problem). For example, I could connect shift registers to a micro and have as many buttons as I want, or I could attach twenty multiplexers to a PIC or whatever. This would also allow you to connect LED drivers (including for multicoloured LED's), encoders, LCD's or whatever else. You would then use the Midifighter to convert between your internal data format and MIDI and have it tell the connected devices what to do (and poll them for fader/button state).

This gives you a lot more flexibility in regards to what and how many peripherals you can support without needing two midifighters to talk to each other, but it will also mean you will potentially have a lot of microcontroller learning to do (hint: even though it often doesn't seem like it, most answers are found in the microcontrollers datasheet - but it may take some time to decipher.. at least for me).
This is very very interesting... The unlimited flexibility is very tempting, especially since it would allow me to use just one board (though I don't even know if it would cost any less given the extra PICs to buy, etc).

I've looked through your code (specifically spi.c) and it actually looks fairly straightforward. If I'm understanding it correctly, you would connect the SPI links using the dedicated SPI pins on the MF. Then you could have 4 SPI slaves connected one each to the 4 data pins, using the data pins as chip selects. Each SPI slave could be a PIC that has full control over any number of additional components or controllers. To communicate out to the controllers, the code would be as simple as something like (rough pseudocode):
Code:
EVENT_USB_Device_Connect()
{
    spi_install_slave() // 4 times to set up each controller
}

do_something_with_controller(int pinId)
{
    spi_select(pinId);
    spi_transmit(); // as many times as needed for number of bytes
    spi_select_none();
}
Then whatever implementation is necessary would be written into the code for each PIC (in my case, preferably using controllers that can be programmed in C).

Now that I've thought it out, it actually sounds reasonably straightforward. What I'm not seeing though is how is the reverse communication handled? Has that code just not been added to the firmware yet?

Am I correct in assuming that the chip select can come from both sides? So the reverse communication would be handled in expansion.c? E.g. in exp_buffer_digital_inputs read which pin is active and handle a read... somehow. Though wouldn't that cause problems when you're setting a chip select pin to send out data and a different chip is trying to return data? I feel like I'm missing something there.
Kimberly Lewark
14.01.2012
Originally Posted by einsteinx2
Sorry I should have prefaced all this with some background, I know what it's like trying to talk tech when you don't know what level to speak on. My full time job (or really two full time jobs considering the amount of hours I work ) is software development. I mainly use Objective-C and Java, but my iOS app has a some code in C and C++ because it deals with audio streaming and playback (shameless plug: isubapp.com ). I've taken a few quick looks at the MF firmware code and it looks very well organized and commented, so I should be able to add whatever features are needed. I took at look at your PIC code and assembly is not something I have any experience with, but that is also very well commented (thanks again for that!) and is not a lot of code, so I should be able to figure out what I need to with enough reading when the time comes.

I have quite a bit of experience soldering as I used to do a lot of Xbox modding back in the day and have a mid grade soldering station + all the paraphernalia. What I'm not very experienced with is actual hardware design, electrical schematics, etc, hence my noobish questions about the MF pins.
Excellent, that makes things a lot easier. I usually default to assuming that whoever I'm talking to isn't a programmer, but obviously that's not always true. You shouldn't have a problem with the Midifighter code, its pretty logically designed and reasonably straightforward.

Originally Posted by einsteinx2
I took at look at your PIC code and assembly is not something I have any experience with
Well, you may not need a PIC at all. Like I said, I used one because I had one at hand, but using an actual LED driver would make more sense. Secondly, if you do need another microcontroller and you choose a PIC24 (you could use another atmel for example), you can (and probably should) use C - I only used assembly because I wanted an excuse to learn the PIC24 architecture better.

(note PIC24 is the 16bit line of PIC micro, PIC16 is the more common 8bit micro and it seems these typically are programmed in assembly, but the assembly for those is slightly different from the PIC24)

Originally Posted by einsteinx2
Regarding my overall plan for this project, the idea I'm kicking around is to make a "super" controller for Traktor that handles all functions necessary for 2 decks + 8 sample decks + effects without using different banks or shift keys. Just one-to-one button to function. The main reason for that is I want to be able to press any particular button or use any fader without having to believe about what state it's in. That would allow me to really develop a muscle memory for the board.

... SNIP ...

Sounds good, I just dug through the code before posting this and saw the function, looks pretty straightforward.

Thanks for all the input and sorry for the wall of text!
Sounds interesting. We are slowly working on a from-scratch controller with similar ideas (though we do have some mode selection) so that it works exactly 100% how we want/need it. It won't be done for a long time yet though since we're still experimenting (eg with ableton live as well as traktor) to see what works best and what exactly we want out of a controller.

Now, my original plan, before I decided to do the entire thing from scratch, was to use the Midifighter only for its 16 buttons, the USB device and MIDI processing unit. Everything else was going to be connected to it over the expansion pins using SPI. This way I can daisy chain as many devices on as I need (with some limitations: eventually latency would be a problem). For example, I could connect shift registers to a micro and have as many buttons as I want, or I could attach twenty multiplexers to a PIC or whatever. This would also allow you to connect LED drivers (including for multicoloured LED's), encoders, LCD's or whatever else. You would then use the Midifighter to convert between your internal data format and MIDI and have it tell the connected devices what to do (and poll them for fader/button state).

This gives you a lot more flexibility in regards to what and how many peripherals you can support without needing two midifighters to talk to each other, but it will also mean you will potentially have a lot of microcontroller learning to do (hint: even though it often doesn't seem like it, most answers are found in the microcontrollers datasheet - but it may take some time to decipher.. at least for me).


I'm having a friend that works in a metal shop CNC me an aluminum case that would cover both MF boards, and inside I would have them attached to a USB hub with just one female USB port visible on the outside of the case. My mapping would deal with handling the appropriate functions on each MF board, but conceptually it would be one single controller.
A reasonable plan. Split your design into two (or more) pieces and treat each piece as a separate controller, each using its own midifighter. Then put it all into one case with a usb hub and nobody needs to know its not a single controller inside and deal with that in the mappings.

You're right - this is certainly the easier approach!

The real question is how badly I need LED feedback. I can believe of a few cool uses for it, but not sure if it's really necessary since I have the laptop screen in front of me. On the MF mappings it's mostly used to show what mode you're in and I won't have modes on this controller. The only really useful thing I could need them for would be on toggle effects.
True. Besides lighting when you press a button (which you can achieve by connecting the LED directly to the button), the rest seems to mainly be for handling states. Even in our mod, the LEDs are only used for
  1. lighting when a button is pressed (can be achieved by wiring to button)
  2. showing what banks you're in (displaying what state the controller is in)
Celina Alabed
14.01.2012		Sorry I should have prefaced all this with some background, I know what it's like trying to talk tech when you don't know what level to speak on. My full time job (or really two full time jobs considering the amount of hours I work ) is software development. I mainly use Objective-C and Java, but my iOS app has a some code in C and C++ because it deals with audio streaming and playback (shameless plug: isubapp.com ). I've taken a few quick looks at the MF firmware code and it looks very well organized and commented, so I should be able to add whatever features are needed. I took at look at your PIC code and assembly is not something I have any experience with, but that is also very well commented (thanks again for that!) and is not a lot of code, so I should be able to figure out what I need to with enough reading when the time comes.

I have quite a bit of experience soldering as I used to do a lot of Xbox modding back in the day and have a mid grade soldering station + all the paraphernalia. What I'm not very experienced with is actual hardware design, electrical schematics, etc, hence my noobish questions about the MF pins.

Regarding my overall plan for this project, the idea I'm kicking around is to make a "super" controller for Traktor that handles all functions necessary for 2 decks + 8 sample decks + effects without using different banks or shift keys. Just one-to-one button to function. The main reason for that is I want to be able to press any particular button or use any fader without having to believe about what state it's in. That would allow me to really develop a muscle memory for the board.

I use my midi-fighter right now in deckalized + instant grat mode, and it's great, but I'm constantly switching modes and switching decks and it get's really confusing really fast when doing things quickly. I'd like to have all the functions I have now, plus a bunch of faders and knobs so I can ditch my Mixtrack. I basically want to build something with all the functionality of the S4 and then some, in exactly the layout that suits me the best for less money (unless you count that whole "time is money" thing, then this will be waaaaay more expensive ).

I'm still designing the board layout, so this is highly subject to change, but here's the current planned configuration:

Global:
1 cross fader
1 track select joystick (contains 2 pots but would only use one for vertical)
2 track load buttons (A & B)
2 four sample load buttons (C & D) (will do some midi trickery to select one sample, move down, select another, etc)
6 TRS jacks for pedals or expression pedals (use as yet undecided)
-----------------
12 analog inputs

Side 1 (A & C):
1 cue
1 drop queue point
1 cup
1 play/pause
8 cue point selectors
8 slicer buttons (like deckalized mapping)
1 slicer enable/disable button
4 loop buttons (different loop lengths)
2 tempo adjust buttons (nudge left, nudge right)
8 effect buttons (similar to instant grat)
3 effect knobs (similar to depeche mode video platters)
4 sample play buttons
4 sample gain knobs
4 sample filter knobs
2 tempo faders
1 gain knob (for deck A)
3 EQ knobs
1 volume fader (for deck A)
--------------
58 analog inputs

Side 2 (B & D):
duplicate of side 1
---------------
58 analog inputs

So that's 128 inputs right there. With no LED feedback, I could potentially put 4 sixteen way multiplexers per midi fighter which would give me 64 + 16 = 80 total analog inputs per MF board for a total of 160 inputs. That would give me some breathing room. But if I add feedback LEDs, I would have to use 8 way multiplexers on one of the boards, and have it control all the LEDs for both boards, then I could have 32 + 16 = 48 + 80 = 128 total inputs. Since all of my state information is in Traktor rather than the MF firmware since I'm not using banks, my thought process was that I could have my mapping in traktor set up so that when it needs to tell an LED to do something, it can inform the board that has the LED controller attached which will be controlling LEDS placed next to all controls. The 2 MF boards would never need to talk to each other because they wouldn't (I believe) need to exchange any information to have the correct LEDs light up.

The real question is how badly I need LED feedback. I can believe of a few cool uses for it, but not sure if it's really necessary since I have the laptop screen in front of me. On the MF mappings it's mostly used to show what mode you're in and I won't have modes on this controller. The only really useful thing I could need them for would be on toggle effects.

Now that I'm believeing about it, I get 16 LEDs per MF board built in, so using 2 MF boards and 16 way multiplexers I would have 32 LEDs + 160 analog inputs total. That should give me more than enough LEDs and it would give me some nice breathing room to add additional controls. I'd just end up desoldering the LEDs and running new ones to the necessary places.

I'm having a friend that works in a metal shop CNC me an aluminum case that would cover both MF boards, and inside I would have them attached to a USB hub with just one female USB port visible on the outside of the case. My mapping would deal with handling the appropriate functions on each MF board, but conceptually it would be one single controller.

Originally Posted by guywithknife
It only sends a CC when its values changes and there is no sync. There's an "on usb connect" function in the firmware. Your best bet would be to write a sync function like you said and call it from there.
Sounds good, I just dug through the code before posting this and saw the function, looks pretty straightforward.

Thanks for all the input and sorry for the wall of text!
Kimberly Lewark
13.01.2012
Originally Posted by einsteinx2
From re-reading your thread, it looks like you're using that 4th pin to control the LEDs.
We use the AT90USB162 (the microcontroller which the midifighter uses) hardware SPI to talk to an LED driver (actually a PIC24 microcontroller, but only because I happened do already have one here - its totally overkill using one instead of an actual LED driver). SPI is a four wire protocol (send, receive, chip select and clock) - we used the fourth digital pin as the chip select, since we need to manually set this. For the other three pins, we used the same pins which the Midifighter uses to talk to its LED driver and analog to digital converter - it turned out that these pins are exposed as solder points in the middle of the board (these solder points were not there in earlier versions of the Midifighter circuit boards). You could also bitbang software SPI (ie do it manually instead of using the micro's built in support), in which case you can use the three other digital pins for the three remaining SPI pins (actually, we only need two: clock and send, since we only communicate one way). This way digital 4 is used as chip select and the other digitals are used for both the multiplexers AND to communicate with the LED driver.

This works because the LED driver only reacts to those pins if chip select is set. If its not set, like when the analogs are being read, the LED driver ignores whatever you do with the pins. Since you won't be reading the analogs while sending data to the LED driver, it doesn't matter that the multiplexers are also seeing the digital data. I was originally doing it this way and swapped to the other approach so I could use the hardware SPI after we got a board with the new solder points.


Originally Posted by einsteinx2
I'll need to get a second MF board
Sorry, I don't understand where a second board fits into this. Can you explain what you want to do with it and why you need a second board?

Originally Posted by einsteinx2
full LED control.
If you mean that you want to be able to control the LED's through MIDI, you will need to modify the firmware to do this. I don't know offhand what you will need to make this work - I don't believe I ever fully implemented this in our mod because we haven't needed it. We really only needed to be able to control the LED's from the Midifighter firmware so that we can visually display what bank your on (our Midifighter mod has buttons that act like external four banks mode with leds highlighting the selected bank; it also has a "global" bank which basically changes the MIDI channel, this also has an LED to show which bank is selected)

Originally Posted by einsteinx2
1. Would it be possible to control all LEDs on the board using just one midi fighter (allowing for 32 extra buttons/faders/pots to connect to one of the boards) or does the midi fighter getting the LED midi messages need to be the same one that has the button/fader/pot that the LED corresponds to?
If you have more than one board, they will show up in traktor as two MIDI controllers. You will also need to connect both to your computer through USB. Communicating between the two would also be problematic.

Originally Posted by einsteinx2
2. Does the mf currently sync the state of it's CC controls back to Traktor without having to first move the fader/pot? For example, I have a Numark Mixtrack, and when I first start up Traktor, I have to literally move very single control on the board to get it to sync it's position up to Traktor.
I'm guessing that the general way those faders/pots are used is that they only send a midi message on a change. So I'm believeing I just need to add a function to the firmware to send the value of all CC controls when it is first connected. Does the MF already do this or something similar, and if not, does the idea sound correct?
It only sends a CC when its values changes and there is no sync. There's an "on usb connect" function in the firmware. Your best bet would be to write a sync function like you said and call it from there.

Sorry if some of the above is too simplified or too complicated. I wasn't sure what level of experience (eg with programming) you have so didn't know how detailed or simplified my explanation should be. For example, if something isn't readily available, you will need to add it in the firmware - I don't know if this is a problem for you or not.
Celina Alabed
13.01.2012		Thank you for the detailed reply, and major props on all the work on your custom controller. I'll be basing my project off of your code.

Ok that makes more sense now. When I saw that you guys were using the analog inputs for buttons I thought I was misunderstanding something.

From re-reading your thread, it looks like you're using that 4th pin to control the LEDs. I believe that pretty much seals the deal for me, I'll need to get a second MF board for this project since I want full LED control.

I just have two questions now if you don't mind:

1. Would it be possible to control all LEDs on the board using just one midi fighter (allowing for 32 extra buttons/faders/pots to connect to one of the boards) or does the midi fighter getting the LED midi messages need to be the same one that has the button/fader/pot that the LED corresponds to? Would it be something that could just be accounted for in the mapping?

2. Does the mf currently sync the state of it's CC controls back to Traktor without having to first move the fader/pot? For example, I have a Numark Mixtrack, and when I first start up Traktor, I have to literally move very single control on the board to get it to sync it's position up to Traktor.

I'm guessing that the general way those faders/pots are used is that they only send a midi message on a change. So I'm believeing I just need to add a function to the firmware to send the value of all CC controls when it is first connected. Does the MF already do this or something similar, and if not, does the idea sound correct?
Kimberly Lewark
13.01.2012		Out of the box, the digital expansion pins are for buttons. This is how four banks external works: it uses the four digital inputs for the bank buttons.

In our mod, sidetrakd and I used the analog pins for buttons for two reasons:
  1. We needed the digital pins for the multiplexers
  2. We wanted more than four buttons


Using the analog for anything other than knobs/faders (ie something analog which generates CC's) requires the firmware to be modified.

Similarly, using the digital pins for anything other than buttons (or a single multiplexer - that functionality is included, but disabled by default, you can enable it with the update tool) requires the firmware to be modified.

Besides buttons and multiplexers, the digital pins can be used for any digital input or output. For example, you could, with a little effort, use them to communicate with another microcontroller or other device using a protocol like I2C or SPI. This would let you talk to a whole range of devices, including encoders, Arduino, memory chips, SD Cards, accelerometers, LCD's etc etc.

Of course actually making them do something useful would take a bit of firmware hacking.

<< Back to MIDIfighter Resources and DiscussionReply

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

Created by Ajaxel CMS

Terms & Privacy