Status for my apps/command-line tools:
Pester: Version 1.1b24 includes full Mojave support.
Shroud: There is a race condition I am trying to isolate, and some bug fixes that should eventually warrant a release. Dark Mode support is implemented if you build from source.
Hermes: I don’t officially support this app any more due to a lack of time, but nobody else has taken it over either. Aside from the recent connection problems (since fixed) due to Pandora not updating their certificates, there are no known Mojave-related issues. Hermes is going to take the most work to support Dark Mode, because drawers have no Dark Mode appearance. This means the UI needs to be revamped to remove them, probably replacing them with history and station list popovers. Contributions are highly welcomed. I’m happy to share my thoughts about future UI directions if desired.
LaunchBar actions: I recently updated LBOfficeMRU to fix some incompatibilities with Office 16; otherwise, no known issues.
NewsBlur Open in New Tab: Not supported in Safari 12. Its replacement, NewsBlur Helper, is in beta.
launch: Needs some updates for APFS, but otherwise functional.
appswitch: No known issues, but I have an unreleased update which filters XPC services by default. Build from source if you would like.
brightness: Less and less functional given Apple’s auto-brightness doesn’t play well with it, but no new issues in Mojave.
soundsource: No known issues, but it is 32-bit and may break in Mojave’s successor. I have not looked at how hard this would be to fix.
]]>The comparative length and severity of bugs on the above lists speaks for itself.
]]>I was working on something else today, when I remembered “hey, doesn’t Windows have compatibility options for this?” Of course it does! Find natspeak.exe and check the following box in Compatibility Properties:
This makes DMPE look better and no longer have issues with window placement. DMPE complains once during launch that it doesn’t want to be in compatibility mode, but it doesn’t stop you.
]]>The reality turned out to be good in the short term but potentially concerning in the long term.
DMPE 2.3 (the version in the About box is actually 12.53.350.033) does add partial compatibility with Windows 10, Internet Explorer 11 and supposedly Office 2016 — I am still using 2013 on the Windows side. It does not support current versions of any modern browser (Firefox, Chrome or Edge). It also fixes a very irritating and long-standing issue described in the release notes as “Too many internal messages overwhelm the system and cause Dragon to appear frozen.” These freezes would last for many seconds and happen seemingly at random, but often manifested when trying to turn dictation on and off. Now toggling dictation is a reliably sub-second operation — I have not noticed a single such freeze since upgrading to 2.3, which is incredibly gratifying.
I continue to iterate on my dictation buffer setup. Since my most recent post on the subject about a year ago, I have fixed some pesky bugs and worked on further virtual machine automation. This has involved such diverse things as performance profiling that helped me partially work around the above freezes, and editing the Windows registry to prevent the Dragon Word addin from getting automatically disabled. I am currently hard-coding my profile path as this is necessary to fully automate dictation startup with a roaming profile, which you’ll need to change if you want to try it yourself.
I had been automating some basic formatting tasks with the built-in Dragon “Advanced Scripting”, as it’ll work on the hospital’s Dragon 360 environment as well as my home/laptop DMPE setup. Unfortunately, Advanced Scripting simulates keystrokes extremely slowly (and apparently slower still on Windows 10). I recently discovered that the older Dragon NaturallySpeaking macro language is still supported; you just need to import an old command, and you can duplicate it. The old language appears to be at least an order of magnitude faster even on Windows 7, so I’ll be using it in future.
In addition to my virtual machine Windows 7 environments, I have recently installed DMPE on Windows 10 in Boot Camp on my 13ʺ Retina MacBook Pro, to see if I can do some of my work without a dictation buffer at all. This has been frustrated by DMPE’s lack of support for high-DPI displays (which persists in 2.3). So instead of using high-DPI, I set the display magnification to 100%, try to use font size adjustments where available to make text readable, and squint or use Magnifier where such adjustments are not available. (I found a better workaround later.) Despite several years and Windows versions, high DPI support in Windows is still inconsistent and buggy. OS X looks amazing by comparison.
Another issue with Windows 10 in Boot Camp, unrelated to DMPE, is Boot Camp’s keyboard and trackpad drivers. Unlike on OS X, remapping Caps Lock to Control does not eliminate the accidental-activation delay, and while a kind soul has reverse engineered the appropriate HID commands to remove the delay, I will need to port the code to Windows before I can make use of it. The trackpad is even worse with no workaround of which I’m aware — simple trackpad activities such as clicking and right clicking are completely reliable when booted into OS X but inconsistent on Windows.
The future contains many potential pitfalls.
If Apple switches to ARM-based Macs, running Windows in virtualization will become untenable and I will likely need to start using a non-Mac as my primary machine, or attempt to make do with a Mac version of Dragon Medical.
EMC, in their great wisdom, laid off the entire team developing VMware Fusion for OS X. There has been a single patch release of VMware Fusion since then, which didn’t seem to break anything too horribly, but i don’t have high hopes for the future of the software. The only other option for high-performance virtualization on the Mac, Parallels, is well-known for their shady business practices, would be more expensive, require more frequent upgrades, and from what I can read, also has poorer quality audio driver support.
Currently, DMPE is still based on Dragon 12, which is two major versions behind the current non-medical version. Nuance has publicly stated that there will be no further major releases of DMPE, and that its future is Internet-connected, subscription software which would end up costing about 5-10× as much ($135/month) in my usage model. In addition, automation choices appear to be substantially reduced or eliminated in this future version, which would likely mean I would have to rewrite or completely abandon my dictation buffer software.
The good news is that with Windows 10 and Office 2016 support, and a relatively new laptop, I’ve got a few years to persevere with my current setup before I am forced to make any changes.
I continue to hope that speech recognition’s entry into the mainstream will eventually penetrate the medical market, finally dragging medical speech recognition out of its expensive, flaky, buggy backwater into the 21st century. In the meantime, I will be thankful for small victories, such as that I didn’t experience any freezing while I dictated this blog post.
]]>In any case, The Dash firmware 2.0 (now “Bragi OS 2.0”), which I wrote about in my most recent post, is now released. Full release notes are here. The major version number increment is definitely deserved, as it adds a lot of features, not all of which I’ve had a chance to evaluate. The timing of these changes does seem to correlate with more general availability for the earphones.
The pairing procedure for both the Bluetooth and Bluetooth Low Energy sides have been overhauled. Both now require pairing codes which theoretically prevent spoofing. More usefully day-to-day, you no longer need to explicitly pair the Bluetooth Low Energy side every time you want to use it. Instead, just inserting it in your ear is enough for it to show up in the app. Both audio and visual prompts during pairing are very well done. Given the design of the Bragi app, I’m pretty sure this pairing procedure was intended all along.
While not commented on in the release notes, the touch sensitivity seems less sensitive to hair brushing against it.
Microphone (hence Siri) quality is once again somewhat improved but it still sounds like you’re talking inside a tin can. The iPhone’s internal microphone is a lot better if you’re able to use it instead.
My trick to give the left and right Dash different names still works, and unfortunately you still need to rename the device twice to get it to stick.
I’ll be trying out cadence detection for cycling tomorrow; I’m not much of a swimmer.
There’s still a lot more to come — including, eventually, a SDK…
]]>Here’s how to do it:
The Dash firmware 2.0 is now in private beta testing. Unfortunately I didn't respond quickly enough to the call for testers on Facebook to get in the pool. The advertised list of upcoming features is pretty enticing:
The Dash is getting a lot of competitors in the cord-free Bluetooth headset market. I hope Bragi is able to keep up and realize more of their vision, while fixing practical issues such as those related to pairing and Bluetooth range.
]]>I assume here you have an existing local user profile to migrate. Dragon NaturallySpeaking’s WebDAV client is inefficient and includes many configuration options of dubious utility, but does (eventually) work. For WebDAV on IIS (or SMB), the instructions in the administration manual appear relatively complete. The manual mentions Apache compatibility but includes no setup information, nor could I find any elsewhere on the Internet. So, my server examples use WebDAV with the Apache HTTP server 2.4.x.
It's 2016 and you should be using SSL/TLS by now. Mozilla has a nice SSL configuration generator; this is the configuration I'm using. The newest protocol Dragon NaturallySpeaking 12 claims it supports is TLSv1, so the "modern" configuration likely won't work.
My configuration follows. Authentication is however you want to set it up; I use digest auth behind SSL/TLS. Obviously, replace my file paths as appropriate. The Dragon NaturallySpeaking WebDAV client configuration includes options to follow redirects, but they don't work properly and aren't compatible with connection keep-alive. Thankfully, Apache has a workaround for such brokenness (redirect-carefully). The client expects infinite-depth requests to work, hence DavDepthInfinity on.
DavLockDB /var/www/sabi.net/webdav/dav_lock.db <Directory /var/www/sabi.net/public/dragon> Dav On DavDepthInfinity on AuthType Digest AuthName dragon AuthUserFile /var/www/sabi.net/etc/digest.passwd Require valid-user SSLRequireSSL # Redirects don't work. At all. BrowserMatch "Nuance component" redirect-carefully RewriteEngine off </Directory>
Make sure the directory is writable by the Web server user; mine looks like this:
drwxrwsr-x 4 nriley www-nriley 4.0K Apr 23 11:49 /var/www/sabi.net/public/dragon/
Documentation is here. Follow the instructions under Enable the Roaming User Profile feature and Set location of Master Roaming User Profiles.
In HTTP Settings, specify your username, password and an Authentication Type as appropriate. Under Connection, click Never for Follow Redirects and check the Keep Connection Alive box. I didn't change the Timeouts from the defaults.
My SSL Settings are as follows:
I haven't actually tested if my server certificate is verified, but I do know enough not to check Using OpenSSL in an application that hasn't been updated in years.
Click Test Connection. If it fails, check your Apache logs; client-side feedback ranges from unhelpful to misleading. You'll notice that every single request is initially tried unauthenticated — I couldn't figure out a way to stop this from happening. Once I was confident that authentication was working, I filtered out these duplicate requests. Here’s the whole test:
% tail -fn 0 /var/www/sabi.net/logs/ssl.*~*.gz | grep nriley nriley [23/Apr/2016:19:18:15 +0000] "PROPFIND /dragon HTTP/1.1" 207 1210 "-" "Nuance component" nriley [23/Apr/2016:19:18:15 +0000] "DELETE /dragon/tst.tmp HTTP/1.1" 404 522 "-" "Nuance component" nriley [23/Apr/2016:19:18:15 +0000] "PUT /dragon/tst.tmp HTTP/1.1" 201 442 "-" "Nuance component" nriley [23/Apr/2016:19:18:15 +0000] "DELETE /dragon/TempDir HTTP/1.1" 404 522 "-" "Nuance component" nriley [23/Apr/2016:19:18:16 +0000] "MKCOL /dragon/TempDir HTTP/1.1" 201 442 "-" "Nuance component" nriley [23/Apr/2016:19:18:16 +0000] "DELETE /dragon/TempDir/tst1.tmp HTTP/1.1" 404 522 "-" "Nuance component" nriley [23/Apr/2016:19:18:16 +0000] "PROPFIND /dragon HTTP/1.1" 207 6554 "-" "Nuance component" nriley [23/Apr/2016:19:18:16 +0000] "PUT /dragon/TempDir/tst1.tmp HTTP/1.1" 201 458 "-" "Nuance component" nriley [23/Apr/2016:19:18:16 +0000] "DELETE /dragon/TempDir/tst2.tmp HTTP/1.1" 404 522 "-" "Nuance component" nriley [23/Apr/2016:19:18:16 +0000] "PROPFIND /dragon HTTP/1.1" 207 6554 "-" "Nuance component" nriley [23/Apr/2016:19:18:16 +0000] "PUT /dragon/TempDir/tst2.tmp HTTP/1.1" 201 458 "-" "Nuance component" nriley [23/Apr/2016:19:18:17 +0000] "PROPFIND /dragon/TempDir HTTP/1.1" 207 2858 "-" "Nuance component" nriley [23/Apr/2016:19:18:17 +0000] "GET /dragon/TempDir/tst1.tmp HTTP/1.1" 200 341 "-" "Nuance component" nriley [23/Apr/2016:19:18:17 +0000] "PROPFIND /dragon/TempDir/ HTTP/1.1" 207 1162 "-" "Nuance component" nriley [23/Apr/2016:19:18:17 +0000] "MOVE /dragon/TempDir/tst1.tmp HTTP/1.1" 201 458 "-" "Nuance component" nriley [23/Apr/2016:19:18:17 +0000] "MOVE /dragon/TempDir/ HTTP/1.1" 201 442 "-" "Nuance component" nriley [23/Apr/2016:19:18:17 +0000] "COPY /dragon/newTempDir HTTP/1.1" 201 442 "-" "Nuance component" nriley [23/Apr/2016:19:18:18 +0000] "DELETE /dragon/tst.tmp HTTP/1.1" 204 261 "-" "Nuance component" nriley [23/Apr/2016:19:18:18 +0000] "DELETE /dragon/newTempDir HTTP/1.1" 204 293 "-" "Nuance component" nriley [23/Apr/2016:19:18:18 +0000] "DELETE /dragon/newTempDir2 HTTP/1.1" 204 293 "-" "Nuance component"
Nuance documentation is here and does a reasonably good job of explaining the options; I recommend you read it prior to my comments below. Here's how I have the roaming Administrative Settings configured:
If you’re going to be the only user, check Display Classic Open User Profiles dialog. This displays a flat versus a hierarchical list of users and dictation sources. Every time you click on anything in this dialog, be prepared for a long synchronous wait for server access. By disabling the hierarchy, you eliminate the wait while expanding your user. (If you only have one user and dictation source, you may not see this dialog at all.)
Allow non-Roaming User Profiles to be opened will need to be checked while you are migrating your user profile to a roaming profile, but can be unchecked afterward.
Merge contents of vocdelta.dat into network User Profile when file is full involves a 500K file; in a WAN environment with reasonably fast links, latency is likely to outweigh any time savings, so I kept this checked.
I unchecked Access network at User Profile open/close only because I keep my profiles open for days at a time and have an Internet connection available at all times. If your usage pattern is different, you may select otherwise.
Despite documentation suggesting that Ask before breaking locks on network User Profiles does not apply to profiles accessed through HTTP, I was asked to break a lock nearly every time I opened my profile until I unchecked it. There might be some server configuration that will let this be checked, but I’m unaware of it.
Always copy acoustic information to network and Conserve archive size on network are somewhat related. How you decide to limit/copy acoustic information really depends on your network performance, patience and desired strategy for propagating corrections and optimizing your profile.
Again, there's official documentation which I won't repeat. There's no progress bar, just an unresponsive interface during migration; watch the server logs or your favorite network monitoring utility if you get nervous.
If you’ve been using Dragon NaturallySpeaking for some time, you may think of your profile as a large, unwieldy multi-gigabyte entity. Much of this is backups and audio data that aren’t strictly necessary — and you’ll notice that the server profile is much smaller because it omits them. My local profiles (compressed!) on two machines prior to migration were 1.4 and 1.1 GB; corresponding sizes on the server are 437 and 430 MB. ~320 MB of each is (primarily) audio in the voice_container subdirectory.
Once you're comfortable your roaming profile works, don't forget to delete your local profile(s).
Much of the information here is out of date but an important and still-relevant sentence is "When using a roaming user profile, backup files cannot be generated in any location". The downside of backups not being written to the roaming profile is that if your profile becomes corrupted (which just happened for me today — I set up Dragon Medical Practice Edition on a new Windows 10 installation and subsequently DMPE crashed every time I opened the profile from my Windows 7 VMs) you’ll have to rely on your server backups. If you don’t have server backups — go fix that.
The Language and Acoustic Optimizers don't run on a roaming profile; they idea is that you run them server-side. I plan on seeing how well they work on a fast network by remotely mounting the WebDAV share, but haven't had a chance to do this yet.
Dragon NaturallySpeaking startup and shutdown obviously takes longer when the network is involved. You can automate opening a profile with a command-line argument to natspeak.exe, but you can't specify a dictation source (if you have more than one) without relying on AutoHotKey or similar. Thanks to various VMware Fusion and/or OS X bugs I already have to babysit dictation startup, so one more click to select a profile hasn't been a great additional hardship.
My other dictation-related blog posts are in the Dictation category, if you're interested. Right now all my dictation effort is targeted at prose, but at some point I plan to investigate VoiceCode — which is currently in the process of being rewritten.
]]>1.4 adds support for broadcasting heart rate to more apps, including Wahoo Fitness, which was confused by 1.3 but works great now.
The audible message when you tap and hold the left Dash is now clearer that this gesture is not only for pairing but for starting Bluetooth LE communication including heart rate tracking.
There’s now audible feedback when connecting from the right Dash alone. Normally, the Dash connects automatically once they’re both in your ears, but you can use just the right Dash by double-tapping it once it's in your ear.
It's now possible to rename your Dash. Unfortunately the left and right sides get the same name, so it remains difficult to distinguish between them. The app implementation is a bit flaky. Sometimes the UI doesn’t immediately reflect name changes. The iOS UI doesn't let you edit the text field directly by tapping on the name, but keyboard navigation via Force Touch (iPhone) or 2-finger touch (iPad) works.
It turns out only the Bluetooth LE side will update the name of an already-paired device. You can use this “feature” to create a different name for each side:
The result is just what you’d expect:
1.4 is the first version in which microphone recording quality is adequate for Siri and dictation — a huge improvement. (Listen to a comparison another user recorded — and I've heard 1.3 much worse than that.) Sporadic disconnections in the presence of seemingly-adequate signal strength seem dramatically reduced once again; I've not had a single disconnection since upgrading.
My biggest remaining Dash annoyances have to do with multiple audio devices. No version has had multipoint support, nor has this ever been promised, but worse is that you can’t initiate a disconnection or pairing from the right Dash once it's connected (however…)
A final tip, if you're still having issues with touch gesture reliability: Use the pad of your finger (like you would with Touch ID), not your fingertip as you would with a touch screen. With this change, my taps and swipes have improved from perhaps a 50% to 90% success rate.
]]>Screen remains the most readable monospaced bitmapped font I've ever used. It’s available in regular and bold weights, and a wide range of sizes: 7, 8, 9, 10, 11, 12, 13, 14, 15, 16 and 18 point. While I mostly use it in the 11 point size, the smaller sizes are terrific for fitting a bunch of log output in the corner of your screen.
After switching my desktop from Mac OS/Linux to Mac OS X in 2001, I initially used Monaco in both aliased and antialiased variants, but missed screen. I continued using screen in X11, running applications on the SGI O2 I then had on my desk, displaying remotely on my Power Mac G4.
In 2003 I used PfaEdit, now FontForge, to convert screen to a TrueType font so it’d work on OS X, and I have used it as my standard bitmapped font since. I would have made the conversions public earlier, but I was concerned about whether this would be a licensing violation. It turns out the SGI fonts were released under a MIT license a few months after I initially converted them back in 2003, but I didn’t notice until today. So, here are the fonts for you to download:
You may notice that these fonts look awful — with inconsistent horizontal and sometimes vertical spacing, even clipping — whenever you try to use them. Recent versions of OS X have been less kind to bitmapped fonts; here are some tips.
In Terminal, you can compensate for the font being squashed horizontally by adjusting the Character Spacing:
The result:
In the Emacs Mac port, you can disable antialiasing and ensure screen font metrics are used on a per-font basis. Here’s how I use Screen 11 if it’s installed, otherwise Menlo 12.
(cond ((eq window-system 'mac) (cond ((x-list-fonts "Screen") (create-fontset-from-ascii-font "Screen-11" nil "mac") (set-fontset-font "fontset-mac" 'latin "Screen-11:antialias=off:destination=1")) (t (create-fontset-from-ascii-font "Menlo-12" nil "mac") (set-fontset-font "fontset-mac" 'latin "Menlo-12"))) (setq default-frame-alist '((font . "fontset-mac") (width . 80) (height . 80) (background-color . "ghostwhite"))) (setq-default line-spacing 1) ; extra spacing [...]
What you get:
In 2008 I built a demo app to demonstrate the various issues OS X had rendering this font, but I never actually filed any bugs. As long as I’m sharing the fonts I might as well share the app (source, binary). It uses a boatload of deprecated/removed API like QuickDraw and ATSUI, mostly to demonstrate how newer font APIs, such as the then-new CoreText, are worse at displaying bitmapped fonts than their older counterparts. You can click the checkboxes at right to see options you can use with the various APIs to try to fix the spacing:
Most Cocoa apps used to display the font without difficulty, but this changed in OS X 10.8 and later, which no longer perform screen font substitution by default. You can fix the font’s display by forcing the old behavior with NSFontDefaultScreenFontSubstitutionEnabled or NSLayoutManager.usesScreenFonts (which is deprecated in 10.11). These are discussed in the AppKit release notes (there’s no direct link but if you scroll up a little from the linked section you'll see it).
Bitmapped fonts are much less useful on a Retina display. A 5K iMac or equivalent is likely in my future when I replace my Mac mini, but not for a year or two as I just bought its current display this year. In any case, I may be posting this just as it’s about to become obsolete. Better late than never?
]]>