Hi, i've implemented a midi bridge for Mini vMac which exposes emulator modem and printer midi ports to the host OS. so far no stuck notes, and sysex seems to work both ways. there's systematic jitter though which needs to be resolved. i can share an experimental OSX build if there's interest ?

here's a screenshot: https://drive.google.com/file/d/17zGJyVF4Az-3sstdZebDKZFHjlKCbWyi

Wow! That's great! I can't guarantee when I'll be able to test it, but I'll definitely fire up DMCS and give it a go. I'll also see if I can patch it through to macOS's Bluetooth MIDI stack and see if it'll cooperate with other MIDI devices

Please do share a link to a build.

Best
Cat_7

I just realized: this solution also means that we have a fully working null modem connection between Mini vMac and the host! That means you can connect the two with a terminal emulator like ZTerm to do file transfers, and even *easily* (since the other LocalTalk bits were already added to Mini vMac years ago) put two or more instances on a LocalTalk network, along with the LocalTalk server one of our forum members created a few years back.

So while the MIDI is a huge boon, the other serial features required to make this work mean that there's more that's functioning properly now too

Let me know when it's stable enough for me to put it through its paces on macOS (I'm currently running Catalina, but I can run it in any Mac OS needed).

I have dreams of running DMCS on the back end, and patching it into Garage Band via the Audio/MIDI setup :D

uploaded a zipped osx build v01 to https://drive.google.com/open?id=1OJ2GE87GE5VPFr8nKZcFwSwJXZDvykxM

any feedback/issues most welcome. would really like to turn it into a usable midi resource, thanks for trying it out!

explored most compilation options and ended up with the flags below: MacII target (because of 68020, please use MacII.ROM instead of vMac.ROM), legacy screen resolution as some early apps did not enjoy 16:10 too much, max emulation accuracy just in case, and background mode active by default. it is an unsigned build. unfortunately i've still been unable to tame the jitter. hope to reach paul c. pratt for more insights on where to look.

@adespoton: that's a great idea, didn't think about other serial port use cases. it would be pretty easy to open a tcp socket at Mini vMac side to expose raw serial port byte streams (ie. modem/printer in and out sans midi packet parsing).

Might be worth posting on Paul's feedback page; I've sent him my debug details that way before, and he's got back to me in reasonably short order Of course, posting on here means he'll look at it eventually... but it could be a month or two.

From https://www.gryphel.com/c/mail/v9.html#m176:

I can think of two reasons for such jitter. First, OS X is not a real time operating system. The operating system will give Mini vMac time to run when it feels like it. To get uninterrupted output for the emulation of built in sound, there is a buffer that the operating system can get samples from, even if Mini vMac doesn’t get time for a while. (This buffering results in lag, which can be a problem such as for games, so Mini vMac dynamically tries to figure out just how much buffering is needed.) But this is probably not the main issue you are seeing.

Second, Mini vMac emulates an entire tick, about a sixtieth of a second (more accurately 60.15), all at once. If the operating system feels like it and runs Mini vMac exactly on schedule, this will run every sixtieth (about 0.0167 seconds). Your emulated Midi clock events are supposed to happen somewhat less frequently. So in most ticks one event is emulated, but occasionally there are no events in a tick. Which is exactly what you are observing.

The only way to avoid this would be to have the operating system run Mini vMac much more frequently, and each time emulate small pieces of a tick. This would be much less efficient, and it is doubtful whether many operating systems would even allow this.

If possible, a better option is to buffer output, like the emulation of built sound does.