Preset help

How do I load in new presets from the forum ??

Presets typically come as a zip-file attachment.
Download the zip-file to your computer.
Unzip the archive. This will extract the actual preset file(s).
A preset filename looks like nnn.pbp, where nnn is the preset number - anything from 000 to 199. The number is the location where the preset will appear once on the SSP.
Make sure the SSP is powered down and then remove the micro SD card to the left of the SSP’s display.
Insert the SD Card in your computer / card reader attached to it. Your computer will mount the SD Card, which will appear as a volume / disk on your system.
The SD Card holds all relevant files for the SSP, including a folder named Presets.
Copy the the file(s) you have just unzipped to the Presets folder on the SD Card. Make sure that you rename or make backups of the presets you want to keep before copying.
Safely eject the SD Card from your computer and stick it back in the SSP (mind the orientation!).
Feed power to your Eurorack and once booted up, the presets are now available on your SSP.

Make sure that you have the necessary Plug-ins installed too, as some Presets depend on them. Plug-ins are easy - there is one combined file from theTechnoBear. This follows the same process as above. Unzip-the downloaded file and copy the plug-ins ( files) to the plugins folder on the SD Card.

Hope this helps. Even if the above sounds a bit laborious, it is very straightforward in practice.
Good luck.

Thank you very much !!..Gregg

As I follow along with videos, the preset 8Vwto and OB 4i4 imparticular soung "nothing like the presets in the video. It is more like a bunch of noise…Please advise

It is like some sample rate problem but all is correct with sample rates , interface settings on the Dante network etc…

All the
FM sounds are perfect…fmgr9,fmb, etc

I have a short clip of OB4i4 recorded directly into Ableton with the percussa as audio interface
If there is a way to upload so you can hear

The Presets that come preloaded with the SSP were developed with different OS/Firmware versions. Some Presets survived updates better than others. In particular the 8VWTO has multiple versions, under different names in the collection. and halfway through the way oscillator pitch is calculated and applied has changed. Unfortunately it is a bit of trial and error which of the Presets still work correctly - most do however in some shape or form. I guess it is all to inspire you to build your own creations from scratch. I suggest to look at the structure and try to rebuild the ones that misbehave.
Before you start - please ensure you are on the latest OS/Firmware - see my post in response to your other thread - and spend some time reading the forum. There is a slot of useful information embedded here. Good luck.

Thank you so much for your insight.


