Slight delay GUI delay - PLY

[MOTOKO]

Bug description (state clearly and simply):

There is a slight delay in the GUI of the SSP. (lag?)

Steps to reproduce (use numbered list):
Slow response when the Move button is pressed.

The xyz points of the WTO have an afterimage like a lag.

Software version (blank if unknown):
29052022 (Superbooth 2022 beta ver.)

Type (major or minor):
minor

SSP’s latest update is excellent.
Thank you very much.

I haven’t looked at it much yet, but I’m posting it because there seems to be a minor bug.

[percussa forum] ssp's gui delay(lag)

+update_1

I found the cause. When the PLY module is added, the SSP works slowly. If I delete the PLY module, it works at normal speed again.

+update_2

There is a problem that lags even when long samples are put in the WTO module.

[thetechnobear]

yeah, I can see this with PLY (and have ideas why this may be the case) , not sure I see it with WTO.

with PLY, clear test case scenario is , clean patch, then add 4 PLY modules, dont need to be patched… latency builds with each one added.I actually find it most notable on browser.
interestingly, it seems only to happen when moving cursor using buttons, not encoders.

[MOTOKO]

Yes, I think you’re right. The PLY module seems to be consuming a lot of resources. Each additional PLY module added increased latency. The encoder looks fine, but if several PLY modules are added, the encoder also seems to have a delay time.

[thetechnobear]

I took a quick look at this… and from my understanding
the issue is a simple one , and it’s ‘by design’
so really, we have to accept this is a ‘heavy module’… kind of one instance thing

there are 2 aspects of PLY we need to understand.

a) PLY has to render all the time, not just when UI is shown
most modules only render their UI when the module’s UI is shown. this means it doesn’t matter how many modules you have, the UI load is constant ( = 1 module)
however, this is not true for PLY.
the audio waveform is derived from the 3d graphic model - so the model has to be rendered continually to generate the audio waveform. therefore we end up with a constant GPU load.
this is why we see PLY affecting UI performance even when it is not being ‘shown’.

b) PLY is using a lot of GPU resources
the 3d shader we are using is pretty intensive, so it’s using a lot of GPU resources.
so, whilst it not hitting the cpu hard, we are likely limited to one as we are ‘bound’ by the GPU.

interestingly, theoretically, we could use different shaders - so perhaps less expensive shader ‘programs’ might allow more instances of the module.
but with current shader we are limited to I think one, and it may introduce a small amount latency.

anyway, thats just my take, Ive also talked (briefly) with Bert, and I think this is also his view.
not saying there aren’t any optimisations that could be done, but I doubt it’ll change this really. (imo)

tl;dr;
I think really we can only expect to run one PLY, and it may have some small impacts on UI performance, but you get a lot from that one module. If we can get it to load alternative shaders, that’ll be even more interesting

this is specific to PLY … not a ‘limitation’ of the GPU usage!
usually UIs do NOT derive audio from their graphics, so usually we only render ONE module at a time, so you can get away with quite heavy GPU loads, since the loads done not build up with more instances.
e.g. if you look at the ENV module, its using GPU (as are all factory modules), and you can see it doesn’t matter how many ENV modules you have.
so this is just a side effect of creating a module whose audio is derived from graphics model.

[klausfre]

Another interesting idea is using the GPU for sound, I see that is coming to pc…

[thetechnobear]

I think most of the buzz around this is using GPU for off-loading DSP - rather than actually producing the sounds - as the actual sound, you probably want from an audio interface with decent codecs.

this is kind of happening with PLY… and is also why its introducing latency on the main UI

I doubt it’d be too relevant for something like the SSP,
it’s an appealing idea when you have massive monster GPU on your desktop, or even ore likely you would installed extras to be dedicated to the task. (you also can’t have eGPUs on something like the SSP)

as far as I can see, the only excitement, was due to the fact GPUs are have a pretty big market (gaming) so the hope was some of the (development we saw from that, could some how be utilised in the (much smaller) audio world.

but a lot of this buzz was before Apple Silicon, it seems kind of redundant…
Apple will just keep on increasing the number of cores as it has heat/energy (the big intel issue) under control. also apple has dedicated ‘accelerated functions’ like their dedicated Neural Engine.
so perhaps once day, Apple could create dedicated audio processors on board, similar to the likes of UAD.

I know not everyone is Apple, but the likes of AMD/Intel are going to have to respond to Apple… otherwise they are going to start loosing significant user base share. - so its only a matter of time till they follow suit.

[MOTOKO]

Thank you for your detailed explanation. For now, it would be right to use only one PLY module.

Anyway, I don’t know exactly what the GPU performance of SSP is, but I think the latest update has made it possible to use SSP more effectively. I’m looking forward to what other possibilities SSP will have in the future.

[BENDY]

There does seem to be some latency in the UI. Rename file and cursor over with buttons you can see it. And elsewhere.
&e

[thetechnobear]

the OP bug is excessive GPU load, caused by the PLY module.
unfortunately, this is a quirk of PLY (see above post, point (a) ), and theres not really a solution to it.

again, as per (a), it does not relate to if PLY is active or not.

for this bug (I’ll rename title to reflect) its therefore important to know if PLY is being used or not.
if not, then better to have a separate bug report, detailing offending modules.

e.g. Im not sure if other modules, particularly WTO, may see similar issues.
but it will be specific, as Ive had some quite large patches with no lag… so seems module dependent.