alright so after getting MIDI converter and getting the wrong one do to a mix up in shipping, I got the right one, but it was broken out of the box. So now I am going back to the flashing of firmware. Could you give me a simple code that I can use? Something that has a few buttons. Just something that I can see how it works so then I can add to it. 

So the example sketch on the blog was not enough to get you going? What else do you need?

The playground is a great place to find info like this. Try http://arduino.cc/playground/Main/InterfacingWithHardware#USB for examples of running your UNO or Atmega2560 as a keyboard HID device.

The Wifly shield certainly is an option, but at $90 vs $55 I like the Asynclabs price better.  Anyone know of any other WiFi shields available?

Your search on sparkfun seems to have missed a few options. Here is the $35 WiFly RN-XV. Use it with an XBee shield like one of these compatible shields.

That's not a WiFi device, it claims to be Bluetooth. You won't be able to connect to a WiFi network with it.

That will be fine if you use UDP packets. If you want to use TCP then it's not so good because the WiFly can only have one TCP connection active at once. You'd have to round-robin them or use some other scheme to keep the connections short-lived.

after installing dfu programmer and patching
I get this:

cortex:~ nicosteckhan$ sudo dfu-programmer atmega16u2 erase
dfu-programmer 0.5.4
Usage: dfu-programmer target command [command-options] [global-options] [file|data]
targets:
        <snip>
        atmega32u6
        atmega32u4
        atmega32u2
        atmega16u4
        atmega8u2
        <snip>
any ideas ?

You should see this in the list of options:

        atmega32u6
        atmega32u4
        atmega32u2
        atmega16u4
        atmega8u2
        atmega16u2  <----- the new target added by the patch

So you're running un-patched dfu-progammer. Either the patch wasn't applied, dfu-programmer didn't build, it's installed in a different location to the existing dfu-programmer executable, or the new dfu-programmer has not been installed. 

Try running it directly from your build directory: dfu-programmer-0.5.4/src/dfu-programmer.

Also you shouldn't need to use sudo to run it.

I have a question - do you have plans to support flow control? I'm losing bytes while ftp-ing large amounts of data at high speed from Arduino.

Do you have a suggestion for how to implement hardware flow control on an atmega328p?

You may have a poorly matched baud rate selected based on the crystal speed on your arduino. Here's a nice break-down of the rate errors for different crystal speeds: http://www.wormfood.net/avrbaudcalc.php. You might get better results if you switch to a 14.7456 Mhz crystal.

The WiFly datasheet claims that you can use rates above 115200 if your packes are uniform and you ensure the last packet has been sent before sending the next. So you may have some options there.

Another problem may be that the RX serial buffer is overflowing before yor sketch empties it. Optimizing the sketch and/or increasing the size of the serial buffer may help.

If you have an R3 UNO with the atmega16u2 providing the USB interface then you should be able to use the LUFA library to implement a USB mass storage driver, turning your UNO into a USB storage device.

I've noticed that when sending large amounts of data it takes twice as long as you might expect.  You have to send a buffer serially to the module, then wait for it to send it to the remote host on the internet.  You cannot do both at once, so it takes more than twice as long.  At 460k baud you might only get 5-10K bytes / sec.  It doesn't seem to matter what is the data rate of Wifi.  It seems like it needs a reply from the FTP host before you can send the next buffer via Serial.  Do your results match mine when testing?

I haven't finished the FTP feature, but I'll do some performance measurements when I do. Most likely this weekend.

im really glad someone took the time to write a library for this. i live in the netherlands, and i just wanted to be sure that
this module combined with this breakout works in combination with the Wifly HQ library. can anyone confirm? I want to use Arduino as a websocketserver using this!

Those links are a bit broken. But the two items look ok ( sorry I don't understand the language). I think with that XBee shield you will need to modify it if you want software serial support ( e.g to make debugging easier), by cutting off pins 0 an 1 and soldering jumper wires in their places so you can connect the WiFly's serial port to some other digital pins.

I added a WeSockets client example sketch to the WiFlyHQ library here: https://github.com/harlequin-tech/WiFlyHQ/blob/master/examples/WebSocketClient/WebSocketClient.ino. It should be just as easy to create a WebSocketServer. A bit more effort is needed to add key support.

No, I'm not discouraging people.
It's just that that video most definitely does NOT demonstrate an Arduino Minecraft server.

Seems to be serving a small static minecraft world. Maybe Soranne can fill us in on what it's doing and post a bit of code.

But thanks for lampooning my mild lament on some of the negativity on the forums. It's still friendlier to beginners here than other forums.

I find it a bit sad when posters here discourage people from exploring their ideas,

That's amazing!
A Minecraft server in only 270 lines of Arduino sketch!

(dammit, where are the [sarcasm][/sarcasm] tags?)

Can you clarify your snark a bit, I don't quite get it. Are you saying people should be discouraged from exploring crazy sounding ideas?

The official arduino wireless proto shield with sd slot has a switch so you can talk directly to the RN-XV via usb...  Might be a good idea to include it.

http://arduino.cc/en/Main/ArduinoWirelessShield

Thanks I've added it to the wiki. I assume you have one and its working with your WiFly?

I've posted some shield options on the wiki here https://github.com/harlequin-tech/WiFlyHQ/wiki.

For any XBee shield you are considering, check the schematic for the shield and make sure it has decent level shifting on the DIN pin to the module. Other nice-to-have features are the ability to connect the USB port directly to the module and the ability to switch the serial interface between hardware serial and two other digital pins for SoftwareSerial use.

Nice!  Thanks!  I'm writing some brief code to execute commands and retrieve/parse their results.  I've noticed it works at 460k baud using hardware UART, but only 38,400 reliably using SofwareSerial.  For debugging I use SoftwareSerial to Wifly, pins 0,1 for debug messages, but when the code is reliable you can easily switch 2 wires and 1 define to make it faster with hardware UART.  Do you see the same results?

I can only use 19200 baud reliably with SoftwareSerial, but yeah the hardware UART supports much faster speeds.  I think I'll start using software serial for debugging via the serial monitor (with an FTDI USB cable) and the hardware UART for the WiFly module.