This page is about the midi/sequencer subsystem in ALSA, which is Linux's modern audio system, also available on a few other Unixey OSes. If you don't have Linux, nor one of those other systems with ALSA, then this page will be of little use to you, sorry! :D
In the past year or two though I've been making great progress with getting midi and synthesizer stuff to work on my system, and since finding out more about how the ALSA midi patchbay system works I've been even more interested in the idea of making my own midi client software for all manner of things. This came to a head whilst I was writing this, having collected a bunch of programming info about it, when I said "sod it, I'm gonna see if I can do it after all, just make something to display incoming events". A couple of hours later (mostly due to not knowing my way around the docs in question) I have awatchmidi v.0.01, it's pretty crappy but it does strictly speaking do what it's supposed to.
(Update: I found out since then, that later versions of Alsa than the old one I have installed on this machine, have an "aseqview" utility in the "alsa-utils" package, which AFAICT does basically what my "awatchmidi" does, but decently and cluefully. My old installation didn't have that, although I had other things like "aseqnet" and "aconnect". So there isn't really much use for it except as further quick+dirty example code)
Also it showed me the broad details of it aren't very difficult once you've got your head around details such as the stuff about "subscriptions" (it's fairly confusing the way they talk about it) and a few other things. It may also be of use to someone for example code for writing their own little programs, although they might do better to base them off a later version when I fix the various idiocies in my code.
I've got a bucketfull of other things I'd like to code up. Yet another graphical patchbay app might be nice too, most of the ones out there seem to be for KDE or Gnome or whatever. Plus of course adapting my old softsynth system Patel to work as an ALSA sequencer client. The original version (after which it stalled) had no effective input system, just a horrible cryptic character/line-based input file format that it read from to set up instruments and describe the score, before it wrote its synthesized output to a WAV file. I suspect converting it to use SDL audio output and read from a sequencer port, would be rather straightforward. It could also get instrument configuration via the same sorts of sequencer events that the OPL synth etc get theirs from, presumably. If those are somehow off-limits I could still embed them in some of the user-defined event types, they don't need much data.
(Update: I since found out, in investigating ALSA's Trident 4DWave synth support (or lack of), that the support+API for instrument loading/configuration via the sequencer interface, has been removed in recent versions of ALSA due to disuse, so that rather simplifies the decision...)
Well firstly, /proc/asound/seq/clients (PASC from here on!!!) doesn't just list clients with ports you can connect together ("subscribe to", in the official jargon). It is strictly possible to make a client with no ports (I did it earlier in experimenting with the API), and such a client will not appear in aconnect's listing (because there'd be nothing for aconnect to connect things to, and that's what it's for!), but it will appear in PASC, shown without any ports after it.
Then if you do have a client with ports, but those ports can't be subscribed to (if this is the case it implies that client does the subscribing to other ports itself, whichever direction the actual data is flowing), then again it is of no interest to aconnect(??? is this definitely the case? Maybe there's exceptions, I should check), and so here again it won't show those particular ports.
Then there's the matter of what PASC actually displays for each client and port, that gives a few extra details that aconnect doesn't as well. One thing is the "Input pool" and "Output pool" stuff. AFAICT this is to do with the client's buffers. The input/output buffers are shared between all its input/output ports respectively, which means there is actually a reason to have multiple "client" handles per program, though there isn't usually. I think the main interest of this info is probably working out if the buffers are overfilling, which is a sign that something can't keep up generally (or is hung).
The other interesting thing is after each port on a client, it shows something like (rWeX) or (R-e-) or numerous other variations. It's reasonably clear to those familiar with Linux file attributes that it's a system similar to that, but I couldn't find any info on this, so I did what I usually prefer not to and hunted around in the source code (specifically the kernel file seq_clientmgr.c). The character positions represent READ, WRITE, EXPORT, DUPLEX in that order.
| READ | WRITE | EXPORT | DUPLEX |
| r:can be read from but not subscribed to | w:can be written to but not subscribed to | e:can be "exported"?? | X:allows duplex IO |
| R:Can be subscribed to for reading | W:can be subscribed to for writing | ||
| -:Cannot be read at all | -:Cannot be written to at all | -:May not be "exported" | -:Doesn't support duplex |
I don't well understand "exporting" regarding subscriptions. AFAICT it's to do with whether a separate client (eg aconnect) can subscribe another client to/from it. So a port could support subscription requests from the client that wants to communicate with it, but not allow the subscriptions (connections) to be set up by something else on that client's behalf. Or something like that. It appears to also be relevant to disconnecting subscriptions too.
Aha! Kyaku, my little 2ndary machine that I'm using Seq24 on (because it was the only machine that'd accept my nice little ISA-based SW60XG synth card), has been poked about with a lot and didn't have mouse scrollwheel support configured yet. My main machine doesn't even have a wheelmouse! Now that's been set up properly (needed to hunt about for the info), I find that what the Seq24 folks say about setting parameters via the scrollwheel is somewhat straightforward. But it still sucks if you don't have one, and for some parameters you don't so much want to be dialing in the values like that. And on the Program Change setting, having no patch names on show isn't very user-friendly.
A few years ago I also poked with the "TTRK" sequencer by Billy Biggs. It's a little bit like a module tracker interface, but text-based (runs in a terminal window) and is still for midi. I didn't get very far with that, IIRC it (1) wanted to be run as root or else to have /dev/rtc made otherwise available to your user, (2) was OSS-only, and (3) didn't accept midi device filenames with any upper-case characters. So to make it work with ALSA, IIRC I had to make some sort of symlink to the lower-level raw MIDI file, and/or install the Virtual Rawmidi driver to give access from the OSSish world to the ALSA sequencer world. This did work at least. But at the time I didn't have anything much to sequence to. I may have had trouble with using the FM synth at the time. TTRK is long abandoned, but someone else made a bit of a fork of it with a few releases in recent years. I haven't tried that one.
Obvious issues with TTRK: You can only access one midi port at a time, you have to have access to RTC (as mentioned) and the whole thing's pretty confusing IIRC.
I've also played a little bit with Shaketracker, which is done in a much more traditionally Module-Tracker style, but for Midi. It seems to be abandoned. Has some good features and some lacking features. I like the Patterns And Orders type interface, and that IIRC each track(?) can access a different Alsa midi sequencer port, like in Seq24, which is very handy. It has stuff for sending controller events, and bankswitching. It doesn't IIRC have any facility for sending SysExes, which is a nuisance. OTOH neither does Seq24.
SchismTracker also has some sort of midi sequencing features in it. I don't remember being able to get very far with those. Schism is of course primarily a Module tracker.