Re: [B2-devel] Midi support in Basilisk (by hook or by crook)

[Brent B. <br...@ke...>]

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"
----------------+ ===============================================