My good friend and fellow Zendrum evangelist E. “Doc” Smith was kind enough to mention the ZDS Shifter in his latest blog post. Eric has Shifter #0001 — the first beta unit off the assembly line. It needed a few upgrades to catch up with the latest model but it’s working like a champ!
EDITORS NOTE While this article focuses on the ZDS Shifter, everything here applies equally to the Zendrum Stompblock.
A typical “pure” MIDI thru device can claim to have zero latency as the MIDI In connection is generally wired directly to the Thru/Out port. However, the Shifter (and the Stompblock) use a soft-thru.
Why a soft thru? It’s because these devices need to receive and analyze the entire MIDI packet (typically 3 bytes) before deciding what to do with it. In the case of the Shifter, this includes looking up and processing any “shift rules” associated with the message before retransmitting the message.
The Shifter is a low-latency device and the average time it takes to process an incoming message is 100 microseconds. That’s a tenth of the milliseconds in which latency is usually expressed and completely imperceptible.
However, that’s not the true latency of the device. Because as I pointed out, it needs to wait for the entire message before it can start processing it. This means the REAL latency is about 10 times that, but still only around 1 millisecond and generally below the level that a human can detect.
The conversion to USB adds on a bit more latency that varies in length as it needs to line up with the 32-bit (4-byte) frames that USB uses. On the high end, this can add another 500 to 800 microseconds meaning that the true latency of the Shifter ranges from 1 to 1.8 milliseconds. Your mileage may vary as you also need to take into account the hardware (and software if applicable) on the receiving end.
Generally speaking, if you’re connecting to a hardware sound module or a modern computer you should experience very low latency.
Chrome version 66 has apparently broken the Web MIDI support that the Stompblock client relies on.
We are looking into workarounds for this issue, but if you depend on the interface, you might want to hold off updating Chrome for the time being.
I’ll post any further information as soon as it is available. Thank you in advance for your patience!
** UPDATE **
The latest version of Opera is still working. Although it uses Chromium under the hood, it’s still at version 65 and isn’t suffering from the issues that Chrome 66 has. Installing Opera is a viable workaround in the short term until we sort out what’s going on with Chrome, though if they release a newer version of Opera it’ll likely have the same issue.
** UPDATE2 **
A workaround is now in place and the client is working in Chrome 66 as of version 5.3
In preparation for the upcoming release of Restomp (the card editor for the STOMPBLOCK), the client application now supports importing ZenEdit map files.
While you’re working in Restomp and typing names for your samples, it’s building a ZenEdit map file behind the scenes. You can then later import this file into ZenEdit (and now the SB client too) so that the proper instrument names are displayed.
This feature was released in version 4.8 of the STOMPBLOCK client and is available right now. You’ll find the controls for managing map files on the main Settings tab.