Am I the problem, or is the SSP?

[DSPaddict]

I’ve been less than enthusiastic about the SSP lately. I’ve had the pleasure of playing with mine for about 6 months now. In the beginning, the UI was different, and a bit of a pain, but I committed to trying to learn it and watch (and rewatch) the MAATHS videos and anything resembling a tutorial I could find.

But the issue is I don’t seem to get any better at using or navigating the UI, it just feels… bad.

I have only an hour or so a day to sit in front of my modular and what starts as creativity and excitement quickly gets bogged down in frustration over the UI, followed by precious patching time spent searching (for the 12th time) how to do a function.

I’ve gone through a similar learning curve with every module I’ve loved; ER-301, Teletype, Vector
five12, Disting EX. It’s confusing at first, you buckle down, learn it until its muscle memory and then frustration gives way to creativity and freedom. but I haven’t hit that with the SSP (yet?) it continues to break me down each time I want to use it.

So my question(s) is how long (if ever) did it take others to hit a point of understanding with the SSP?
Should I just keep pushing and hope it ‘clicks’ or should I accept that maybe the SSP is just not for me and move on? I WANT to love it, but it’s beginning to feel a bit like an abusive relationship.

Bonus question: How difficult would it be to redo the UI for the SSP? Honestly, if the controls could be even slightly intuitive (or even if functions could be labeled in a way that makes sense) I think that would solve 90% of my problems with this beautiful module.

[FuzzedOut]

It’s taking me a long time to get to grips with the SSP too. I’m similar to you in I only get a limited time with mine, I’ve just sat down and it’s 10pm.
I personally think that it’s just a complex module with lots of features and I fully expected it to take a long time for me to learn it.
UI wise it can seem a bit clunky or confusing for certain tasks like the way modules are connected but I can’t really think of any other way to improve that without adding something like a touch screen where you could just physically connect each module, but again I’m not sure if that would help much really. So I think it’s just a case of getting really familiar with the UI by spending more time using it.
There are a few things that catch me out every time though like the recorder channel + button going down through the channels rather than up which doesn’t seem logical to me and it gets me every time! There’s a few other things like that but overall I’m still having fun learning with it. I’ve actually just bought a 4ms pod for mine and a headphone module so I can comfortably sit and use it on its own a bit easier.

[Handsonicsuki]

In my case, it is less than a month for meeting requirement of the minimum necessary understanding of SSP that I need.

Maybe it is because I have clear direction how I use SSP for and base module setting is common in all my preset.
Digital patching UI on SSP is still not so comfortable for me. But once I made my base template with taking a long time, I just modify a base template little bit for my needs.

[thetechnobear]

@DSPaddict

So my question(s) is how long (if ever) did it take others to hit a point of understanding with the SSP?

I suspect this very much depends on how much you use it… and how…

its a deep module, so like others it pays to really sit down and use it regularly, and initially try to use every single module.

i think if you have a ‘casual’ use of it, where you pick it up every now and then and load up a few preset and modify them a little - I think it will take a very long time to learn.

on the other hand, if you always develop patches from scratch - and try different things - I think you can learn pretty quickly. (albeit, it may be a little frustrating intially… as lots to learn)

but, of course, that requires a time investment, and also the motivation - which of course can vary from one person to another… e.g. if the you have a huge eurorack, with lots of modules - perhaps its hard to focus on the SSP - whereas, if you have a small rack, and its very important part of it … then you’re likely to spend more time with it.

so Id not ‘beat yourself up’ about it, its quite natural for it to be different for different users.

Personally, I think the concepts are very straightforward, once you have done a few patches - it becomes quick and pretty natural… and its easy to see when you ‘forget’ something (e.g. opening an input) - the scopes are vital for this.
More ‘difficult’ is knowing which modules to use, and how, and when and for what.
There is no getting around the fact, that a ‘virtual modular’ is more deliberate than patching physical modules - so that means knowing whats available…

