I've built a software. I want to control it via a MIDI controller (e.g. keyboard). How do I get the MIDI data from the MIDI port to my software using e.g. ALSA? I'm using Linux.
ttymidi will act as an ALSA device and print output or read input from a file. The intended use is that this file is a serial device, but /dev/stdout also works -- this can then be piped to the program. If you want to code the device yourself, the ttymidi code is probably simpler than say timidity, so you can use that as an example.
Use asoundlib. This gives you MIDI events as structured objects rather than binary data.
Related
For a project I'm thinking of using this relatively new IC from TI - the ADS7138. The issue (I believe, though I may be wrong) is that there is no driver for this chip in the kernel. Does anyone have any suggestions for a work around to talking to this driver? Is there another driver I could use or am I stuck writing a custom driver specific for this IC?
I've worked on a board bring-up project with the same IC. I couldn't find a driver for it so I wrote one myself. I hope it works for you as well:
ADS7138 Driver
Till you find a compatible kernel driver or develop one yourself, you can quickly experiment with the ADC from user space using the i2c-tools. You can use either the command line tools or use the API to write your own app, but be cautious if you use the command line tools like i2cget(8), first read the man pages and pay attention to the warning section.
To use the API, open(2) the i2c device, set the slave address with ioctl(2), then use smbus APIs like i2c_smbus_write_word_data(), i2c_smbus_read_word_data() etc. You may take a look at the tools code like i2cget.c itself to see how the API is used. Following is a simple code to read a register from an I²C chip connected to /dev/i2c-0.
int fd = open("/dev/i2c-0", O_RDWR);
ioctl(fd, I2C_SLAVE, slave_address);
__s32 res = i2c_smbus_read_word_data(fd, register_address);
close(fd);
See kernel documentation or the web about i2c/smbus and instantiating i2c devices for more details.
I'm working on a project that is using a Raspberry Pi with Raspbian and an SGTL5000 based sound card (FePi.) I have no problem selecting the card and getting samples in both directions - once I have configured the multiplexer to properly select line In/Out. I did this with Alsamixer. I want to automate the process so that the only step required is to run the application.
I don't see a way to do this using PyAudio/PortAudio. Is my only option the ALSA API or is there a way to do this with PyAudio (or PortAudio) that I'm not spotting?
Thanks in advance for any insight you can provide.
Oz (in DFW)
I ran into a similar problem, I wanted to automate changing mux settings but I wanted to adjust inputs not exposed by alsamixer too.
To deal with the limitations of the driver I ended up porting over the Teensy 3.x sgtl5000 control software to the pi yesterday
https://github.com/Swap-File/pi-sgtl5000
You could force feed the same commands via i2c via python.
The only downside is, once you start force feeding the sound card i2c commands, you break alsamixer (and anything else that might try to adjust it's own volume settings).
While using tshark, I want to capture a packet that contains a specific string.
After executing tshark, I want it to stop receiving packets immediately when it receives a packet that contains the specific string and return it.
What parameters should I use to do this operation?
I think you're looking for something like trigcap, which is part of the Wireshark project, but not currently being shipped to my knowledge because it apparently doesn't work on Windows and may have problems on other platforms now too since it hasn't seen any active development in quite a long time AFAIK.
You can try to compile it yourself to see if it meets your needs. Read more about it at:
Bug 2039 - Triggered Capture
what is the work of trigcap?
If you're on Windows, you might want to take a look at the dumpcap.bat file posted on the Wireshark wiki Tools page.
All of these solutions rely on BPF (pcap-filters), so whatever string you're looking for as your stop condition needs to somehow be manipulated into that format, which may not be easy to do.
Normally in Linux PCI drivers may expose a control interface to user-land
via a character device, e.g. /dev/drv_ctl, and a user application can
read/write I/O control commands with ioctl() on the open file descriptor.
In Linux we create this with register_chrdev() kernel API.
I would like to have the same or similar mechanism and behaviour on Solaris, but seems that on Solaris it works slightly different; DDI routine ddi_create_minor_node() requires a node type indicating audio, block, net etc. device, this looks quite vague to me, for example what type a crypto PCI device belongs to?
Also, it seems that ddi_create_minor_node() creates a node under /devices/* and not under /dev/*
I would appreciate if someone could clarify my doubts and point out at the right directions.
Thanks.
Typically you create a symlink under /dev yourself, using a name which is useful to you. That would point to your actual /devices path which was created by calling ddi_create_minor_node(). You'll find the list of ddi node types in <sys/sunddi.h>; for a crypto device (what even is that?) you'd probably want DDI_PSEUDO.
I have a Yamaha MIDI guitar, that, when I play a MIDI file encoded using the XG MIDI standard, causes certain lights on the guitar to turn on and off. I am trying to determine the MIDI event that causes this so that I can programmatically send the same event without the use of a MIDI file (the same way I can send a Note On (144) or Note Off (128) command).
However, while I have been able to locate a copy of the MIDI protocol, I have not been able to locate the XG MIDI protocol. Is there a way, beyond trying to send all possible commands to the device until I locate the appropriate command, to determine what the MIDI event is that is causing the lights to change state? Or is there somewhere that I can get a copy of the XG MIDI protocol?
The Yamaha manuals for their products detail the information you are looking for. The XG commands are device specific. Some XG commands give direct access to the device memory and my manual for the MU2000 tone generator warns that "you can damage the unit by sending incorrect data"
Two things:
XG is the semantic extension of MIDI protocol. It doesn't change anything in the structure of the MIDI file. The only thing is, that if you use an XG-compatible instrument to record, say, changes of the resonance of the filter, it will cause the same effect on any other XG instrument. But on the MIDI procotol level, you will still have the CC (Control Change) message #71 (IIRC).
MIDI protocol is very extensible and leaves a lot of space for manufacturers. Not only you can use CC messages, but also Registered Parameter Numbers (RPNs) and NRPNs (Non-Registered ones). On top of it you have System Exclusive (SysEx) messages and I would bet that an appropriately crafted SysEx message could change the lights on the guitar. Try to get so-called "Data List" for your instrument, it should include all the information about the MIDI messages that are being sent/received by your guitar.
Wikipedia: "In 1999, the official GM [General MIDI] standard was updated to include more controllers, patches, RPNs and SysEx messages, in an attempt to reconcile the conflicting and proprietary Roland GS and Yamaha XG additions." This was called General MIDI 2.
I recommend looking into what Java (javax.sound.midi) has to offer (C# seems to be lacking a solid MIDI library). Read up on MetaMessage, ShortMessage, SysexMessage, and Patch. From what I understand, special system messages are sent through SysexMessage (the lighting data might be here).
If you need some sample code look at Java Sound Resources.
Other links I found:
Working with XG SYSEX on the Yamaha QY70
Win32API::MIDI::SysEX::Yamaha
For a managed .NET Midi Library look for the C# Midi Toolkit on codeproject.com.
I'm using the codeproject midi toolkit by Leslie Sanford to communicate with the guitar.
http://www.codeproject.com/KB/audio-video/MIDIToolkit.aspx
Everything you need to know about the guitars communications is in the manual on a single page near the back.
Here is a video of an editor I built - it features full communications with the guitar.
YouTube Video of Guitar Program
Ultimately, you'll need to find that information from the manufacturer. It's likely a sysex message, although it could also be a controller.
Walking through all the controllers is pretty simple in software so you could try that if you wanted. But the chances of stumbling upon the right sysex message by accident or exhaustive search is close to astronomical.
Dig through the back of your manuals. It might be in there. If not, google for the sysex for your device. Otherwise you'll need to ask Yamaha for the info.