Percussa Home / Shop / Contact /

Automatic module connection in Network menu

SSP Features and Ideas
#1

Description of feature (short and simple):
Whenever one connects 2 modules together, for example sampler to output, the user needs to “confirm” this connection twice, i.e. make a connection, select that Sampler goes to Out1 and then in Out module confirm that it will take input 1. Although this allows for flexibility in configuring modules, it is also unnecessary when making a connection, since if i connect Sampler to Out1 i don’t need to confirm it again in the Out module.
What I propose is the following:
When connecting 2 modules ( Sampler to Out for example), when I make an assignment of Sampler --> Out 1, Output module will automatically confirm this as a destination without having to select IN1 in the Output module. Later if you want you can reconfirm that.

How will this feature improve the workflow or experience for all SSP users (keep it short and focused):
This will make the workflow more intuitive and fast, no need to reconfirm every connection.

Are Core OS + User Experience ‘feature complete’?
#2

Imagine patching real modules, if i patch Output of oscillator to a VCA, I don’t need to think wether VCA takes this oscillator signal because i already patched it there. Then if I want to break a connection I can remove a cable from either OSC output or VCA input.

#3

the reason the patching system works like it does is because it automatically repatches for you if you break a connection with a module and connect that module with another module.

the software will check what the module is allowed to modulate and what it accepts in terms of modulation and based on that it automatically makes the connections.

this is called “rule based patching” and as mentioned on the kickstarter page.

if we make the patching system explicit as you describe you will have to manually break a lot of connections and then make them again when you want to connect two modules together for modulation. So the end result is that it becomes just as inefficient as plugging cables in and out.

#4

I dont really understand what do you mean that it connects automatically, i never really noticed this?

#5

Every new module I insert needs to be fully configured

#6

I think what i mean is that the system can still work in the same way as now, just when connecting modules together it accepts the input automatically. For example if I connect SAMPLER to OUTPUT 1, it is very obvious that I want Output module to accept Input 1 and hence the destination module will accept a connection based on what you select in the module that is being connected to it.

#7

Could you write out an example showing how the system repatches for you please?

#8

I’ll post an example ASAP. Working on the sampler module at the moment :slight_smile:

2 Likes
#9

Well where I think it could get tricky is if I have the sampler connected to more than one out. What if I want something going on out on output 1, but on the other outputs I want something else? Might be a thin example, but i really like the system as is. It does seem like a lot of work, but it is also sort of just like patching with a cable.

You would plug your cable into the source jack, and then plug it into the destination jack on the other module.

Certainly could be room for some automatic situations, but I’m not sure what they would be. OMHO.

1 Like
#10

Yep your example makes sense.

#11

Hi @bert,

I’m trying to grok the example posted later in the thread and how it illustrates the rationale for requiring the end user to menu dive twice for every new patch connection but I’m coming up blank.

Maybe something obvious is flying right over my head, but nothing I’ve seen so far can explain why the UI doesn’t automatically enable an input on the destination module when the user sets the source module’s output to go to that input? If the destination input is already enabled for something else then couldn’t the UI just throw an error with *a message explaining which source module is already connected and maybe an option to override that connection or something? It just doesn’t make sense that users be forced to sift through a one-dimensional menu interface twice for each new patch they want to test out. Could be the systems engineer in me, but I lack the tenacity to repetitively act as a human implementation of grep -m1 foo. Even once is one too many times for me and twice just makes me shake my head. The menu interface could group things by fours or something to make it faster to drill in I suppose, but I’d settle for reducing this operation to one time per patch if that is even on the table.

So zooming out a bit, I was going to post this follow up sooner but decided to wait for the new update in case the behavior was changed. Since apparently nothing has changed in the UI with the latest update I hope the community can get some better understanding around the way it was designed and flesh out its limitations etc from the core dev team directly. Please correct me if I’m wrong but there doesn’t appear to be any indication that the core UI will change materially in the near future, and if that’s true then feedback directly from the core dev team on these areas would be incredibly helpful to me and I expect to the majority of other users who are looking at investing a lot more time and effort into using the SSP’s interface.

Thanks,