I guess the other side is experimentation - on one hand, I often think deliberately about a patch I want to create and figure out how to do it, but if I hit stumbling blocks or limitations - I let that deflect me into doing some slightly , or very different.
I think this helps since it stops frustration setting in, when you cannot seem to quite do what you want to do.

In other words, it becomes more ‘What can I do with the modules/feature I have?’ - rather than, 'why can’t I … ?"

Should I just keep pushing and hope it ‘clicks’ or should I accept that maybe the SSP is just not for me and move on? I WANT to love it, but it’s beginning to feel a bit like an abusive relationship.

Only you know if you have invested the amount of effort you are willing to invest.

The questions I ask myself in these situations is simple…
when I got the module what did I want to DO with it? is this possible? if not why not?
is there another use that makes it worthwhile?
what do I use if for?

at the end of the day, it doesn’t matter what the ‘dream’ was, of what it would achieve,
that dream always has to turn into a reality.

but again… easier said than done

Bonus question: How difficult would it be to redo the UI for the SSP? Honestly, if the controls could be even slightly intuitive (or even if functions could be labeled in a way that makes sense) I think that would solve 90% of my problems with this beautiful module.

anything is possible…
as the code is not open source, the factory modules and main UI (network/recorder) cannot be change by anyone other than percussa - so its a matter of talking to them.

generally coding is often not about ‘difficulty’ , assuming you have skilled programmers, rather its about time and resources - at the end of the day, coders need to eat and drink too

as I said, I dont personally find any issues with the main UI - though for sure there are some quirks with different modules.

some of that though is down to ‘history’ e.g. different users requesting different features, and trying to accomadate everyone - that can be pretty tricky. its also difficult to ‘fix’, since it may involve breaking peoples patches (which some users will be fine with, others not so much)

---

anyway, the above is very personal - and I recognise, Ive likely a different take than others.

as I mentioned on my video on how I use the SSP, I try to use it in a pretty ‘adhoc’ way - partly because I want to retain that ‘modular’ feel, of starting from scratch.

btw: Ive still got a ton to learn, and experiment with on the SSP.
I really want to sort out my samples on the SSP, form a kind of sample library. also I want to improve the workflow I have with the SSP and thinks like the QuBit Nebulae/Octatrack
… and I really need to dig into the using it more for complex fx… which was my original goal for the SSP when I bought it.

[wavejockey]

i too find some choices made in the (UI of the) SSP counter-productive :
the encoders make it hard to dial in fine values
the encoders make it hard to dial to specific values or to go from one side of the spectrum to the other (‘keep on turning’)
a lot of patching needs to be done, not always logical (from a proven and tried audio setup/studio perspective)
-once you know the drill, you get there anyway
a lot of turning the encoders needs to be done when you want to assign / connect destinations / sources, especially if you have multiple modules in your grid
-in this respect some wins can be found since the encoders are the main instrument / UI
some wins can be found in modules as not all slots are occupied with (direct) assigns to the knobs
there’s some (more) logic needed when working with stereo sources and modules (reverb, delay, granulator) and patching/connecting them in/out as this is not totally transparant

[postsolarpunk]

At 28:30 ish in the first of the 5 MATTHS videos, he’s connecting the sampler to the output.

1. Navigate to SAM, then do the button+select OUT module combo to enable connections
2. Two large lists of IO then appear with a lot of text to scroll through
3. Red box selection box around the left list “SAM: Pitch 1 [0]”
4. Enable Out1:OUT In1 and Out1:OUT In2

To me a complete a newbie, that looks like a connection of the Pitch CV of channel 0 on the Sampler being sent to the Input1 and Input2 CV jacks if I’m reading the lists from left to right. Obviously I’d need to RTFM because the left list is the “available SAM input jacks” on the selected module, and the right list is the “available SAM to OTHER output connections” where it’s “SAM Out1” to “OUT module input name: In1” and “SAM Out1” to “OUT module input name: In2”.

