I am working on a C++-based MIDI sending app and it's the first time I'm working with MIDI.
I chose the RtMidi library because it seems to be the most complete library around, but I'm open to suggestions.
The OS that I'm working on is Windows 7 and I have an USB-MID interface installed and it's working with other programs (i.e. Roland UM-One).
Now I may be way off-track, but I'd expect that when you do a search for ports, it should show this device.
When compiling the example code for RtMidi i get no ports; in or out.
What am I missing?
Do i need to open a virtual port?
This is also for others experiencing a similar issue as well:-
When I first started using RtMIDI, if you don't specify (on OSX at least) a macro define for the target system, the example code by default uses a dummy MIDI device, and this will have no MIDI ports.
Once I had specified MAC_OSX_CORE, then RtMIDI used the correct architecture and returned the MIDI devices on my system as expected. Perhaps you have to do something similar for your system - check the docs under "Compiling":
http://www.music.mcgill.ca/~gary/rtmidi/index.html#compiling
I've worked briefly with RtMidi and it is, as you stated, a rather complete library. However, when working with MIDI devices, you have to take the specific issues of this type of devices into account.
Another thing is that cheap USB-MIDI adapters often simply refuse to work with some applications "just because". They are very simple inside, yet apparently chinese manufacturers are still able to make malfunctioning devices.
If you're using unmodified, example code, and it's not showing your device, I'll first ensure all other apps that might be using it are closed, then try again. Creating a virtual interface is also a nice idea; I personally use freeware LoopBe1 for it. If it will show the virtual, but not the real interface, then the problem is with device itself. In that case you might want to experiment with different drivers or simply plugging it into a different port.
If it doesn't show any device, neither real nor virtual, then I strongly suspect there's something wrong in the way you build/run the application.
Related
I feel like this should be rather easy, but it continues to vex me, so here it is. I've been trying to find a simple solution to iterate through the available UART serial ports on linux (I'm running the most recent version of Manjaro Linux) and then printing these to the console. Yet, all of the solutions I've found thus far have been incredibly convoluted or they end up throwing a bunch of errors that I can'at figure out when I test them.
So, I've resorted to coming back here to see if anybody else has any ideas. On Windows, there is a GetPortNames() of Windows' System::IO::Ports, maybe a similar API call would be the most ideal.
Update:
So after receiving an answer and using that information to learn a bit more about interacting with serial ports on linux, I eventually ran across a good way to accomplish this effect of iterating through the available ports. It's not quite as simple as a one-line command, but it works so it's fine with me. I found this method of iteration/sorting through the /sys/class/tty directory as an answer to another question (the author of the code that I used is named Søren Holm), and you can look at that here.
Two simple possibilities:
Serial ports on linux are character device files, you can see them on /dev/ttyS*. Serial ports created by an usb device are in /dev/ttyUSB*. This reduces your problem to a dirent iteration.
There is also a thing named sysfs, it is essentially a runtime, non-persistant, kernel-internal registry which is exported to the user space via a virtual filesystem. Normally it is mounted below /sys. Below /sys/bus/serio/devices you can find the devices.
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!
I'm not actually well versed in C++ or SDL_Mixer, but I'm asking this question anyway on behalf on the Doom community. Put simply, nobody writing Doom source ports can seem to figure out how to control normal sound volume and MIDI sound volume independently using SDL_Mixer on Windows Vista or 7. I'll let James Haley, author of Eternity Engine, put it in his own words:
Seems the concept of independent volume for native MIDI doesn't exist under Windows Vista or 7, as using MIDI volume sliders in any application that has them (including most games that use SDL_mixer) also affects the volume of digital sound output. This makes attempting to adjust the relative volume of music for comfort impossible.
Has anybody found any workarounds for this? I'm guessing it's unlikely given how Microsoft seems to have skimped throughout the OS on any way to control the volume of individual sound devices separately.
I've heard of various workarounds all involving a Timidity driver, but this requires the user go above and beyond simply installing the game on his system. The only port that I know of that definitively fixes this issue is ZDoom, but it uses the GPL-incompatible FModEx and is thus not a suitable solution.
If you want some code to look at, Chocolate Doom is perhaps the easiest Doom source port to grok and you can grab its source here.
Any suggestions on other open-source sound and music libraries would be welcome as well.
A solution would be to ship with a FluidSynth-enabled SDL_mixer. You would also need to ship a SoundFont2 file to go with it. Fortunately, there are free SF2's out there, and some are even optimized for Doom's MIDI files. Licenses shouldn't be a problem, since SoundFonts are assets, not code.
You then load the SF2 using Mix_SetSoundFonts().
You may want to look at different MIDI libraries outside of SDL.
http://wildmidi.sourceforge.net/
http://sourceforge.net/apps/trac/fluidsynth/
http://timidity.sourceforge.net
I am maintaining a similar game port (Descent 2), and I have come across the same problem. Afaik there is no solution for it when using SDL_mixer. A cure to avoid sound being muted when turning off midi music I have found is to retrieve a handle to a temporary midi device, set the midi volume to max and then close the temporary device again.
For the longest time, the only solution we found was to use something like PortMIDI. However, Quasar of Eternity Engine fame has come across a neat solution:
http://www.doomworld.com/vb/showthread.php?s=&postid=1124981#post1124981
He essentially puts SDL_Mixer into its own process and controls it with RPC. Very clever.
So one problem with the previous answer I gave was that sometimes the MIDI subprocess did not behave itself, and would break or stop working in strange ways. Eternity's specific implementation used IDL, and I personally re-implemented it using pipes, but the subprocess itself was a bug magnet.
Thankfully, another answer was figured out rather recently. You can simply bypass SDL_Mixer entirely and deal with Windows' native MIDI support directly, which turns out to not require a ton of code once you know what you're doing.
https://github.com/chocolate-doom/chocolate-doom/blob/master/src/i_winmusic.c
You can also implement this sort of idea with PortMIDI and get the benefit of being able to communicate with external MIDI devices as well.
https://github.com/odamex/odamex/blob/stable/client/sdl/i_musicsystem_portmidi.cpp
My main goal is to create an advanced program for manipulating the packets that route within my network via the router. Let my program have total control over the router. Set the download/upload speeds to my inputs, apply the effect to certain devices within in my network. Block upload or download traffic. Set second delay for either the upload or download speed. Specify % of loss packets, and the list goes on.
The problem is that I don't know where to start. I know most languages at the very most basic level. I'd like to create this program in either C, C++ or C# but I don't know yet. What else do I need to know before creating this program? Winsock or something? Winpcap APIs?
This goal is my motivation to learn programming to the extreme, and I'm really looking forward to it.
Thanks in advance!
Hmmm I guess you would want to look at pcap(?):
pcap
Check out:
http://beej.us/guide/bgnet/html/multi/index.html
'Beej's Guide to Network Programming
Using Internet Sockets'
All you could possibly need to know about programming sockets for capture and manipulation.
If I were you I'd write it in C, I'm writing a similar project at the moment in C++ and it's hell but too late to stop and start again.
Hope that helps.
Bear in mind that you either need a router that you can re-program or you need to use your PC as a router to do this.
Either way you want to look into how IPTABLES are implemented.
I've never seen Desktop Windows used as a router only Windows Server, though it may still be possible. libpcap is for packet capture, but not interception as I understand it. Programs like Wireshark use it to monitor copies of packets, but not to modify them. If you want to attempt this, my impression has been that there is a lot more documentation and tools for doing something like this with NetFilter/IPTables on Linux. You can even install something like OpenWRT on a compatible router and get a small, cheap Linux router, though having Desktop Linux will probably help for development. The NetFilter QUEUE library can be used with some IPTables firewall rules to redirects specific (or all) packets to a regular user program. That program can then read the packet and modify it or even request it to be dropped.
http://www.netfilter.org/projects/libnetfilter_queue/
If you want to manipulate network traffic on a Windows machine (as you mentioned), you will need some extra software. This operating system wont give you the full control over itself, which is fine for some reasons.
I think what you want to do, should be done with either winpcap or win10pcap if you are using Win10. These packages contains a windows driver and the libpcap user space library.