Input output - just opinion state of mind

Would fit in category „Dummy, me“
My head is spinning

Just for me! it so hard to be able to keep in mind outputs do have inputs and inputs have outputs and having s th to select in big input or output list an output or input of a function of a module and not forget to later dial the input of the connected module for the functional output of the module I have selected now
Which equals in modular plugging one or two cables into two corresponding jacks

So far it doesn’t seam easy for me to achieve what I was thinking to try
I keep my hands off for a few days from the versatile amazing digital module

I wish all connections could be done by graphic points or something on screen to select from or time will come I master the logic of the system

The reason there are input and output modules, is to let you choose how to use the input and output jacks.

I agree that the input module could be made simpler. Please join this discussion -

The output module has an input in the patching grid, because how would you otherwise send a signal to it? In the output module you can choose to which of the output jacks you want to send the signal.

The alternative would be to make an output module per output jack, but then you have 8 different output modules, so it makes the list of modules unnecessarily long. The same with the input module, imagine if we had one seperate module per input jack …

If you have a better suggestion how to simplify this please add it to the above topic so other people can join the discussion.

If we would have to show all possible inputs and outputs in the patching grid, for each of the modules, in a kind of patching pin matrix, it would be enormous and would be scrolling in a grid like in excel. It would exponentially increase in size as you add more modules.

So that is why the input and output lists are used, and they only show the inputs and outputs available for the modules you have connected.

Here is the quick procedure:

  1. go to the first module you want to connect
  2. hold the shift left or shift right button and press the button for the other module you want to connect to
  3. the modules will now both have a blue border around them to indicate they are connected
  4. next step is to enable all the inputs of the two modules you want to use.
  5. finally, enable the outputs of the modules you want to use.
  6. the system will have automatically connected the inputs and outputs which are enabled.

For example for an LFO and output module:

  1. put LFO and OUT module on grid
  2. go to LFO in grid
  3. hold shift-left or shift-right and press the corresponding button for the OUT module in the grid (use 8 soft keys)
  4. LFO and OUT module now have blue border
  5. while still on the LFO module use encoder 4 to scroll to Sine: Out: In and press it to enable the output
  6. now go to OUT module in grid
  7. using encoder 3 scroll to and enable (press) the Out: In in the leftmost list on the right

You only have to enable the Out: In on the OUT module one time, of course. It stays enabled until you delete the OUT module from the grid.

Separating on two different pages the routing for the physical IN and OUT to faster access and address them for example on a page that shows the 16 in and 8 out jacks and from there going on to the routing to the modul connecting points, like Hold a button of a graphical jack plus the addressed Modul to start the connection

The Internal routing would be less cluttered

How will this feature improve the workflow or experience for all SSP users (keep it short and focused):

coming from the modular usability I first want to be clear which physical IN or OUT I want to use for what result

1 Like

Perhaps it would smooth flow if there was a global pref for the “obvious” choice to be auto patched from both ends after shift connecting.

For me the initial confusion was after Shift-connecting and enabling the output … in my Brain I think “ok it’s done” but then I have to remind mysf to return to the other tile to enable connections to complete the task.

If there’s was a pref for auto connecting most common Audio to Audio paths this would ease flow of creation.

If not that, even a visual cue giving the user a “hey… nothing’s connected on the other side for this to work” reminder.

1 Like

I’m just trying to think of a logical way to program this, and it is difficult. The reason why auto connecting things based on outputs is difficult, is that you might not want all of those modules to have what might be considered the automatic connection.

For example, I have an input module connected to 4 WTO modules. I have pitch and gate going to all 4 individually for 4 voices. How would the auto connect work here? Would it require me to be tedious about how I make connections so that the software can follow along with each new output and at what point does this become smoother?

But what if I want 1 input module output to go to the WTO X input of 3 WTOs, but on the 4th want it to go the WTO Y input? How would the software account for this?

I totally understand why the current system seems confusing, but unfortunately I’m really just not sure of how to reduce that without reducing its flexibility. I also think that once you are able to internalize the current system it really is not that bad given the flexibility it permits.

As a tester for a while I might be biased in this regard. I’ll just say that as long as no functionality is diminished with a new system, I’m good. I do think the current one works pretty well though. :wink:

Rather than smarter automation or rule based patching I think we will get more mileage out of improving the usability of manual methods, with the goal of improving efficiency without diminishing flexibility.

1 Like

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
    destination choice.
    Now either:
  • hold a different keyboard modifier and click target module
    Or perhaps:
    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.

Seems like the fastest path to this would be running puredata on the SSP.

Can you go into some detail about how this would work?