My gut reaction is “available outputs signals on the left for highlighted module” patching into “list of available input jacks destinations for modules that have enabled connection on the right”. Like if I’m patching a modular I think: I need sequencer gate out to go to ENV trigger input, which would be “scroll to the sequencer, click the gate output box, drag it to the ENV input on the right.” Then after an hour of patching, to check where the sequencer gate out is going, I’d go to the sequencer, scroll down the outputs on the left, and then all the enabled connections would be highlighted on the right. That would give me an easy list of “where are all the places this thing is going to”. This would condense the Out to In info to one place instead of scrolling between two modules to verify if connections were enabled or not. This would sacrifice the In-from-Out data management for the selected module because we only have two lists. Maybe a button could be included that would swap between (signal sources, Input jacks of highlighted module) and (output signals highlighted module, input jacks of connection-enabled modules). Dunno.

Just throwing out ideas! <3 I am new here, downloading software… massive UI changes to the patching network 2-3 years after release seems time consuming, hard, and would annoy long time users who have already learned how to use this thing lol

[thetechnobear]

I agree, I think the most time consuming (and error prone) part of patching, is scrolling thru output destinations.
this becomes really problematic when you connect to a few modules esp. if they have lots of inputs.

I still strongly believe it should only list inputs that have been opened… this would greatly reduce the number of inputs in that list.

of course, I recognise this forces the workflow of open input -> connect output to input.
rather that the current method which allows you to connect, and then go open the input.
but I feel thats a worthwhile trade-off, esp. since with the current method its very easy to make the connection, and then forget to go open the input…

i coud imagine other tweaks here, but that one seems easy - and would have a huge impact on patching quicker.

another similar option would be filtering by selected…
the UI already allows you to kind of select two modules (to allow you to connect them), I could see this metaphor being extended to let you ‘focus in’ on these two modules showing you just the inputs and outptus releveant to those modules.
… though, that has to be done very carefully, as I can see that also be pretty confusing for many users.

I do agree with @wavejockey about values - really there should be coarse/fine and defaulting for all values - I think my vsts show that this can be done quite nicely with the push encoders.
its not perfect, but with what we have, I think it works well… also is relatively easy to retrofit.
(unlike adding buttons combos, since often all buttons are already in use)

so sure, theres lots of possible improvements - thats the nature of software

but, for sure, none of these are showstoppers for me… they dont prevent me patching, or lessen my enjoyment …

whats tricky, and something Ive also faced, is deciding how much time to spend on polish, and how much in adding features - its a fine balance, and different users have different opinions.
theres always a call for more features, more functionality, more modules - yet, at some point, its also really nice to have limited functionality that just works really smoothly.

and for sure, as developers we all learn, and develop our ideas as we go forward - thats why I recently decided to re-write all my plugins… to gain consistency, and longer term gains.
but, my code base is much smaller (and younger) than Percussa’s , so considerably easier/quicker

so no easy answers…

---

but back to the OP, whilst I can say there are other modules I would like (or other features on existing modules) - there is nothing really that prevents me using/enjoying what is already there.

[wavejockey]

@thetechnobear

I still strongly believe it should only list inputs that have been opened… this would greatly reduce the number of inputs in that list.

what are those ?

are those inputs connected?

[thetechnobear]

to connect an output to an input, is a 3 step process

i) connect the two modules togther
ii) open/enable the cv input , you wish to connect TO
iii) connect the output to the cv input

e.g. to connect midi pitch to oscillator its
connect MIDI to OSC
open/enable OSC pitch
connect MIDI : pitch to OSC : ptich

the issue is step 3…
when you go to MIDI outputs it lists every OSC input, regardless if its enabled or not - so you have to scroll thru them all… for some modules there are alot of inputs.
now if you also connect that MIDI object to a WTO and say GRA, you have all inputs for all 3 modules… which can become a very long list to scroll thru.

