Planned Development and Release Schedule
TapPatch will be a free, open-source plugin with a community development process. Because it depends on behind-the-scenes features of Rack which may change in Rack V2, it will not be submitted to the Library while we are still on Rack V1. Once TapPatch enters its open beta period, I will make builds available on GitHub (in the manner of @stoermelder’s Pack Tau) which can easily be downloaded and installed.
The code is not quite ready for release, but the community development process begins today! I’m already recruiting a group of around 5 to 10 alpha testers (if you’re interested, let me know soon) who will start giving feedback and suggestions on the nitty-gritty details of the plugin. I’m hoping to release code and builds to the alpha testers by the end of May (there’s more I want to add first, and the code needs a serious refactor before it’s ready for anyone’s eyes).
What I’m hoping for now, from anyone interested in MIDI or keyboard patching, is blue-sky thinking about features. There’s a big list of features below, but if there’s anything you’d like to see, now’s the best time to mention it, as the interface is going to get pretty full in the next three weeks. Now that the basic features (like markers and port search) are in place, it turns out that, for most features, getting them integrated into the interface is harder than actually coding the functionality. And since TapPatch is, by design, limited to 16 pads, there’s not unlimited space for features, although this is unlikely to be my last Rack control module…
After the alpha testing period (~two weeks?), my hope is to pull in another group of people for a short closed beta (probably a week), to make sure the plugin works and is stable on a larger range of systems and to do some additional refinements. Once that’s done, I’ll open up the code and builds, along with a feature roadmap based on alpha and beta feedback plus any requests and discussions in this thread. So if you’re not in the closed alpha or beta, should be able to try this out by mid-to-late June.
Further Details
As the drab grey panel, huge blank spaces, poor alignment, use of Calibri, and all-caps word PROTOTYPE suggest, this is a prototype. (It’s so prototypical that it doesn’t have rack screws yet!)
Right now, it’s being driven by a mash-up of @stoermelder STROKE and VCV MIDI-GATE coming in over that polyphonic cable, although I plan to integrate keyboard and MIDI support by the beta (so that it can be used by itself out-of-the-box). Here’s what’s happening offscreen in the demos above:
I may keep the external gate input to allow things like merging multiple MIDI control signals or allowing multiple keyboard shortcuts for the same pad. (By the way, TapPatch ignores its own gate input when selecting ports, so you don’t have to keep not choosing it!)
The full interface will consist of sixteen pads (of which thirteen are implemented in the prototype). These can be simultaneously activated by external MIDI controllers (4x4 pads recommended) or by ordinary keypresses (with number pads offering a very convenient mapping; plenty of suitable USB number pads are available for less than $20, if your primary keyboard doesn’t have one or you want to place it near other gear). On-screen clicks are also supported as a convenience, but are never required (except for module configuration options which wouldn’t normally be done in the flow of patching).
As mentioned in the feature list below, smaller interface configurations (with a 2x2 grid splitting the screen along the two main diagonals) are also planned. The 2x2 interface would be suitable for non-numpad keyboard use as well as 2x8 and (with some concessions) 2x4 MIDI pad controllers.
External devices capable of displaying colors via normal MIDI messages can show real-time feedback, generally following the on-screen pads, with some differences (for example, the white rings around the on-screen pads will be expressed on external devices as differences in brightness). (External devices which require Sysex messages for feedback will be supported once Rack V2 is released; sending Sysex out from Rack V1 requires a custom build).
And by the way, if you were wondering, it’s already pretty performant (graphically and computationally it’s doing very little compared to what Rack has do on every cycle anyway):
Caveats
While I am making every effort to ensure that TapPatch is as stable, seamless and problem-free as possible, its use of Rack features such as module introspection, cable manipulation and out-of-module labeling means that it’s hard to guarantee the same level of effortless interoperability that we are used to with Rack modules. So, for the foreseeable future, there will be, to quote @stoermelder’s T7 module (which obviously inspired this one and whose code I relied upon), “NO SUPPORT FOR VCV RACK WHEN USING THIS MODULE.” Your use of TapPatch will be supported as much as possible, but no one not involved in the project should be bothered about problems you have when using it, least of all @Vortico, who already has plenty to do.
Background/Philosophy
By this point, Rack has a suite of excellent options for mouse-free parameter control, both built in (MIDI-MAP) and via the Library (MIDI-CAT, for starters). Mouse-free patching, however, has been largely unexplored, despite some interest.
The leading (and, as far as I know, only) option for mouse-free patching is @stoermelder’s groundbreaking T7 suite, part of his experimental PackTau plugin. Jakub Mudrak’s intriguing Midilar controllers couple T7 with an innovative hardware setup, as seen here.
The T7/Midilar approach, however, relies on advance configuration; ports intended to be patched using the system are pre-designated, and cables are added to or removed from them when messages come in. This is very suitable for fixed racks and performance contexts, but not (at least in its current state) for fluid exploration of an ever-changing set of modules.
Hence TapPatch, which accepts the primacy of the screen and focuses on eliminating click-and-drag mouse movements. With hardware modular you need to see your rack to patch it, but you don’t need to drag your finger across it; you pick one port with one motion, and another port with another, and the cable falls into place. This is the basic interaction pattern which TapPatch seeks to emulate in software.
Thanks…
…to everyone (especially if you read this far) for your interest, and thanks in advance for your ideas! Special thanks to @stoermelder (whose top-quality, innovative open-source code, particularly for GLUE and T7, was crucial to this development) and to @Vortico, not just for Rack but for the decision to make Rack’s plugin interface so incredibly open. That something like TapPatch (or the many other interface hacks available) can be added by a plugin, not a fork, is a huge testament to the quality of Rack’s software architecture and to the decisions made during its development.