Hack the F1

[MoeHawk]

yeah im not very impressed with the feel of the F1 either. quite frankly i hate the buttons. dont care for the clicking to have to press. i was assuming it was gonna be like a maschine. im pickin up a mk2 maschine after holidays anyway, but contemplating selling the F1 as i hardly use it aside from messing with some remix decks.

[Nicky H]

I kinda get where you're coming from, but I didn't expect my F1 to work like Maschine, so I wouldn't expect the opposite either.

[DjLiquitATL]

remix decks are ok, making your own remixes is better...i'd rather have 2 additional decks then remix decks

[tunecrew]

I started to get into the remix decks and found that they're pretty dope, but very limited using just an S4 as everyone knows.

So I've ordered an Arduino Leonardo which should arrive Monday or Tuesday and I'm going to attempt the emulation route with both a Trigger Finger and a Korg microKontrol by routing the MIDI out into the Leonardo, having the Leonardo identify as an F1 and then having an internal routine in the Leonardo that does the MIDI-HID translation.

Once I have this working I'm then going to try USB-USB using a USB host shield, and possibly even an HID-HID translation, so that devices like the APC40 and Launchpad can be mapped.

I'm an EE but my embedded systems stuff is a little rusty so wish me luck!

[tunecrew]

I should add that I looked into doing this strictly in software on OS X, but writing kernel extensions is pretty tricky business and not my area of expertise - but if someone wants to collaborate on this ping me.

[abythell]

I have reprogrammed an Arduino UNO so that it can send and receive USB-HID messages and impersonate a Kontrol F1. Any LUFA-supported device, like a Leonardo or a Teensy or even a Midi-Fighter (pro, classic, or 3D), should be able to do the same. You can find my fork of the hack-the-f1 project at http://github.com/angryelectron/hack-the-f1.

Currently, Windows recognizes the device and installs the drivers for it, and it can send the required 22-byte input reports with simulated button presses, but Traktor is attempting to communicate with it and is failing. This may be because the UNO is not a high-speed USB device, or because there is some sort of handshake that occurs between Traktor and the F1 when it is first detected. I need some help collecting more information before I can proceed with this project.

If you have an F1, Traktor installed on Windows, and access to the USBlyzer software (through whatever means, demo or full), I could really use a capture of what happens when the F1 is plugged in while Traktor is already running. This is quite simple to do by anyone - no advanced technical knowledge required. Let me know if you want a walk-through.

I would also be interested in hearing from anyone who can flash and run my code on a high-speed device, like a Leonardo, to see if it behaves differently. I think all it would take is a modification of the BOARD setting in the LUFA makefile to compile for the new target, although the Other Speed Configuration descriptor might have to be written. Again, let me know if you want more details.

[tunecrew]

I have reprogrammed an Arduino UNO so that it can send and receive USB-HID messages and impersonate a Kontrol F1. Any LUFA-supported device, like a Leonardo or a Teensy or even a Midi-Fighter (pro, classic, or 3D), should be able to do the same. You can find my fork of the hack-the-f1 project at http://github.com/angryelectron/hack-the-f1.

Currently, Windows recognizes the device and installs the drivers for it, and it can send the required 22-byte input reports with simulated button presses, but Traktor is attempting to communicate with it and is failing. This may be because the UNO is not a high-speed USB device, or because there is some sort of handshake that occurs between Traktor and the F1 when it is first detected. I need some help collecting more information before I can proceed with this project.

If you have an F1, Traktor installed on Windows, and access to the USBlyzer software (through whatever means, demo or full), I could really use a capture of what happens when the F1 is plugged in while Traktor is already running. This is quite simple to do by anyone - no advanced technical knowledge required. Let me know if you want a walk-through.

I would also be interested in hearing from anyone who can flash and run my code on a high-speed device, like a Leonardo, to see if it behaves differently. I think all it would take is a modification of the BOARD setting in the LUFA makefile to compile for the new target, although the Other Speed Configuration descriptor might have to be written. Again, let me know if you want more details.

Are you reflashing the USB chip on the UNO to accomplish this?

On the Leonardo (with no separate USB-serial chip) I am attempting to do this starting with editing the PID and VID and other USB descriptor info in the bootloader and then reflashing the bootloader (this is to spoof an F1, then I'll get to the HID stack, which you can load at runtime).

Right now I've made the necessary changes, but am still working on getting the updated bootloader built correctly (it builds, but the resulting hex file is very small and doesn't work when flashed)

[tunecrew]

Are you reflashing the USB chip on the UNO to accomplish this?

On the Leonardo (with no separate USB-serial chip) I am attempting to do this starting with editing the PID and VID and other USB descriptor info in the bootloader and then reflashing the bootloader (this is to spoof an F1, then I'll get to the HID stack, which you can load at runtime).

Right now I've made the necessary changes, but am still working on getting the updated bootloader built correctly (it builds, but the resulting hex file is very small and doesn't work when flashed)

actually update - just got the bootloader to build and flash properly - hopefully will have it spoofing F1 at the USB Device Descriptor level by tonight

[abythell]

actually update - just got the bootloader to build and flash properly - hopefully will have it spoofing F1 at the USB Device Descriptor level by tonight

Congrats on your progress! Can I ask why you are modifying the bootloader code? Won't this only make the device appear as the F1 when it is in DFU mode, which is rather like trying to make a Windows application by re-writing the BIOS?

The code in my GitHub repo I think is exactly what you are trying to achieve, and while I developed it on an UNO, it will run on a Leonardo simply by changing two lines in the Makefile (Details here: http://fourwalledcubicle.com/blog/20...uino-leonardo/).

I don't want to fill the forum with technobabble, so get in touch by e-mail (abythell -at- ieee.org) if you want to discuss further. It would be great if we could collaborate on this!

In the mean time, anyone out there with an F1 who can send me a USBlyzer report?

[tunecrew]

Congrats on your progress! Can I ask why you are modifying the bootloader code? Won't this only make the device appear as the F1 when it is in DFU mode, which is rather like trying to make a Windows application by re-writing the BIOS?

The code in my GitHub repo I think is exactly what you are trying to achieve, and while I developed it on an UNO, it will run on a Leonardo simply by changing two lines in the Makefile (Details here: http://fourwalledcubicle.com/blog/20...uino-leonardo/).

I don't want to fill the forum with technobabble, so get in touch by e-mail (abythell -at- ieee.org) if you want to discuss further. It would be great if we could collaborate on this!

In the mean time, anyone out there with an F1 who can send me a USBlyzer report?

funny enough I just realized this - new to the Atmel world - my embedded experience is from a long time ago and on PICs and 68HC11s... I'll email you.