imagine, now it would only list (in the output connection list) those inputs that were enabled/open.
even if you have 3 or 4 open per module , you’d still have a very short list.

as i said, it also means you are less likely to make a mistake…
if you forget to open up pitch on OSC, it won’t show… so you go open it up.

a more subtle variant of this ‘mistake’ is connecting to the wrong thing…
the number of times, Ive connected to the wrong instance of an input e.g GATE 2 instead of GATE 1
if it filtered to only open/enabled inputs - then this is much less likely - partly because of less inputs listed (so easier to read), and partly bcause you only enable GATE 2 if you are using it…otherwise its not even listed.

also a designer, I feel we have the disadvantage of two workflows as its is currently…
a) show all inputs
currently, all inputs are shown - so generally, we shoud not need to enable the input - the SSP could enable it automatically when its connected , in this case, I can see it makes the user have one less step…
but we currently also are forced to enable it manually it as well. ( * see below )

b) filtering
one advantage of the ssp having you enable inputs, is it knows which of potentially lots of inputs you actually plan to use… so in this case, use this to help drive the UI.

---

(*) why we cannot allow automatic ‘enabling’ of inputs
the above really is a ‘theoretical’ argument, since there is an ‘advanced’ use-case, where we can use the disabled inputs to differentiate between different instances of a module type. this is actually pretty powerful.
however, its easy to argue, that the fix to that is to have the SSP do connections based on slot location and NOT module type - this is probably a larger change but I think mid-term is pretty important one.
… but for now, this imho, prevents automatic enabling of inputs.

[postsolarpunk]

I was going to mention some sort of automatic enabling of I/O, no clue how / if should do that. In hardware everything is “enabled” all the time. If you need the control of “enable output send” and “enable input receive” it’d be something like audio mixer of all the signals into a manual mute switch to turn the signal on and off. It’s nice to have that functionality on all the connections on SSP.

Could subfolders help here? Instead of flattening all the i/o to a single list to scroll through, could you group by “sample” or “gate” folders, then “channel 1-8” folders, then “pitch, length, etc.” Would you think that would help or hinder?

[wavejockey]

that was initially thought about, but was dismissed since it would require more screen estate (and more moving around)

[thetechnobear]

grouping would create more navigation, so would make patching slower imo.

Enabling has to be done - due to dsp processing, you need extra processing/memory per input that’s enabled - as I said auto-enable cannot be done in current design - as it would break a very important use-case.
Also - it would prevent filtering that i mentioned above.

That’s the thing about software design, we often have competing requirements - things that work well in some use-cases perform badly in others.

Anyway this seems to have turned into a wishlist.

Going back to OP,

I personally don’t see any of these points really making patching difficult…. And I patch everything from scratch, so walk thru this all the time.

For me, the framework works fine - I mainly see areas where I want new modules, or modules that I wished to worked differently- but these are all things I can do by creating new vsts.

That said, if I ever got tired of the framework, I could create an entire new UI, and utilize my vsts as modules

Always options !

[wavejockey]

going back to OP: it is not only the patching that hinders working like a breeze, cause that can be studied, and is rather logical
the encoder handling (code) can benefit from an upgrade
the preset management (inside and outside ; manage multiple modules, copying/re-organizing presets) can do better
last but not least, i would like to see some modules have an upgrade (sampler, recorder)

[DSPaddict]

I appreciate everyone taking the time to respond!
I’m going to give the SSP another 6 months, try to spend some more quality time with it. I’ll keep you posted if I finally click with the interface.

[thetechnobear]

what is it that you are not ‘clicking’ with?
what is it that you want to do with it, that you find yourself unable to do?

understandly, alot of posts on forums (generally, not just here) focus on issues / problems / enhancements - as users are seeking solutions.
(I totally include myself, often I mostly talk about tech and what it can/can’t do…)

