TapPatch proto (fast patching from keyboard or MIDI pads): feature requests requested!

If you feel that way about the keyboard, you might want to check out my Sequencer. It is quite keyboard driven. You can even set your own keyboard mapping by editing a json file. Here’s the keyboard reference: https://github.com/squinkylabs/SquinkyVCV/blob/main/docs/sq2.md#Keyboard-reference seq

4 Likes

Many thanks, @dwat3r (and welcome to the forum!) Really appreciate the kind words, and your experience with keyboard-driven workflows in general will be very handy in the alpha!

(also, ++ to @Squinky Seq++, it’s awesome)

1 Like

VIM for Rack, yay! :slight_smile: Seriouslly, this looks very interesting. For me the biggest damper on Rack patching pleasure is mouse usage, so if this can be made to work smoothly it could likely be my primary interface.

2 Likes

Thanks, @LarsBjerregaard ! Now I’m thinking about what emacs for Rack (or ed for Rack) would look like :sweat_smile:

VIM is definitely the right comparison because of the modes (happily this is quite a bit simpler to learn!)

I don’t know if you’re interested in joining/have time to join the alpha (or later, beta) but even if not I’d love any thoughts you have on useful features, what smoothness would look like, your controller setup, etc.

1 Like

Sure, sign me up! I can’t promise I’ll deliver anything on deadlines but I’ll be happy to try it out and give feedback. My first thoughts are ambitious. I can use my keyboard for patch-cables, but the other large part of mouse usage is placing modules and moving them around, and moving knobs/controls on modules. Doing that by keyboard as well would be awesome!

There was an old Firefox extension I used to love dearly. You would hit Escape and every control/anchor on the page would get a little number next to it. Then you would hit the number and the cursor or focus would jump there. Fantastic and effective keyboard usage for webpages. Wondering if something similar could work in Rack.

1 Like

You’re talking about Vimperator :slight_smile: That was an awesome plugin I’ve also used :slight_smile: http://vimperator.org/

The suckless guys actually created a browser named Surf, which has this keyboard-driven control as default. https://surf.suckless.org/

I agree, module arrangement would be the last thing which would need a mouse after this plugin.

3 Likes

@LarsBjerregaard - excellent! no worry about deadlines, anything you can think of sounds great.

@dwat3r - thanks for the link, that looks neat!

Both (& everybody else interested) - I’ve started with the pads model b/c it unifies keyboard and MIDI controller use (and flexibly scales down to 2x8 and 2x4 configurations) but there’s no technical reason why a keyboard-requiring approach that used letter/number “paths” instead of directional “paths” couldn’t be implemented; in fact it would actually be a pretty quick thing to test out (or bake in) as an alternate selection mode. I would be interested to know what’s a better experience as the directional selection feedback may move more quickly from screen=>eyes=>brain=>fingers even if the paths are longer. But that’s a perfect candidate for alpha/beta test feedback :slight_smile: and if you want to think through what a full-keyboard system design would look like I can definitely work up a prototype for it!

Yes, patching is not the end goal here by any means.

Here are Rack’s interface layers (I think this is a complete list, please add if I’m missing anything!) and what I think can be done with them from the pad and key perspective (in roughly priority order, although some of the module-level stuff could bump up if the interface design becomes clear because I’ll have implemented module select in the patching context):

  1. Patching–pretty much covered by feature list, proto is already highly usable
  2. Standard controls (basically anything that can be mapped with existing tools)–LOTS of possibilities here, more details soon :slight_smile:
  3. Module-level operations (e.g. disable, disconnect, randomize, delete): already have keyboard shortcuts which module select could pass through; for pads, module select plus modal pad commands would work fine, though the positional mapping will be somewhat arbitrary
  4. Module movement post-creation: tricky interface design but doable with module select and move keys (probably something like “place a shadow”=>“move to shadow”)
  5. Module insertion: this is tricky insofar as it has a different positional concept (mouse in empty space) and would need a custom menu to be workable with pads, but @stoermelder MB has shown that it is completely doable; just need the design.
  6. Nonstandard controls and right-click module menus: probably nothing standardized enough to work with (I think of these like DIP switches anyway, so if going to the mouse is like unscrewing something from the Rack, that’s fine)
  7. Top-bar menus: probably nothing (and nothing needed)
  8. edit: I should really list view here, which supports the others; some existing keyboard shortcuts, ots of possibilities with pads (including integrating with other modes)

This is a V1 list, of course; V2 will add some other things (more hover feedback, etc.) which raise interesting possibilities of their own.

1 Like

Yeah! Thanks for the link, and via that I found https://vimium.github.io/ which I definately need to try out on my Chrome browser.

1 Like

