The "instruments" that are used with Guitar Hero and Rock Band have USB connections. Is there any documentation or reverse-engineering info out there about how to read the messages they generate?
This message may be too old to be useful.
I was hacking around with an old Nyko 3rd party Guitar Hero / Rock Band PS3 controller on a laptop running Ubuntu 10.04 (2.6.32-25) and I discovered that the hardware was not recognized immediately by the USB HID module. It reports an error of: "can't set config #1, error -32".
I began writing a small test application with libusb-1.0 and was able to apply a configuration directly. Upon doing so, I unintentionally triggered the USB HID module taking over the device and making it available as an input device through a /dev/input/js* interface.
Check out Wiiuse - it suppors the Guitar Hero 3 controller, as well as Wiimotes :)
From my Google searches, the Guitar Hero and Rock Band controllers are USB HID devices. This means they should plug and play on most any machine that supports HID (most do). See USB Revealed by Jan Axelseon for more information.
You could check Frets on Fire project. It's opensource GH-like game, and as far as I remember documentation said you could use Guitar Hero controller instead of the keyboard.
Here's some additional semi-info: Frets on Fire and the 360 Guitar.
I tried the GH3 controller on my WinXP machine and it appeared as an HID device - and appears as a game controller - so I suspect most of the work is already done for you.
Try it and see...
Maybe you can ping these guys for info?
http://www.dxprog.com/entry/rock-band-drums-on-windows/
http://andrewrudson.com/drummachine/main.php
Related
I am working on a non-audio app for iOS and iPadOS and macOS. This question is specifically about iPadOS for now.
I purchased a generic "USB Volume Control" knob device. I am able to plug it into my (non M1) iPad Pro 12.9 and it does indeed control system volume (rotate), as well as things like rotate through tracks in the Music app (push and rotate), mute (push), etc. I have a second such device from another manufacturer on the way to test with as well.
What I'd really like to do is use it in a non-music context. To be able to capture the raw actions and interpret them in my app's subject domain (DCC model train control).
I have been able, on iPadOS but not iOS [as it doesn't have generic USB support as I understand it] to capture the volume changes by using AVAudioSession and KVO tracking the outputVolume property. I haven't yet figured out how to get the push and push-rotate yet but assume I just need to find the analogue functions in AVAudioSession or some other Apple class.
But I would rather not dink around with the Audio/Music classes and have to "re-purpose" them into my own control needs and was wondering if anyone knew of a way to be able to find and connect to the device and get the values directly.
As iPadOS now has pretty good generic USB support for all sorts of devices, I am hoping there is a way for me to provide service to/with/from those devices but I can't find information through normal internet searches. Poor Google-fu.
I looked at the External Accessory framework but my understanding is that only for MFi certified devices and my attempts to detect the devices have not worked as these are generic USB devices. (Unless there are generic protocols one can register for and make this work).
Thanks for any hints, pointers, admonishments, etc. RTFM is welcome if you tell me the M.
I apologize for the weird title but it is the best that I can come up with right now. So I have a project where I am building a HID device that will act as a game controller. I am thinking to emulate the controller so that it appears as an Xbox 360 controller to a Windows PC. There is a decent API called the XInput API for games so that they can utilize the 360 controller. I would like to take advantage of that.
I am currently looking into what it will take to code a microcontroller to appear as a 360 controller to the PC. I do have some questions which I am hoping someone with more expertise in the field can help me on.
1) I am looking into the HID standard. I was wondering, is there a separate subclass of the HID standard designated for game controllers that I can use that is compatible with the XInput API? Or at the very least, is there a provision for a game controller in the HID standard?
2) I found documentation on how to use the XInput API here: https://learn.microsoft.com/en-us/windows/desktop/xinput/getting-started-with-xinput
Now, I am wondering, is there any documentation out there that specifies how to make a HID device compliant to the XInput API or will I be doing some reverse engineering where I use the API to guide how I code the microcontroller?
3) Lastly, is there any documentation on the API that the PC uses to communicate with an Xbox One controller? Or is it still the XInput API? Or is it the Gamepad class (https://learn.microsoft.com/en-us/uwp/api/windows.gaming.input.gamepad)
Thank you for taking your time to read this and I look forward to your response!
Some info that I have on this:
Xbox 360 Controllers are using proprietary protocol to communicate with PC\console via USB and Wireless.
Driver for it is implemented in XUSB22.sys that comes with Windows (was separate driver package earlier).
Under the hood there are so called Krypton Packets (codename of wired controller) on USB bus and Argon Packets (wireless controller RF codename) for wireless controllers. Driver produces XInput interface and HID interface (consumed by legacy DirectInput). Under HID it lacking vibration support and LT/RT only under one axis.
Xbox One controllers are using proprietary protocol called GIP (Gaming Input Protocol) for USB and Wireless, also HID for Bluetooth (on newer controllers). Driver implementation lying in xboxgip.sys. It provides XInput interface and USB HID interface. Under HID it lacking vibration, LT/RT under one axis, LT/RT motors (so called impluse triggers) are not working.
Wireless controllers are using Wifi packets on physical level with incapsulated GIP in them.
Windows.Gaming.Input - is new WinRT/UWP API that comes in addition to XInput, HID and legacy DirectInput APIs. It consumes XUSB/GIP/HID internally (via XusbGameControllerProvider, GipGameControllerProvider, HidGameControllerProvider). Its a native interface for usage of Xbox One controllers on PC since you can use impluse triggers only via this API.
You can try to reverse engineer those protocols/drivers via IDA PRO debugger, USB sniffing etc. PDB symbols are available from Microsoft Public PDB service (IDA will download them automatically):
xusb.sys
xboxgip.sys
Check this Linux Xbox Gamepad driver
I have a single button USB controller, but it did not come with any drivers (simply a Windows program that communicates with it directly for its intended purpose).
USB Fidget
Vendor ID: 0x1d34
Product ID: 0x0001
Product name: DL100A Dream Cheeky Generic Controller
So, I would like to be able to read whether or not the button is being pressed. My main development environment is Mac, but I'd like the solution to run on Windows too. So ideally a cross platform solution would be best.
I can find pieces of code for other devices by the same manufacturer but there are differences in Product ID so the code does not work and I lack understanding to change anything other than the vendor/product.
As far as I understand it I need to poll the USB device with a feature request packet?
Is there some software I can use to "watch" the USB device so I can see what is actually happening when I press the button? If not, how would I go about writing some myself?
basically on MacOs very huge amount of usb devices work through IOUserClient. This standart class provide to user mode programs ability to control device without kernel mode driver (by using usermode part of IOKit framework). To sniff for usb packets you can use USB Prober, start from this article http://developer.apple.com/library/mac/#qa/qa1370/_index.html
On windows standart way - standart USB driver + standart HID driver, no need in specific vendor driver if they not develop some additional functionality over standart. You can use any of commercial or freeware tools to sniff usb packets - like this one http://www.hhdsoftware.com/usb-monitor
I don't know of any cross platform way to handle it. This is the presentation I point people to for how to create a driver app for a random piece of HID hardware:
https://developer.apple.com/videos/wwdc/2011/?id=207
For testing / accessing HID devices, i.e.
Get Feature Report (matt's original question)
Sending Feature Reports
Sending Output Reports
Receiving Input reports
I'd suggest the "HIDAPI Test Tool" / "testgui" included in the great cross-platform HID library from signal11/hidapi.
On Windows you require an additional 3rd party package to compile the testgui application, but it was pretty easy and the GUI tool was more straightforward that other code examples and tools I saw. (I could cross-check if I am maybe allowed to publish a VS2008 compiled version of this.)
Another free option for sending output reports and receiving input reports, is our own "Docklight" tool (in evaluation mode, unlimited time, just no storing), see Docklight Scripting HID USB.
I'm trying to write something that will allow a user to use a keyboard/mouse combination on a games console. The approach I've thought of is to do the following:
Figure out how input maps to output in the console's controller. This is good old trial and error, basically connecting the controller via USB to a computer and figuring out how the controller responds to input using detailed USB logging.
Then, write a userland program that takes keyboard/mouse input and converts it to the controller's output.
So far so good. Now comes the complicated bit. I need to figure out a way to connect my computer to the console, while making the console think that what is actually being connected is a standard controller. For this, I will need a way to create a fake USB device, which communicates over a USB port to the console. This is the part that I have no idea whatsoever how to do.
I guess I'm looking for a USB spoofing library of some sort, but I'm not sure where to start looking for something like this. Python bindings for the library would be great, but I'm not fussy. Similarly, something that works on Mac or Linux would be perfect, but I could live with a Windows-only library in a pinch.
USB doesn't work this way. USB involves a directed hierarchy of devices, and trying to connect two host devices (your computer and a console) will only result in bad things happen (like destroying the USB controllers in both devices).
Probably the best thing to do would be to use some sort of embedded processor like an Arduino to sit between your keyboard/mouse and the console to do the conversion.
is there a way (hardware/software-combination) that I can use to control one or more "Philips Living Colors" lamps using a PC - e.g. a USB-stick that acts as the "remote". This way i could control the lamp through software (e.g. a web-app - over iPhone / remotely) or even create what Philips builds into some of their TVs and calls "ambilight" (graphics driver detecting the main color to control the lamp).
I guess this is more like a hardware than a software question - but I couldn't find anything about this online and I'm sure not to be the first to have come up with this idea right when I unpacked my LivingColors lamp yesterday ;)
There are two version of the LivingColors lamp, the Gen1 lamp can be controlled with a small kit, as far as i know the Gen2 can not be controlled with 3rd party products.
There is an Arduino shield that can control the Gen1 lamps, the article describing this is in Dutch. In short : the shield, and by extension the lamp, can be controlled by serial-over-USB. Google translate may help :
The hardware : http://www.knutsel.org/2010/04/11/assembling-the-cc2500-arduino-shield/
The link to the software is at the end of the post. (I can only post one link.)
There is a schema and software, enough information to build your own controller for Gen1 lamps.
Some remarks:
I am the a author of these posts.
The shields are sold as a kit in the Netherlands and Belgium (hence the dutch blog post).
The Gen2 uses IEEE802.15.4 (it says so in the manual) and is said to use encrypted Zigbee. Zigbee and encrypted Zigbee use IEEE802.15.4.
I should probably make a better translation of the posts.
[ 11 April 2010 edit : made translations of the blogposts in English and changed the links here ]
LivingColors uses an implementation of 802.15.4, the ‘ZigBee’ mesh-network wireless protocol designed for consumer appliances.
The second-gen LivingColors lamps can be persuaded to talk to the Philips Hue wireless bridge and integrate with a Hue setup. Much anecdotal information about how this is done can be had here:
http://www.everyhue.com/?page_id=38#/discussion/7/hue-and-living-colors
... for your purposes, integrating with Hue is your best bet, as the bridge exposes (as of yet, unofficially) a comprehensive RESTful JSON API, which is easily scripted — one of the better resources on using this API can be found here:
http://rsmck.co.uk/hue
I personally have had a good deal of fun doing what you are trying to do, with the Hue bridge and LivingColors lamps. Good luck!
I would too be interested by controlling my Living Colors from a computer, through a 2.4Ghz USB transmitter (mainly just for fun ;)
I have two Living Colors, a "Generation 1" and a "Generation 2", and the bad news is that the remote hardware and (maybe) the protocol have been totally modified by Philips in the process (probably to add the "fading effects" of the second generation). So it's even more complicated now, such a transmitter would have to deal with the 2 protocols.
Another link about what's inside the official controller
(in addition to the Elektor article given above) :
Gen 1 : http://www.knutsel.org/2009/01/01/livingcolors-1st-generation/
Gen 2 : http://www.knutsel.org/2009/12/01/philips-redesigns-livingcolors-breaks-compatibility/
Elektor (reverse engeneering of the procotol : http://www.ideetron.nl/Livcol/UK2008110661.pdf
I checked the Philips website where you can download the user documentation. The following trouble-shooting tip provides a clue:
LivingColors doesn’t respond quickly to the remote control.
- The communication between the remote control and the
LivingColors can be affected by heavy traffic on a wireless data
network, for example a wireless router.You should move Living-
Colors away from the wireless access point and switch your
wireless router to channels 8-11 for minimum interference.
So the controller uses wireless communication. It is clearly quite a sophisticated communication link, one controller can control up to 6 lights.
Unless it is a full WiFi link getting a computer to control the light would necessitate some heavy hardware hacking. Should it be a WiFi link it would be possible to write a driver.
If anyone has one these could they do a WiFi scan to see if the light and controller show up?