GUI woes and gripes

I should have said it before. This new amazing FW was clearly a huge undertaking, and has made the SSP more powerful and stable. I am very impressed with the effort and results. And so, out of love, I bring you my frustrations, in addition to other complaints posted elsewhere.

  1. So many abbreviations. I’ll just never remember every parameter or module name. And so many names are similar, it slows me down and makes me want to do something else.

  2. Module selector page. This would be better as a list than a grid. Maybe sorted by category. But certainly full names for each.

  3. Module selector page, Also, how to I back out of this page without selecting anything? Like if I pressed the knob accidentally, now I can screw up the whole patch with no undo. I hate it.

  4. Patching node inputs/ outputs. There has to be a better way. This chaotic endless list makes no sense to me, I’m just scrolling looking for: L out into 1 in, R out into 2 in. But first I have to scroll past every other possibility.

  5. Knobs and acceleration. Did this change? Seem the same. And I still am scrolling for days on some parameters. It occurred to me that the knobs themselves are the wrong physical shape for the kind of twiddling that the SSP requires. There is nothing satisfying about spinning a sharp edged aluminum knob 1000 times.

  6. Sampler tape wind effect. It’s just too loud and can make some really ugly sounds when I want to subtly adjust a start or length point. I’ll make a separate post with a video about it sometime. But this feature kills me.

  7. Sampler and granular start and length resolution. Turns out, 3 points of resolution is not nearly enough on most samples. How can we get more precision here?

  8. Waveform zoom. Click once zoom in, click again zoom out. But I’ll be turning this for days to get anything in-between. Dying here.

  9. Rename preset. The behavior is, turn the knob and the character changes to the previous characters value before advancing or retarding through the alphabet. It’s unintuitive and unconventional. Why are we reinventing this wheel? Can we please just have normal behavior here? My brain will never rewire to accept this.

That is probably enough for now.

3 Likes

I think this would be better in one post… as this is pretty much in the same vain as your other topic - here.
(Id merge if I was a moderator :slight_smile: )

I agree with the points (and many are not new to any of us), but again, a lot of dev effort implied to change, most do not have simple fixes (*) … but rather require substantial changes.

… again, id agree with them, but easy/low effort to make suggestions, takes lots more effort to actually do them.

(*) example, there need to be abbreviations for many things, simply because the UI is not that big.
in some places, you mention the text is to small , but then later you have issues with abbreviations.
… so you already are seeing the ‘trade off’ that has to be made.

(yes, I know there are solutions to this… but again, once you start down that road, you point to yet more dev effort - which is why I said, there are few simple fixes/low hanging fruit imho)

I don’t mind abbreviations generally, but when they are in all caps and made up of mostly the same letters, I get lost. Legibility does not necessarily mean BIGGER. I appreciate your points on this, and I understand. But at the end of the day, the gui has to be fast and informative. I’m certainly not advocating for going backwards, I appreciate the monumental improvements in this new version. But product developers have to keep in mind the needs of its user base. Look at other small displays on successful devices, Apple Watch, OP1, etc. They cram a shit ton of info into a small space.

2 Likes

yeah, I totally get that…I agree legibility is important.

I will say, with all respect to Bert.Apple have dedicated teams of specialists working on UI/UX, and then dedicated teams to implement their recommendations … (similarly TE spent alot of money in this area for the OP1).
thats just not the case for smaller / boutique products , where devs have to balance dev resources spent on UI/new features/bugs/performance improvements.

as I said, I agree, improving the UX is important esp. for a musical tool. (*)
question is… how can this be done without a huge dev effort/re-write of the UI?

but Im rambling, Ive could spend hours talking about UI/UX, and how Id approach things, and the complications - but it wont get us anywhere… except if I decide to really start a ‘new project’ in this area :wink:


(*) some might argue, its a tool … so has to just ‘not get in the way’,
however, id argue as a musical instrument, its much more than that… it has to be fun/inspiring to use.

but, thats even more dev effort ! but personally, Id take that over new features.
I do think music tech often focuses way too much on flexibility/features.

last year I bought a piano, just because if you just want to play - its often more satisfying that sitting down with a complex (hardware) synth - its focused on music, not on a bunch of other things.

1 Like

I agree with the module selector page, some list with full modules name and possibly categories would be great.

In some sense a bit like Push2 selection works.

1 Like

Agree on all your points! And I wanted to add another point to your list.

The sampler looks great, but it would be important to have access to the old way the sampler looked.

By that I mean a sample overview. Because as the sample view behaves right now, its not possible to see your entire sample. If you use 10 minute long samples, and you know them well… you want to scroll through the file to a certain point in the sample.

But this is almost impossible because the sample view is zoomed in, and there is no way to zoom out. You cant really tell where you are!

Also, it is irritating when you modulate start and stop of the sample. The window of your view then also just jumps around frantically, leaving you to guess where you are at.

So I wish there was a way to zoom out completely, and have an overview of the entire sample, like before the July update.

1 Like

I flagged this in a bug report, but there was no response from Bert so…

I still have my pervious system on an SD card so I can go back to the previous FW… but… eh…

&e

it’s a pity this is flagged as a non-issue and apparantly nothing in the pipeline to address (some) of our concerns - or is there ?

where?
(I don’t see or remember seeing any comment by Bert on bugs… or stating they were ‘non issues’?)

which? most of the points mentioned in this post are not bugs, rather feature requests.
(and many have not changed in this firmware release e.g. 1-7)

though for sure the waveform displays and the way they interact with start/end (and a few other things) have some new issues (as mentioned by Evoken, and also the posts you made in bugs

of course, Id like these fixed too…
but in fairness, Bert spent a lot of time on the last firmware update, it was a huge development effort.
so, Im not surprised IF he is taking a bit of a break from it for a while.

I’ve been taking a bit of break from development over the summer, to help recharge my batteries - get back a bit of enthusiasm/motivation. programmers are not machines… we also get tired, and also need new stimuli too :slight_smile:

where was this acknowledged ?
-quod erat demonstrandum

we don’t ask for a solution rightaway but a(ny) response would be nice