Hi all! Here’s a quick update, since it’s past the end of May :slight_smile:

I’ve been able to progress on this pretty steadily despite a scarcity of time. The technical debt from the prototype is mostly paid down, so the module has a sensible structure, proper command/event system, etc., and the alpha is close to ready (I’m hoping to start it sometime next week). Some of the planned alpha features have been bumped (either to a second alpha or to the beta), but the core features have been expanded and refined in a way I’m pretty happy with. I’ll update the public feature list once the first alpha is out, in case anyone’s interested in following along.

Right now I have a decent group of people interested in the first alpha, but I could add a few more, so let me know if you want to get involved at this point. This is also the best time for big feature requests, as the interface is still finding its shape, so post here or message me if you have any ideas, no matter how outlandish!

Existing alpha testers, thanks again, and I’ll be in touch shortly by message.

1 Like

I would like to jump in for testing the module

1 Like

@rsmus7, fantastic! Many thanks!

I’ll send around a 3-minute survey (regarding setup/interests/etc.) in a few days and follow up soon after with builds and/or code.

2 Likes

I have one idea in mind for total control over Rack with the module: knob / fader / button setting. It could work like you tap a different key, then enter the parameter adjust mode, and after select the knob / fader / button the same way you select a port, then for knobs / faders you’ll have eventually 2 keys, for buttons only one. With this, you can patch and configure a fixed rack just with this module. :slight_smile:

1 Like

Sounds good! I had already planned to let the module spread parameters out on a MIDI controller, but I think you’re on to something with a pure keys/pads approach as well! Consider it on the main feature list.

I imagine that some sort of coarse-fine control would be useful for knobs/sliders, and maybe a direct entry feature as well that allows typing a value (what right-clicking currently does on standard params).

As far as selection (for this and for the MIDI control spread), I’m thinking that the best way will be to select a module to target using the grid search, and then do a second grid search just on that module (there will be a cable patching mode that works like this too, BTW).

We can experiment with selecting from all onscreen params (the way it works right now for ports) but for some reason I think that might be more suited to patching than to parameter control. Not hard to try both ways, that’s just my best guess in advance; happy to hear your (or anyone else’s) thoughts on what to prioritize!

1 Like

Quick update: Real Life ™, specifically paid work, has intervened hard on my timeline. I should be able to get back to coding next week and will update the plan at that point! The good news is that during my time away I think I’ve solved some interface issues (in my head, at least) so there may be more in the alpha than originally planned. Still very excited to get this into other people’s hands as soon as possible.

2 Likes

Sign me up too!

1 Like

any news?

1 Like

Thanks all for continued interest in this!

@rsmus7, my head is finally getting above water from pandemic/day job stuff and I am excited to pick this up where I left off (plus some new design ideas). Hoping to have a proper update by the first week in September.

@pgatt, fantastic, will do!

1 Like

Hello all!

So, any other announcements recently? Anything going on? :stuck_out_tongue:

In all seriousness, since we now have a Rack 2 date range (and since I’m going to be slammed at day job through November, it turns out) here is my goal:

  • Spend any time I have between now and November:
    • (before Rack 2 alpha code is made public) refactoring and refining the existing features so the codebase is as clean as possible;
    • (after Rack 2 alpha code is made public) furiously adapting the existing code to the new API–while I think that everything planned (and more!) will be possible, this plugin is obviously way way out in the 10% of stuff that’s not an automatic upgrade).
  • Soon (maybe 2-6 weeks, depending on API stuff) after Rack 2 is released, I hope to have an alpha with approximately the feature set described above, which I’ll send around to the kind folks who have already expressed interest, as well as anyone else who speaks up before then.
  • After the alpha, and an open beta, if it seems rock-solid and the response is good, I’ll bother @Vortico about whether there ever might be space for this in the VCV Library, or whether it’s so far in the corners of the API that it will need to stay Pack Tau’d.
  • In either case, I’ll plan to open it up and continue development (it’s already essential to my own music-making, even in its current fragmentary form, and I think that people who like this sort of thing–however few or many there are–will really like it!)

So, thanks for both your interest and your patience, and I’ll be back in touch by November (or earlier, depending on when Rack 2 code drops and when I get a chance to start porting).

In the meantime, feature requests and expressions of alpha/beta interest are more than welcome!

2 Likes

Great idea! Which code you use to create pathches (cables) between modules? Is it api methods?

It’s been a while, but since then I’ve stumbled upon this gem: GitHub - rvaiya/warpd: A small X program which provides novel methods for keyboard driven cursor manipulation. It’s basically a keyboard-driven cursor controller. It’s obviously nowhere near as efficient as your idea, but worth mentioning for a very general use-case for those whose wrists hurts like mine from constant mouse use.

1 Like