Attach a mouse and keyboard. Run pd instead of the default ssp app. We would need some details regarding how to make use of the encoders, buttons, and jacks.

Initial setup would require Linux knowledge, but someone could potentially make a Linux image that boots straight into pd for the command line averse.

Oh, I misunderstood. I thought you were proposing some way of integrating the SSP app into pd itself, not simply running pd on the SSP hardware :slight_smile: I guess this could be done, why not? I don’t have direct experience with pd, but would be into learning it. Not sure any of this really solves the problem, more like sidesteps it, but I suppose the only way to judge the value of this is by what creative options would be made available (and how easily) as a result. Obviously, the harder path here is moving the SSP app in the direction of what I proposed, so I dunno - we’ll see if anyone agrees with me or not.

@Mercurial - love the Turbosynth as an example of signal flow and honestly it’s the same workflow overview that Kyma and Reaktor still use today.
I’m a strong advocate for a picture is worth 1000 words in UI design but working with the SSP isn’t the same as starring at a wall of text either. The SSP does indeed have a lot of screen real estate at the ready so maybe it’s possible to have a way to showcase a global or macro view of your completed patch overview or workflow…?
The mouse might be a good idea since there’s already an extra USB input, but maybe people could use a Wacom tablet, trackball, PS4 controllers or even a Wii nunkuk to move the cursor around for navigation…?
All interesting ideas for sure!
It’s going to be interesting to see how this module evolves given more time and more users :sunglasses::+1:

Ideally, this would be the network page…

Not sure I understand what the advantage of a mouse would be.

Unless, of course, you were running Pd instead of SYNTHOR.

@jason I understand that the Network page already represents your patch but was just entertaining the ideas put forward by @Mercurial to possibly change it up.

The benefits of a mouse (or any other input device) would be to quickly navigate the UI (menu,cells, samples, etc…) without having to be within arms reach of the module and/or using the Data encoders in conjunction with the navigation buttons I guess… maybe @Mercurial can speak more about his application for these input devices more.

it has been suggested to have a “macro control dashboard” by @Mercurial and @PyroMalibu (see the macro thread) where you have the most important patch parameters available to tweak using the encoders.

Of course that doesn’t give you a different patch visualization. It just gives you access to the most important parameters.

Completely changing the user interface or patching system or supporting mouse or other input devices application-wide so you can do it all with the mouse and a keyboard is not something we have the resources for at the moment.

Stuff like a zoom out for really big patches using a shortcut is something more realistic we could implement. That might help with not getting lost in a patch if it grows big.

1 Like

We have the remote control surface that we plan to integrate further and update for use with the SSP. It has almost the same button / encoder layout as the SSP but it has 16 additional shortcut buttons and 8 encoders instead of 4. You can connect that via USB to the SSP.

1 Like

I’m increasingly of the opinion that labels should be accessed by a shortcut that shows them in an overlay in very large type that is visible from a distance. The rest of the time, the labels are hidden from the screen, freeing up additional screen space.

what would that look like? just want to make sure I understand.

Unfortunately it would require a dedicated soft key unless someone has a different idea that hasn’t occurred to me.

The legend for the soft keys would appear when the legend key was pressed. In my previous mockups I imagined this would cause other UI elements to shift/rescale to make room (thinking you might want to leave the legend on screen) but if we’re talking about a situation where the SSP is remote (so, potentially quite a bit further away than at arm’s length) it seems to make more sense for the legend to either overlay or completely replace the screen contents, allowing for very large type (and ideally, no abbreviations).

As far as how the mouse/kbd would be used, I see it working much like the whole Turbosynth/Max/Reaktor/ paradigm, since this is familiar to most experienced users, and so much work has been done in this arena. Mouse to select modules, kbd modifiers to either pop up info about them or indicate that you are patching, just like I detailed above. Basically, leveraging the best of the long-established computer GUI aspects to speed up working with and creating complex patches in the SSP without being limited to cursor keys and a grid as your primary interface. Note that this would be optional, e.g. one would have a choice to work with the existing button-based UI, or not, so that would accommodate most any user preference in terms of interface style. And yes, it wouldn’t have to be a mouse, could be a trackball, tablet or other USB device, potentially. What is certain is that we all know how to use mice and keyboards, and are all familiar with concepts like modifier keys, shift-to-multiple-select, etc, and since these things provide great speed and convenience, it’s an obvious move to support them when you’re talking about a device like the SSP with such potential for enormously complex patches, where speed and convenience become not just luxury items, but essential.

And I just realized I should’ve been replying to you, Jason, so apologies for the misdirected reply :slight_smile: You asked what the advantage of a mouse would be, and I was trying to address that.