From: Brent B. <br...@ke...> - 2018-07-04 19:56:55
|
bjj_Rosemount--- via basilisk-devel <bas...@li...> writes: > Sounds like a cool project. > > I have a vague memory that the BII serial code gets a value from the > guest saying which mode it would like to use when opening the port, > and that one of the possibilities is MIDI. So maybe you could modify > the serial code to use the host's MIDI infrastructure (ALSA, > PulseAudio, SDL, etc. -- probably whatever BII is using for audio) in > that case. I doubt you'd have to deal with the low level details of > Mac serial port clocking. BII doesn't really emulate hardware, it > intercepts driver calls in software. Well, Linux has two different low-level ways of providing MIDI (actually three, but the third one's not pertinent here). The native way, ALSA, needs library calls and specific support in the application, so you have to specially code for it, and I don't want to go through all that just to pass bytes that are already being made available to me on the Mac serial port which are literally the bytes you'd send to the physical studio equipment over cable, if you could find a way to get them there. Also, ALSA is Linux specific, so if you supported it that way, it won't help any other host platform but Linux. The other way of providing MIDI, OSS, is available on most UNIX flavors, even fairly old ones that no one particularly thinks of as multimedia OS's you'd want to do MIDI work on. ALSA provides a kernel module to emulate OSS on Linux for backward compatibility. UNIX flavors that use OSS normally provide character device nodes under /dev that you just send bytes in and out of, like a serial FIFO. All that's needed is for the Linux machine to load the snd-seq-oss kernel module (most distros do it by default), and it will create the emulated OSS device nodes under /dev, which can be used alongside with and interchangeably with the native ALSA library calls on the same machine. So you can run apps that do things the ALSA way with library calls (which is Linux-specific), and on the same machine at the same time you can also run apps doing MIDI the OSS way through nodes in /dev (the older UNIX way). For our purposes, using the OSS compatible character FIFO's is way less work (since old Macs want to do MIDI through serial i/o, the same as OSS expects already), and also is compatible with more UNIX platforms than just Linux. DOSEMU is providing the kind of MIDI support I'm wanting for DOS apps by doing it this way: It doesn't do direct calls to ALSA, it just sends bytes that were meant to go to your DOS MIDI port to /dev nodes of your choice on the host, and likewise for listening to MIDI input coming back the other way, and it works. That's all I'm wanting here, more of less just a character FIFO to/from a /dev node on the host. Basilisk seems to already be doing that for its emulated Mac serial ports...almost. It's just not letting the data flow if it's MIDI for some reason, but allows it if it's a telecomm program like ZTerm. If I make some progress with this, I will provide patches. > Disclaimer: I haven't looked at the code, or used Basilisk, in 15 > years or so... I'm amazed I'm still on this mailing list. :) So I may > be way off base. No, that sounds exactly right from what I see in the Basilisk code. There's a long switch/case block "int16 XSERDPort::control" starting at line 312 of serial_unix.cpp, at least in my git checkout from May 1st (don't know how often you commit). If nothing in the switch/case block matches, it ends up defaulting to 'printf("WARNING: SerialControl(): unimplemented control code %d\n", code);', and that's exactly what I get echoed to stderr in my terminal when an application tries to use MIDI. And nothing ever comes out of the port. Then I go into ZTerm and send Hayes modem commands and it works like a charm. I could call a BBS. :) It would really be nice, as you're suggesting, if I didn't have to actually fake the 1MHz signal coming into the pin on a real Mac that a hardware MIDI interface would produce, though I suppose if I had to, that could be done. Really I'm just trying to let bytes in and out unhindered by code that says, "I don't know what this is, so I'll just throw an exception and skip it," which looks like what that last part of the switch/case block is doing. > Good luck, I'm gonna need it. As the gladiators used to say, we who are about to die salute you. ;-) Addendum: I'm also making an effort to reach the author of Sound Process Visual Editor postally (since his email no longer exists), to see if he's interested in releasing the code. While that wouldn't solve anything for people wanting to run other old Mac MIDI applications, it would be the best answer for this one, so others can take over maintenance rather than letting it die or having to run it in an emulator. We'll see if anything comes of that I guess. A GPL-licensed native Linux version of SVPE would be really nice, or maybe OSX if that would make it easier to port. (Is there software to help with porting Classic MacOS stuff to OSX?) -- - Brent Busby + =============================================== + "The introduction of a new kind of music must -- Studio -- + be shunned as imperiling the whole state, for -- Amadeus/ -- + styles of music are never disturbed without -- Keycorner -- + without affecting the most important political -- Recording -- + institutions." --Plato, "Republic" ----------------+ =============================================== |