Maybe an older topic and of lesser interest, but I have experienced the above problems with the presets, especially 8VWTO (after setting all the WTO’s to 440 Hz) and the garbled audio. I’ve reached out to @technobear. Consensus is that kind of preset is very CPU intensive, hence the issue. My issue disappears if I limit my plugins folder to no more than 2 (CLDS and QVCA for example).
I still don’t understand the direct relationship with the plugins folder having too many vst’s in it and the hit on the CPU that would justify such audio problems (besides the CPU meter doesn’t really drop after removing the plugins.
In conclusion, it is possible that if one wants to create CPU intensive patches, one might need to keep the plugins folder to a minimum, and have another OS version on an sd card with all of plugins if so wish.


The number of plugins in the plugins folder should not affect performance - and so far, I’ve not seen any evidence that this is the case. ( * )

the plugins should only affect performance if they are added to the current patch.

What I said in my reply to you was…
I think 8wvto is already at cpu limits ( ** ) , so probably doesn’t have the spare cpu capacity to add another module like clds … that’s not an issue with clds, just available resources.
What you can try to do is reduce the number of voices to regain some cpu, or if you want polyphony try replacing wto with plts which I believe may be more efficient.

(also, make sure you are running at 48k SR, using causes more cpu load, and will cause issues - I dont even support it on my plugins, as I think it really doesn’t buy us much, and potentially creates pain)

I’ll try to grab the 8wvto patch and see if I can replicate.
(honestly, I don’t hold out much hope, as Ive seen people having issues with 8wvto on its own…)

As I’ve mentioned elsewhere, really I don’t use the factory patches - I think the beauty of the ssp is the ability to quickly create your own patches to your own needs - this tends to conserve cpu since you only add what you need.

also… just like physical modular, Id say generally virtual modulars ( *** ) are not great for polyphonic patches - the issue is simply, you have to duplicate so much to every voice - 8 note polyphony is like running 8 synths constantly (not just when the voice is activate).
generally, when we write polyphonic synths in software, we are able to optimise the code so this is not the case - so can achive higher polyphony for much less cpu.
Im not saying its not possible ( **** ) - just trying to explain why you might be surprised that 8 voices take up so much cpu.

( * ) to be 100% as accurate here…
The plugins do get scanned and loaded at startup, which would take a small amount of memory - however they should then be dropped out of memory. At that stage they should also not be being rendered on the audio thread.

( ** ) if you are using large wavetables it would also be interesting to see if memory issues are starting to prevail. Swapping would create audio glitches.

( *** ) this is starting to change as many are introducing explicity polyphonic support, by having ‘polyphonic’ cables. (funny thing is Reaktor has had this for years!)

( **** ) we could on the ssp solve this in a similar way to others are in eurorack (eg. qubit chord)
we could create a module that essentially is a polyphonic synth voice in one module, this allows for the code optimisation, albeit by reducing flexibility.
question is really, how many are trying to use the ssp as a polyphonic synth?

btw: plts has a chord mode, I think its 3 (perhaps 4) voices, so you can see what I mean about how one module can produce multiple voices more effeciently than trying to do with multiple modules.

Not sure it is the same issue as yours or not, but I have an issue with 8vwto preset.

Turn on the power and do nothing.
There are noise and output connection is changing between 0 and 1 busier.

My CPU intensive patches also occur noise and connect issue, but not always.
I’m not sure, but it may hit the CPU limits at some times.

1 Like

I have followed your advice, double checking that yes things are running at 48k SR. I have removed a couple WTO’s in the patch; the problem persists. I also don’t have any plugins added in the patch.
In the end, I am not that attached to the patch itself. It started as a curiosity that the audio problem would occur when the only thing that would change, everything else being equal, is the amount of plugins in the folder. I am pretty sure it has nothing to do with yours in particular; it’s just that besides the Qvca, yours are the only plugins I have on the card. And since I love what you’ve done more than the presets, I have them on the card regardless and enjoy using them.
That being said, there is no denying that the audio garbles after I exceed 2 plugins in the folder. I will post audio/video later if I have time just for research/info purpose and see if there’s anyway to figure it out.
I will add that I am connected to the SSP via USB using an FA-08 as a controller; I will try other controllers to see if I get the same problem.

thanks for that @Handsonicsuki, thats actually really useful info.
I suspect that is symptomatic of the issue…and I can reproduce it here.

Ive had a look at what’s going on…
so adding plugins does use memory, which is to be expected.

however, we have 2GB to play with.
without plugins, with 8vwto running we are using 970mb

add all plugins, and we are up to about 1500mb, thats a huge jump , esp. as the (compiled) code for the vsts is about 64mb (!)

(ok, synthor is storing info about outputs etc, but thats still a huge jump)

this takes it to around 69% mem usage, and its reporting (after all other processes) about 200mb is still available. - so that is all a bit ‘concerning’… but not theoretically an issue.

so, why the audio issue?

what also seems to happen is the ALSA thread also jumps to using the 90% cpu, up from 75% cpu.
whats also bizarre is one of the dsp thread (dsp2) drops to 11% cpu, from its usual 35%

so whilst the overaly cpu usage appears not to have changed much - the alsa thread, and so will peak one core. (its quad core)
why is this happening? nwithout the code of synthor I can’t know…
it be some kind of priority inversion happening, but why?
It seems unlikely to be memory, but given no extra code runs if there is one VST or 100 in the plugin directory … it feels like its possible?!

@bert thoughts?

hmm, what to do?
well I cannot change or debug synthor.

what Id like to see if I can get some more info on is…
why is synthor consuming so much memory when loading plugins.
Ive a feeling its instantiating all plugins when it starts up (to scan them), and then keeps them around,
and whilst they are not rendered (and so consuming cpu), they are taking up memory.

so I need to check to see if there is any data allocation that is going on, that can be done later, or is for some reason not being cleared up.

that said… I generally only allocate data in my plugins when its rendered (prepareToPlay), so this should not be happening at startup.


there appears to be a cpu overload on the ALSA thread.
this might be related to memory consumed whilst loading vsts, rather than audio processing.
but it is not vst rendering code (which is not being called)

its will be exhibited on patches that are on the threshold of cpu usage (so not 8vwto specfic) , since the ‘bump’ in cpu usage on the alsa thread cannot be accomodated.

ok, added some debug code to one of my plugins…

I’m seeing my plugins get created and destroy twice when SYNTHOR starts up.
thats ok, and should not leave any residue memory,
(I just checked I leaked no memory between creation and deletion)

I can also see the the associated shared library is unloaded, and only loaded when an instance is created - so even the code is not actually residing in memory!

this means something is going on in the host code that is using a lot of memory (probably whilst scanning the plugins) and then not releasing it…
unfortunately, this is not something I can do anything about :frowning:

@Handsonicsuki I can confirm I get the same changing between 0 and 1 in Output if all the plugins are present, but that stops once I only have 3 plugins in the folder while the audio issue remains (though lessen).
@thetechnobear I am impressed once again at all your work and having actually zeroed in on what the problem could be even if nothing can be done about it.
And to what could perhaps be a silly suggestion: Would it make a difference (help) to go back to the old way with the VST module being in the module list of the SSP and then having to select the plugin?

1 Like

not an option really… nor desirable :slight_smile:

Ive had a quick message exchange with Bert, I believe he knows where the issue might be, for now it goes on the ‘issue list’

for now, if we have issues with patches that have heavy cpu (or perhaps memory intensive) then we know reducing the number of plugins in the plugin folder might help.

at least we know to watch out for this until we have a fix.

1 Like

I’m glad to know it’s common issue and will be on the issue list!
I had thought that issue was occurring my system only and was related to my module combination or power supply.

Me too, I was lamenting in my own corner, why this stuff only happens to me since nobody reported similar issues! :smile:

1 Like