I also expected screenshots there, especially given the word "interface". Turns out, it's not about user interface (UI), it's about programming interface (kinda API). It allows calling window-related functions on Macintosh, X Window System, and Atari. So the resulting windows were looking like a native UI, I assume.
The readers' natural question is 'does this look reasonable on multiple platforms?'. A two-second glance at two or three screenshots goes a long way to answering that.
In hindsight, this sounds more reasonable in 2026 where graphical documentation is taken for granted. In those days I think anyone would have spooled the .ps to their nearest laser printer and begin building something quickly with it just to check the looks.
I remember following a "build your own text windowing system" tutorial printed in a hcontinous paper back then
The document looks to be nicely rendered, likely from Postscript. Maybe generated by roff, since it doesn't look like TeX. Screen cap bitmaps could be converted to EPS and inserted into the Postscript.
If it was a PS document, you would have to spool it to a printer or screen renderer to read it anyway. The X Window System debuted in 1984, so on-screen renders would have been not too hard to find in a CS department in 1989.
As far as I understand, the MMS TTS models are trained from scratch (section 7.1 of [1]), they do not employ any SSL models. So the OmniASR SSL models are not useful here.
What might be interesting is the newly released OmniASR data, because the MMS data, which was used for the MMS TTS, was never released.
Also, the OmniASR can be used to transcribe some untranscribed speech to train a TTS on it.
There is only a single paper that has published a similar derivation but with a critical mistake. To be fair there are many documented examples of how to derive parametric relationships in linkages and can be quite methodical. I think I could get Gemini or 3.5 to do it but not single shot/ultra fast like here.
reply