but for me, the drawback, is I see little about what users are actually doing with the SSP today…
I think that makes it difficult for new users, its such an open platform , that there are few examples of where to take it - what works easily, what is more difficult to achieve…

Personally, I think this is the difficulty in starting out with the SSP - and not so much the mechanics of creating patches. (iirc, I think MATTS video showed this pretty well)

[DSPaddict]

There isn’t anything I want to do that it can’t do (theoretically)
It’s just not a pleasure to do it. I think the point I was trying to make in the original post was that I want to love this module, it’s very powerful but it hurts my soul to use the interface.
That’s not necessarily the fault of the module either, I get that Bert designed it a particular way, that way just doesn’t jive (currently) with how my brain works, but it obviously works for other users such as yourself.

The ‘Click’ I’m looking for, that I found with other similarly complex modules, is when the interface makes rational sense to me and the frustration of navigating the UI to make something gives way to the unimpeded pleasure of just being able to make it.

[thetechnobear]

well I wouldn’t keep something that ‘hurt my soul’

as I said in my first post…

with anything new, it takes a certain amount of time to build up ‘muscle memory’, which make things quick - thats an investment of time.

for sure, some things need more than others.
e.g. some absolutely adore the Elektron Octatrack, and get immense pleasure from it - even with its (many) quirks. but others find it the most frustrating instrument on the planet and cannot derive joy from it.

and the advice is similar there…
try to use it regularly for what you want/need it to do, expect a learning curve.

BUT at some point, if you feel you have put as much time as you are willing, and its still not working for you then move on. (only you can say, when you have ‘had enough’, as its different for us all)

we are all (wonderfully) different, and music making is very personal , we have different motivation, amounts of time (to invest) - so different instruments will suit different musicians.

[BENDY]

@thetechnobear

on the other hand, if you always develop patches from scratch - and try different things - I think you can learn pretty quickly. (albeit, it may be a little frustrating intially… as lots to learn)

This is the best advice really, start from scratch and it will become second nature (or close to it). Also, don’t expect it to be Macintosh friendly, like ever. There is a science and a soul to the SSP, embrace it. Or sell it.

[FuzzedOut]

Would agree with this. First thing I did was erase all presets on mine after going through them. I actually have to make some presents now I think. I’ve just been starting from a blank set up each time I use the SSP to try and get me learning from the very basics up.

[Riggar]

Useful discussion and I must admit on occasion I’ve been tearing my hair out struggling with the Percussa. Slowly (very slowly) it begins to click and I move up an incremental step but sometimes that’s lost if I move away from the Percussa for a period and lose that incremental step and then need to re-think again. This is all about time investment which is picked up a fair bit in this thread.

But I’m going to stick with it and the reason is - I understand the power the Percussa has is vast (hey thetechnobear says he’s still learning!) and managing all that it offers with 4 encoders and 18 buttons - well just consider if Percussa was realised in a hardware form! Massive.

But I have a recent strategy - hinted here several times - the old KISS principle (Keep it simple stupid). Make up a second micro card for only your presets. Build (from scratch) small presets and re-build them often - in this way you go through the process of taking an idea (see a simple-ish idea below) - creating it via Percussa’s interface - and then operating it - again via Percussa’s interface - and so learning and relearning. We can’t all build a mega 8 voice macro synth with many complex modulations in 20 minutes. Then build on the simple presets you’ve created by adding little bits and pieces; a delay, a reverb, duplicate to get stereo, LFO modulation, CV input modulation, external control whatever - not all at the same time!. KISS remember.

My first preset build is what’s known as the good old ‘basic patch’ i.e.

Input (e.g. MIDI) to VCO to Filter to VCA to Output
With Envelope Generators to the Filter and VCA
If you build that about 20 times it does begin to make a bit of sense.

So huge potential, perhaps overwhelming at first, quirky-ish mechanics (probably necessary), start simple and build slowly - there’s no rush, well at least not in my book.