I have to say that I concur on this, in general.
Let me elaborate a bit though, if I may.
Automated or rule-based patching has always struck me as one of those "great on paper"
things that misses a crucial point - if you patch things explicitly and manually (just like in the real physical world), you tend to internalize the structure of the patch you’re making in a more solid way than if it’s done automatically. This is particularly important in a software modular system, because patching explicitly (e.g. going through the actual process of “I am now connecting this to that”) most closely resembles the physical act of plugging in a cable, which again solidifies things in your mind. You end up visualizing the patch way better, which makes it less likely you’ll get confused and lose track of where you (or your patch) are.
I still think that ideally, what you really want is mouse/keyboard computer-style explicit patching,
just like we’ve had since Turbosynth (see below.) All this shift-key/cursor-key navigating is way more cumbersome than one would ideally want, from a workflow perspective. It’s important that we not lose sight of that simple truth here. Having mouse and keyboard support in the SSP interface could get us so much closer to this long-familiar methodology than we currently are. Of course, another option in the future is a computer-based editor, which I’m also fine with. However, let’s consider for a moment the difference in speed and clarity between navigating a patch on the SSP’s current key-based method vs. using a connected mouse and keyboard.
The patching process I’m proposing might work something like this;
- Select source module with the mouse (and a keyboard modifier key to indicate you want to create patch connection)
- a list of available sources within that module pops up. Choose desired source
from list with mouse or keyboard cursor keys. Your selection flashes and the list vanishes.
A flashing outline appears around the whole window to indicate the SSP is awaiting a patch
- hold a different keyboard modifier and click target module
drag source module’s icon on top of desired destination module, which gets highlighted.
- a list of available destinations in the target module pops up. Select desired target in destination w/ arrow keys or mouse. Your selection flashes and the list vanishes.
Patch connection made.
Total time elapsed: under 5sec.
Number of gestures required: 4
Given that we’ve all long-since internalized the keyboard/mouse paradigm, this seems like
the obvious workflow to me in this context. I’m keen to hear everyone else’s opinion on this.
This brings us inexorably to the other most important UI topic here:
How a patch is visualized in a software modular environment.
I hate to say it, but I have yet to see anyone make things
clearer and more immediately graspable than this, 30 years later:
Have a look at the charmingly quaint example above.
You can know nothing about this program, but if you have a working knowledge of audio software and the modular paradigm, it’s pretty immediately clear what’s going on: Palette of available modules on the left, workspace window, patch cables. Mixer module, time stretch, filter and pitch shift modules. Output jack.
Now, of course Turbosynth was well primitive by today’s standards, and also didn’t deal with CV, just audio routing. This adds considerable complexity, I realize. However, there’s a lesson here -
Even crude graphical icons that give an idea of a module’s function, coupled with
the ability to physically arrange modules in a workspace freely, for clarity
(as opposed to be constrained to a grid layout) contributes significantly to the immediate clarity of the whole application.
Again, I’m keen to hear everyone’s opinions on this, but after a whole lot of work in software modular environments over the last 30+ years (Turbosynth, Max, Kyma, Plogue Bidule, and others), I have a reasonably solid experiential base to draw from in this context, and I feel it’s hard to argue with the simplicity and immediacy of this approach.
Of course this is a drastic shift in direction from what currently exists,
but I’m not trying to be a contrarian here; just trying to keep an eye on the shortest distance between two points, workflow-wise. We all have to live with this UI design for a lot of hours
and years to come (hopefully!), and I would feel remiss if I didn’t bring these things up for discussion. It’s crucial to always consider the quality of the actual moment-to-moment experience of working with the SSP for hours at a time, and not get lost in the forest of minutiae here as we all contribute to the device’s evolution.