As they say, necessity is the mother of invention, and something needed to be done about this. I have researched using a keypad to trigger macros but couldn't find a reliable way to have a numeric entry from a standard USB number pad. It would converse with "hotkeys" in my sequencer program and do all sorts of weird things depending on which window was "on top".

 After some searching around, I thought I had found a macro program to fit the bill, only to discover it was almost $300, and with the limited "it can do this and that" info on the site, I wasn't about to fork over that kind of cash if they had no demo to test. So after some more searching a few days later I found the FREE program "AutoHotKey".  It is script based, and can do virtually
anything at all with the press of a keyboard key.

  Now all I need to do is find a keypad. I researched gamer keypads because they are robust and usually have some form of mounting hardware. They are programmable, but as I soon discovered,
not programmable enough. So I said to myself " OK! I'll build one dammit! "

- type in a 3 digit song code (from my songbook or memory) and have it open the MIDI sequencer program if not already open,
  (FL Studio in my case) then load the song, ready to go.

- Have clearly defined Play/Pause & Stop Buttons

- Have a pedal switch that controls Play/Pause

- Be able to set the next song from the key pad and arm the pedal switch to load it when pedal pressed.

- See / feel the keys in the dark, so a large old telephone keypad will do. ( Thanks June for all the old phones! )

  I thought to myself, " why stop here? ". It's a big secret right now, but sometime in 2013 I will be performing a show with
projected video, special lighting effects, and live music to go with it, as a type of "musical" stage production.
I really need an interface that will recognize trigger codes embedded in (DVD) video, and load the appropriate song / software
setups / etc., so I can perform fluidly without any breaks in the productions flow. This takes care of having to have a sound
guy, a video guy, and a 'puter guy!

So there it is, I plan to use a USB game controller board with a telephone keypad and built-in SVGA video code interface. Am I crazy? Ha ha!

    The Video Codes:

 I am lucky enough to have a BenQ MS510 projector which has an SVGA output that sends exactly what
video is input from the PC. To be able to project video, but also use other programs, a dual output video card is required. The SVGA from the projector goes back to the SDS KeyPadz for coded video decoding.

The Video code as shown above is comprised of all 3 colors, Red, Blue & Green. The Red is
Data, the Blue is the clock, and the green causes a Latch to grab the data.

 Because of the way different media players and Codecs handle colors, I was unable to just overlap each color, i.e. blue/violet = blue and red, so I had to make the clock and data pulse
sequentially. Normally, in any 2-line serial communication, the data is set up on the data line, then the clock comes along and writes it in, but because I must stick to primary colors,
the data must be somehow held long enough for the clock pulse to clock it in.

  Using a simple delay capacitor between two 7414 invertors is an easy fix! (Diagram, left)
Because the PIC microcontrollers I love to use aren't anywhere near fast enough to deal with video signals, ( are any? ) I had to use some power hungry 74"LS"299 shift registers to get the data on to the board. The reason I put "LS" in quotes is 60mA/chip! Power pigs!

 But they are very fast, and I happen to have a few laying around...
So the video data is shifted into the '299's and the PIC chip reads each one via their OE pins, and an 8 bit bus on Port C.

  If you plan on building this as well, don't worry, I'll do up some better schematics when I have some time. So, before moving on the the simple keypad section, in a nutshell here's how the video signal and code looks /works...

  You may have noticed there are two bars? After playing around with the code and adding a CRC, which is the last 8 bits of  the sum of the first 2 bytes, I thought it's be secure enough.
By secure I mean that it won't be tripped by ordinary video graphics and images etc.. It's a one in 65536 chance.
I was wrong. Even though the code can't be zero, and it must be valid twice within 160mS, (i.e. 2 horizontal video scans) and the code, 0-65535, must be less than or equal to 999,
right away the title of one of my music videos tripped a code!
 Hence, the compliment code was born. This code must be sent at least 2 video frames (30fps) before the data code. It is a compliment (1=0,0=1) of the actual data byte, but the CRC
is true for the first two bytes. So, in the above example, code #901, you may notice the red bars are vacant on the opposite line, but only in the first 16 bits. (the last bit is the same)

  It's rock solid and hasn't monkeyed up yet.....well that way. Now there's a problem with getting the proper data. I noticed that video converted (to WMV in this case) and played back
wasn't always causing the code to trigger. So after looking at the signals coming into the shift registers, I noticed sometimes there was and extra clock pulse. The codec must've brightened
the video just slightly so the latch (green) pulse was causing a spike enough to raise the blue level. A brighter green does have blue in it. After messing around with filtering for a while,
I came up with an idea! The old adage "If you can't beat'em, join'em" rings true: Just combine the last clock pulse with the Latch pulse. This makes an awfully bright sky blue, but
totally annihilated the problem.

  After doing some "demo" videos, which start up FL Studio, and start playing a song part way through, then stopping it again, I have found those code bars at the bottom aren't even
noticeable, unless you are really looking for them. If it's right after a quick fade it's not there at all. Unfortunately, because of the 2 code structure, nothing else can be on the screen
while the code is active, except maybe a really dim image. But it's only 2 frames with a space in the middle.

  The Key Pad Circuit:

  These keypads are all standard 3x4 layout, so the PIC 16F74 only needs to pull up each row
(Port D,0-3) while checking the column inputs (Port D,4-6) Port D,7 adds another column,and is used for the extra 2 buttons for Play & Stop.

  The foot pedal can't be scanned this way as the long wire would create too much capacitance and may trigger a Play/Pause at the wrong time, so better safe than sorry. Before each keypad scan, Port D,7 is checked for a high level. If it is high before the scan has started then foot pedal has been pressed.

The outputs on port A & B are driving a 4066 quad analogue switch to "press" the game controllers buttons. I could have used transistors with this controller, but if it ever fails, who knows what might be next, so once again, for the little extra board real estate it's worth it. Each pair from the 4066 is isolated away from ground/Vdd which is a good thing as some of the keys were positive & others neg.

The board to the right is mostly accurate, except the added 75 ohm resistors to ground at SVGA inputs B, G, & R. ...and a 100k pot to ground from the base of each Q to control the bias/gain levels.
Again I'll post a more detailed image with the jumpers etc. I used photo-etching to do this board, and it was the best I've ever done ( out of 60 - 70 photo-etched boards ) Must be our new laser printer I guess. The original image is >3000 pixels.

Because the game controller only had 8 buttons, I decided to only involve the numbers 1-8. This may have been a silly thing to do, but it's done so no going back hehe. The 2 remaining # keys close FL Studio (#0) and toggle between FL Studio and DJ Mixxx (#9) like <ALT> <TAB> does, except just between those 2. You could change the AutoHotKey script to anything though.