I'm currently specing out projects for my graphics class and I am thinking of writing an application that displays a visualizer for midi data. What I would like to do is sniff midi data as it passes through the system. I do not want to hijack a driver, only watch the data go by (that is, I want the MIDI data to later be accessible by a DAW). I am not familiar with programatically accessing midi in windows. The closest I could find to what I want seems to be midi spy. However I would prefer to write the app in c/c++.
I was looking at MIDI Stream API, but I can't tell if I'll be able to sniff devices that weren't opened by the library. I was also looking at SDL Mixer and QT Midi. I'm just trying to get some personal pros and cons to the options that I've presented or ones that I haven't found.
Unfortunately, there is no way to actually sniff MIDI streams under Windows. All you can do is place your application between the two MIDI devices.
Unless you are putting software between physical in/out ports, you will need to set up a virtual MIDI loopback driver that directs the MIDI stream data from an input to an output. Fortunately, there are a few off-the-shelf solutions already. The easiest method is to require your users to set up a virtual MIDI port and configure it on their own. LoopBe1 and MIDI Yoke are free.
Another method is to use a virtual MIDI driver that goes directly to your application. Tobias Erichsen has created a very easy-to-use driver for this very purpose. I don't believe he has released it yet, but if you shoot him an e-mail, he might get back to you. See this question: DDK "Hello World"
Related
Using PortAudio, how can I access running applications' audio interface so that I can capture the audio they produce in real time? The goal would be then to send this audio as UDP packet to a server.
I've had a look at PortAudio's code samples but can't find anything similar.
Maybe PortAudio is not the right library for me?
I'm working mainly on Mac OS.
Core Audio does not have the sort of functionality you're looking for. Processes are sandboxed/isolated from one another.
You could probably achieve this using library injection, but there are a number of complications. OSX has added System Integrity Protection which disables injections. If you're willing to disable SIP (which is dangerous! Proceed at your own risk!) then you could try something like mach_inject and intercepting the target processes' calls to Core Audio. But you'd never be able to ship something like this, since asking users to disable SIP is not reasonable.
I am looking for a piece of software, or assistance with where to start for coding, that will let you select a USB device and convert its output signals (when buttons are pressed on the device) into keystrokes or configurable macros.
In more detail, I have this remote control (more accurately, a USB handset/phone) that sends USB signals depending on which button is pressed and the software I currently use converts those signals into keystrokes or macros. The software I currently use however is extremely limited, non-configurable and obsolete. The software which I retrieved from the CD that the device came in is simply named 'USBPhone 5 in 1' however there is no mention of this anywhere on the internet.
The device is unfortunately unbranded and also has very little visibility on the internet so I cannot see if there's any updated software or even any way to edit it.
Any help is greatly appreciated!
I think you need to start by getting basic understanding of the USB standard and device classes. Then you need to find out if your device implements a specific device class or some proprietary interfaces. Then you will either need to use a driver for the device class or implement a proprietary driver.
While USB is abbreviation from Universal Serial Bus, it is not transferring some random analogue data but well defined digital packets. The standard defines Audio Class for audio devices, Video class for video devices etc. Most devices implement one or more of those classes. For keyboards and mouse it defines HID class, which is most likely what your device implements. You can find HID device class related specifications here. It is not the most simple one to begin with, but it should work when you just plug the device to your PC and open e.g. notepad and start writing. USB device class codes are listed here.
In order to find out what device class your device implements, you need to read it's descriptors. In Windows one of the easier ways is to use usbview. You can read more about USB decriptors from here.
You do not mention what is your USB host (Windows or Linux PC, Mac or something else), so I am not going to go into actual USB driver implementation, but hopefully I was able to give you some information on what could be needed. In any case, if the device has some proprietary implementation, you will either need to have specification for it, or reverse engineer it by monitoring the USB packets. There are lots of expensive hardware solutions on the market for analyzing the USB traffic, but there are also some free SW solutions that might be good enough for your purpose. Quick Googling brought up this.
You can try joyToKey, this software do exactly what you want but with gamedpad. I don't know if it will work well with your USB controller.
http://joytokey.net/en/
I am developing C++/Qt application which interacts with Tektronix TDS2002 oscilloscope via USB. The oscilloscope appears as "USB Test and Measurement device (IVI)".
Currently I use TekVISA library supplied by the oscilloscope's vendor. It works, but it is huge, old, buggy and poorly maintained. Therefore I would like to bypass the library and interface the device directly.
So far I have found this simple library: https://github.com/xyphro/WinUsbTmc It is exactly what I am looking for, but it uses libusb which requires to install some device filter and in addition it is advised to be more development tool than customer solution. Do you have any experience on this?
What is the easiest way to interact with USB Test and Measurement device in Windows/C++/Qt?
Thank you for your suggestions :)
You need a USB driver. My oscilloscope works with the driver included in this VISA package (the driver can be extracted very easily): http://www.keysight.com/main/software.jspx?cc=CZ&lc=eng&nid=-11143.0.00&id=2504667&pageMode=CV I assume all USB TMC devices can use the same driver, but I have no possibility to check this.
USB driver can be accessed via standard Windows functions. Guys on this forum were really close:
https://forum.tek.com/viewtopic.php?f=568&t=137573 and also this document was very useful: http://www.ivifoundation.org/downloads/Class%20Specifications/Ivi-6%202_USBTMC_2010-03-23.doc
You cannot write commands to OSC directly - data you send and receive have certain header which has to be in the correct format, otherwise the oscilloscope ignores the message. See reading and writting implementation in this simple library: https://github.com/xyphro/WinUsbTmc I didn't use this library because it uses libusb library which uses some kind of device filter and I personally do not like this concept (and in addition I have genuine working driver).
Data you read have also a simple header. To ensure you fit the header structure on input data well, you should first flush the input buffer. Then you issue reading request (using write command - see WinUsbTmc library above) and finally you receive the data and fit the header on its beginning.
I hope this will help to somebody :)
With regards
klasyc
I have a feature request on a project I work on, it is to integrate with a Paylife CC handheld, which has a USB connector to connect with the computer. I have the docs, and am reading up on it.
When I searched on google how to read/write to a usb device on linux, it said, use libusb.
I was wondering, is there another possibility? Can't I just open it like a file and write a stream to it, and read a stream from it?
I don't actually need to do anything fancy. I just need to write a string of control codes to the device, and it would be mildly nice to read back the ACK and Error codes. But since those are already displayed on the device screen, I don't have to do much with it, just deliver the total required for payment.
So my question is, what are my options?
The connected computer is a regular ol ubuntu linux box.
It is definitely possible when the device complies with one of the USB device classes -- drivers for them are universal.
If that's not the case, then you may stick with a manufacturer-provided or a third-party driver, given there is one and you possess enough of it's documentation.
If that's also not the case, libusb-1.0 is your resort, unless you want to write a kernel driver youself :)
I am working with a pressure-sensing mattress having a USB interface. The maker provides USB device drivers for Windows, and an API written in C++ which has functions to request data and set some parameters.
Currently, I cannot use this sensor for testing some Python data-visualization scripts directly, having had to ask my coworkers to write a text-logger for me, and then I read this information offline with Python.
Also, I cannot use Linux at all with the sensor, because there are not drivers for Linux, and I do not know where to start to "hack" the sensor, and that is why I am asking:
"If I were to try to read data from this sensor directly with Python and perhaps in Linux, what should I do first, or read first?"
EDIT: the device has an FTDI driver (FTD2XX.dll) if it helps.
Any help would be very welcome
Odds are fairly good it's a HID device, in which case you can probably start to write a userspace linux driver for it using libhid. First place to start with that would be enumerating the tree that gives you information about its capabilities. (lsusb -vvv or Example)
Failing that you can use libusb on linux (and other platforms too these days) to write a userspace driver still. You'll want to use something like usbsnoop or a real hardware equivalent to see what the official driver does when it's talking to the device and mimic it from there.
From the python side you can probably generate a decent wrapper to the existing C++ API using SWIG for relatively little effort, especially compared to developing an entirely custom driver.
Update:
If it's an FTDI device then it's might be a lot simpler to work with. Depending on what the vendor and product ID are showing it might automatically work with the FTDI driver in Linux, giving you as USB serial port. Failing that there are parameters to the module - vendor and product that I believe you can use to make it claim other devices besides the pid/vid combinations it knows about already. From there you can try opening the serial port device with different settings. With luck it might be sending state info regularly already.
If it's not you want to try and discover what the official software sends to make it start playing. You're back into the realm of sniffing again, but I think there might well be things that do it at the serial layer instead of the USB layer for windows (although I can't name any). You might also learn something by trying to make their library use a software emulated serial port instead of the FTDI device and seeing what it writes.
The FTDI chips have a linux driver. Just go to the FTDI website and download it. The driver creates a virtual serial port. You can use PySerial to interface with it.
Too bad I didn't see the post sooner!