I received an exciting message in my Inbox announcing a major software update and plug-in development for the SSP. I expect our forum members would have received the same message.
Just wanted to say a big Thank You to @bert and @thetechnobear for their continued support for the SSP platform.
If you need any beta-testing done before the release in June, I would be happy to participate.
also excited and available to beta test!
at least some exciting news on the table at last
Press release , I assume went out via email subscription for Percussa.
For those not subscribed, Matrix Synth ( and others) have reported link
I’m posting an update on what Ive been up to on ko-fi, and my development
https://forum.percussa.com/t/thetechnobears-vsts-development
Yep very excited with this! Thanks to Bert & co and the technobear! 
Official press release below. Hope to see you all there!
PERCUSSA UPDATES SSP EURORACK MODULE SOFTWARE, ADDING 3D GRAPHICS, NEW PLUGIN SDK, SCANNING OSCILLATOR MODULE AND MORE
May 2nd, 2022 (Los Angeles, CA) Percussa, makers of the Super Signal Processor (SSP) Eurorack module, are set to return to the SUPERBOOTH show in Berlin, May 12-14 2022, since the COVID-19 pandemic started, and are presenting a major software update for the Percussa SSP.
Percussa has been working on a software update for the SSP since its last participation in the show in 2019, featuring a complete graphics rewrite, leveraging the previously unused GPU processor on the SSP, for accelerated 2D and 3D graphics. Additionally, the SSP’s plugin SDK has been updated to enable plugin developers to use the GPU as well for 2D or 3D graphics via OpenGL(ES).
Graphics acceleration on the SSP and GPU support in the plugin SDK were stretch goals which were not reached during the succesfully funded Percussa SSP kickstarter campaign back in 2017. With this update, users will receive the features planned in these stretch goals, and the benefits of accelerated graphics and increased DSP power.
In addition to increased DSP power, audio processing optimizations, and accelerated graphics, the update features countless bug fixes and improved memory management, and comes with a new “3D wave scanning” oscillator, developed by Percussa, featuring GPU powered raytraced 3D graphics.
Since the last SUPERBOOTH show, Percussa has released several incremental updates and fixes for the SSP software, enabling 24-channel USB audio support, improving MIDI MPE support as well as improvements to the step sequencer, sampler and direct to disk recorder.
In addition to the new software update, open source developer and SSP power user @thetechnobear (Mark Harris) is releasing over 10 new plugins for the Percussa SSP, and will be demoing these daily at the Percussa SSP table at the SUPERBOOTH show. Mark has also started contributing recently to the main SSP application software, in addition to his plugin contributions, which include countless modules such as a performance mixer, matrix switchers and mixers, sample and hold modules, utility modules, and ports of open source modules such as Clouds, Rings and Plaits. More information about @thetechnobear’s work can be found at TheTechnobear's VSTs development. Including @thetechnobear’s plugins, the SSP now offers more than 50 modules in total.
The new software update is currently in BETA with the release version to be made publicly available by the end of June. The update will be available via the Percussa forum at https://forum.percussa.com/. Percussa has also opened up pre-orders for the next production batch of SSPs. The SSP can be ordered via your favourite eurorack dealer, or on Percussa’s website at https://www.percussa.com
How about a Jupiter in there with revolving rings … (joking) - looks good!
Moons of Jupiter will be sequencer Tracks 
🫣
This is obviously big and very welcome news, but to someone who has barely any understanding of DSP applications and GPU what does this actually mean in basic terms, does it mostly translate to having fancy graphics for modules and VST’s or will it be helpful for other applications within the SSP? I’m kinda imagining the modules to show more graphical details now so the reverb to look something like the orange haze showing the reverb tails on the N.I RC24
Would I be correct in thinking the “3D Wave scanning oscillator” might be something similar to the 4ms spherical wavetable navigator, it certainly
Really looking forward to what this will bring to the SSP and the future, great work.
@bert Are there plans to open up the beta to testers, or is is going to be a closed beta until release? I’d be happy to test if you need some additional testing resources.
k, so I can’t speak of when beta/release will be ultimately thats up to Bert
(and I cannot/will not speak for Bert)
but I can say at little about where we are at, as Ive had a couple of people ask…
at the moment we are very busy with preparing for Superbooth next week, then Bert/Celine will be travelling to Berlin, busy at show etc - so nothing is going to happen till after return from Berlin.
(this may also mean things are quiet here on the forum)
Beta/Public Release…
imho, really for the SSP, “Beta” is a tag to set expectations and how you use the release.
the SSP user base is not so large, that it warrants a limited roll out.
I don’t know if plan is to label it a beta or not.
Personally, I’d call it a beta if there were ‘known issues’ still be worked on or similar.
any how, really wont matter to users. I’d alway advise, keeping a backup of what you have when going to a new release of anything, so you can ‘rollback’ if you experience issues.
as for when, I think once superbooth is out of the way, then that’ll leave a bit of ‘headspace’ to determine whats left to done before release (or whatever kind)
of course, the fact it’ll be demo’d at SB, and Ive been using a dev version for many weeks now, shows we are ‘close’.
I should note, on this release, it will involve a new sdcard image…
not just copying across a new synthor binary. so you might want to have a separate sdcard for this, this’ll mean you can easily rollback.
before the pessimists jump down my throat - no Im not saying this is necessary, or its unstable, or you’ll need to rollback… this is just good practice!
it means 2 (related) things…
yes, OpenGL could be used in built-in modules, VSTs or indeed any other application running on the SSP. however, it should be noted, they would have to be coded to do so.
also, theres a few of points to note here…
a) nothing is a panacea 
openGL is suited to some things more than others… without going into to tech details, basically you have to ‘prepare work’ for the GPU on the CPU. and in some areas, that CPU load for prepping may be as high as doing the graphics work on the CPU! but in other areas, using OpenGL brings huge benefits.
b) its not magically on everything…
OpenGL requires specific coding. so Bert has updated all built-in modules to use OpenGL.
my VSTs however, are just rended onto a OpenGL context… so really are not using OpenGL.
I do not know at this time, if I want to convert them to openGL or not.
I suspect not, I’d prefer to spend time on supporting musical concepts than graphics.
Id use openGL only if/when I find a module that I think would be substantially better for it.
(also really goes back to (a) !)
c) dsp vs ui
like all music applications (on modern/multi core computers) , synthor does not run the UI on the same core as DSP - this is just normal ‘good dsp practice’. so freeing up time on the ‘ui core’ does not directly give more dsp space. however, Bert has done a lot of work in this area which does bring benefits to the cores processing dsp, and the UI does feel ‘smoother’.
overall, honestly, Ive not tried to quantify improvements…
frankly, it be tricky task… but my impression is its quite a bit better, sure the cpu meter shows things much lower
but amusingly, I noticed that the CPU load indicator really is very unreliable (always has been) … as its showing average load across multiple cores, which really isn’t very useful.
Ive talked to Bert about changing this to a better metric (% of available dsp time available)
but, of course, that’ll mean you cannot compare before/after … as it’ll be measuring something completely different !
of course, once its released, users will be able to see if they can patch more things than they could before… but this is of little interest to me… I patch things from scratch, so really don’t have old patches to compare to … or try to expand more… I just look at what works today, the past is irrelevant
sorry, I know , even with me trying not to be technical…that probably went a bit too techie…
but honestly, its more complex than ‘will it give me better graphics?’ 
Thanks for the explanation. I know enough about tech that (I think) I understand some basic like having a dedicated gpu can offload lower processing power by using that for graphics rather than the main processor. I was just fishing for what that might mean for the SSP as the original post was quite vague.
So basically we’re likely to end up with some nicer looking modules and that shouldn’t take much or any processing power away from what we have already. Like you say graphics aren’t really important in making music but I guess they will put a bit of a shine on the new UI. I’m guessing with the GPU and the multi core processors the SSP is quite capable of doing some fancy visual stuff.
Regarding the SD card is there a limit to the size of card we can use for the new SD card image?
Really looking forward to this release 
basically yes, though for many of the modules it doesn’t really make a lot of visual difference.
but some indeed look better, and others could perhaps be updated in the future.
similarly, synthor looks very similar… but there is the option to do more with it in the future.
completely depends on the developers interests…
as I said, Im personally don’t have that much in interest in this area…I’d prefer to make more, or spend the effort on more (musical) functionality on a module, or move on and create a new module.
the exception to this would be if I create a module that really would benefit from some more involved graphics to help user understand whats going on… but honestly, I think thats pretty rare.
in fact, Id go so far to say, Id probably only going to digging into this in depth, if I suddenly have the urge to do some 3d graphics, and then Id probably build some kind of visualiser… rather than try to fit it to a music module. but thats not really an itch I want to scratch at the moment.
the other thing to bare in mind is , the plugin’s UI take a disproportionate about of development time even in a basic form… so really extending that for many more days developments is just not that appealing to me.
this is however very personal, I quite like simple UIs for plugins even on a desktop e.g. I much prefer Vahalla’s plugins compared to some that have complex graphical UIs.
BUT I know some really love the more graphical ones.
so, its definitely got a role to play - and of course it also opens up opportunities for synthor for the future, or even running other apps on the SSP.
so really, my statements above, are just to make sure people dont think Im going to spend a whole bunch of effort on this for my plugins - that would be an invalid expectation
Would it be fair to say that the main benefit lies in not having to bother the CPU anymore with graphics duties - be it simple or complex - because the GPU takes care of it? This leaves more cpu cycles available for the audio processing part of any module / plugin. Therefore musicians would have a bit more headroom in the SSP for complex patches, number of plugins etc.
no, not really - thats why I have my detailed post above !
it is just not as simple as that, it depends on lots of factor , and trying to simplify like this just gives the wrong impression.
when using OpenGL , the cpu has to prepare OpenGL ‘commands’ which are then sent to the GPU to execute.
that cpu load in some cases might be more than just rendering the graphics directly via the cpu,
but in other cases, that cpu load is very small compared to the gpu processing.
it all depends on a lot of different factors.
also, as I stated above,
in audio apps with multi core architectures (like the SSP ) , you would usually use a single core for the UI/graphics, and other cores for DSP, this is good/normal practice.
however, we have to remember the OS is also competing for (cpu) resources, so if your UI ‘core’ is using less, it’s more likely to pick that, than your DSP cores… but thats a side-effect rather than direct - as of course, his would normally only happen when you are pretty low on resources anyway.
but again, this is an oversimplification (rather more an example, that the real world use-case), with this stuff the devil is in the detail!
so I personally (*) I see this as allowing more complex graphics to be possible (on the existing UI core). its also means the UI is smoother - and it has a few ‘knock on benefits’ to the DSP that are kind of side-effects.
however, Bert has made other changes optimisations/changes, that do mean the DSP cores are more effectively utilised, and not impacted by the UI as they were before.
It is these changes that will allow for more complex patches.
please bare in mind, when writing a press release… you don’t have the luxury of going into the details or using technical mumbo jumbo as I have… you have to simplify.
unfortunately, with complex technology… this can be to the point of ‘limited use’ (*) , you need to dig deeper to really understand whats going on, and so impacts/benefits.
(*) I should say the above is my opinion based on my experience with dsp.
(**) bit like at school, where when young, you are given a simple (and inaccurate) physics model, then later you are told the (much more complex) truth
Its hard to explain OS preemptive scheduling and why that could be disastrous for DSP
Is the GPU on the same chip as the CPUs? If Bert will start utilizing the GPU fro some modules how will that effect heat dissapation?
Yes, it’s an SoC , but have you seen the size of the heatsink on the SSP 
Really as discussed in other topics , the ssp is fine for cooling IF your rack is properly setup - you need to provide proper airflow. But indeed it’s something many overlook.
Anyway, I’ve been running for a while now, and for long periods of time and it’s does not seem to be running any warmer.
(Not sure kernel extensions are in place to check what’s it’s reporting but it feels like a non issue)
Thanks for making me feel young again! 
Appreciate that there is a lot more going on than how I tried to simplify things - and (appreciate) you taking the time once more to explain. I’ll be patient and await the reports/videos from SuperBooth and ultimately the new release.
