Input Module

I can totally agree with that. I think the GUI is a solid place to make improvements, which is not to say I think it is bad now. Lots of good discussions on that going on right now, and I’m loving it.

1 Like

i mean, the setup with the 8 inputs, how to assign them and how they are pictured
is this the same setup in every module in the SSP?

1 Like

I had an idea today to simplify the input and output modules.

What if we made 2 input modules, each with 8 outputs, one of them gives you the first 8 jacks and the other module gives you the next 8 jacks. We can call it input A and B.

The output module can be changed so it has 8 inputs corresponding to the 8 output jacks.

There is nothing to be configured inside the input and output modules anymore in this case. The P-page only shows signal scopes for information purposes.

@Mercurial @2disbetter @PyroMalibu @SSPix @NeilParfitt @BrettSaberhagen @jason what do you think?

3 Likes

Nah, this just makes it more cumbersome, because you now have to think about which of the proposed 2 input modules you’re using if you want to access specific outs.

This isn’t hard. See below :slight_smile:

aengine said:
I’m not necessarily saying that the solution has to be a completely open routing matrix (though it would be nice)

I’m necessarily saying that.
On the H9000, you have a graphical routing matrix with arrows going between sources and destinations.
Same on the TC6000 ICON.

Here are some iPhone screenshots:

TC ICON:

H9000:

The clarity of simple graphical routing matrices like these can’t be beat.
There’s a reason companies like TC and Eventide do it this way -
it’s the clearest and most intuitive method of dealing with multichannel routing in complex
devices like these.

1 Like

The routing we have right now is completely open and easier to understand and use than what I can see in the screenshots above. But if you want to further simplify it my last suggestion above is an option.

Sounds interesting, something else crossed my mind maybe color coding in the corresponding grid module color in the lists might ease things when selecting ( as we have a color display
Or graphic icon to select in the grid directly with everything in the list …

@bert I personally do not mind 2 input modules if the SSP is so limited. That’s fine.
Also, color coding would be fine if that’s possible.

The only reason I’d be against 2 input modules is mid patch you change your mind with something and want to move it from A to B or vice versa. And, more clicking around vs it all unified in one tile.

Would switching tiles maintain connection between all modules involved?

Is there a smoother terminology besides A and B? Like INodd INeven or something? I’m just spitballing and haven’t thought too deeply about it…

Yeah, really I just want 1-8 to change when I scroll down the page to 9-16… wish that could be coded.

and color coding so I know what input is actually being assigned.

This has been suggested by @NeilParfitt as well in another thread, we’ll look into doing this.

1 Like

Not a limitation of the ssp :slight_smile: just a proposal to make the software easier to understand.

You mean in the input module you want each scope to have a different colour matching the colour of the toggle buttons used for enabling the channels?

That is a problem, yes. So what we can do is have a toggle button in the input module that switches it from the topmost 4x2 jacks to the next 4x2 jacks. So the input module just has one single toggle button and you switch it from the top group to bottom input group. Of course this will imply some limitations on the physical input jacks you can connect to the input module “virtual outputs” which is maybe not what you want? Right now you have more flexibility on how you route physical jacks to virtual outputs.

FWIW, I had a go with INP and OUT yesterday and really had no problems with routing.

I did, however have clipping in OUT, which I could not easily see when adjusting INP gain. I was surprised to find such an apparent gain increase between INP and OUT with nothing in between, and found fixing it to avoid clipping across two channels to be quite fiddly.

Did you just route some signals from the INP module to the OUT module in the grid, summing them?

If you sum multiple signals you have to reduce the gain to avoid clipping in some situations. You can do that in the input module but the better way to do this is in the patcher grid where you can scale outgoing signals and incoming signals for each module. You do this using shift-left and enc 3 (select the input to scale first) or using shift-right and enc 4 (select the output to scale first).

I routed input 1 to output 1 and input 2 to output 2. Straight. Nothing summed. Gain significantly increased. No idea why.

There is absolutely no visual indication on the screen that this is possible, is there?

the default for an output module is to send its signal to jacks 1 and 2 (see the P-page)

so if you did not change the default, and you routed input 1 to an output module, and then input 2 to another output module, you will be automatically summing those two signals, with the result going to both jack 1 and 2.

also, if you have the global delay and reverb sections enabled those might also influence the gain of the resulting output signal.

OK, I think I understand. I’m not feeling any of this is very intuitive.