Hi, my granular keeps crashing every time I use it. Is this a common issue?
Iâve never had the Granular module crash. Need a few more details. What are you trying to do with it, etc.
what do you mean with crashing? do you mean that the sound starts to click as you adjust certain parameters, or do you mean that the software reboots (i.e. crashes) when you load a file or adjust a parameter?
the granular does not have âsafety featuresâ built in. Certain combinations of parameter values will blow up the sound. Itâs up to you to adjust the parameters to get the result you want. For example, if you trigger a lot of grains and have the max. nr of grains setting all the way up, then eventually you will cause clipping unless you adjust the level parameter.
If I did put safety features into the module, then you will have limitations on how you use the granular, and I preferred to give the user the maximum power and possibilities instead of making choices for the user.
If the module crashes when you load a file then post the file if you can, or at least tell me nr of channels, file size, format, sample rate and bit resolution.
The file that I load is not related. This happens with the files that were default on the ssp, and happen using many different ones. Attached is a video showing what happens.
Iâd suggest you first read how the granular module works, you can find a description of the parameters elsewhere in the forum. GrainCo is the grain coarse trigger frequency, which controls how many grains are being triggered. If you turn this up all the way then you will get so many grains triggering that the sound clips. You can limit the number of grains that can be triggered using the max nr of grains parameter.
I understand. Is there a number that you recommend to leave it at?
I does appear to go weird though, and the sound doesnât change after adjusting a ton of parameters and loading a new file?
No it locks and I have to turn off the case. But it seems like leave the max nr of grains low is preventing it from happening.
This can happen occasionally if you select way too many grains and/or increase the length. Once it happens I notice it tends to continue to clip for a short time, but if you lower the number of grains it should resolve relatively quickly. Iâve never had to reboot because of this. The good thing is that the fairly large amount of grains that the SSP allows (at least compared to every other hardware granular unit out there) gives the user a lot of headroom before you run into the ceiling.
Do you guys suggest a number not to go over to prevent the unit from overloading?
Also I love your videos on the 301. Are you still using it as much now that you have the percussa?
Thx!
Theyâre completely different - use them both lots.
Just got my SSP and this is happening to me too, but I notice that if I turn the number or length knob very slowly to the same parameter that caused the unit to freak out then it doesnât happen. It seems like quick movements cause it. So for example, moving the length know or number of grains knobs to parameter x quickly causes it to lock as shown in the video above. Moving it back and then slowly to the same parameter number doesnât make it lock even though the parameters are then set exactly as they were when it locked before.
In other words, it seems like itâs more related to rate of change of certain parameters rather than the absolute value. Is that known already? Makes it very difficult to use the grain knobs in any kind of live setting.
so the video shows a âlock upâ whilst loading a new file,
but you are talking about change to gr len or gr number changes.
so whats interesting is⌠the sound continues to play, this means that the SSP sound engine is still alive and well ⌠but that the UI has frozen.
Id hazard a guess the issue is a cpu overloadâŚ
( if you display the CPU meter you may see it rise, but will also suffer ui lock as well, so you might not)
so increasing the number of grains will significantly increase the cpu load, and length makes them laster long (so more in existence at one time)
so why the UI freeze? but sound continues?
because audio generation is at a much higher priority than the UI (as it should be, so we donât get glitches),
but at some point you can push it so high, that the UI thread will no longer get anytime to process the display or user actionsâŚ
why only happening when quick, and not locking with same values?
because the UI when it freezes is not showing the values used by the sound engine, i.e. the sound engine has got the new values - but the UI has frozen before its got a chance to be updated.
so youâre not really seeing a âtrue pictureâ âŚso when you turn quickly, you might have turned up a lot more grains that you thought.
unfortunately from experience, predicting this overload is quite tricky, because cpu load is dependent on so many things e.g. what else are you running at the same time as the granular?
the âeasyâ solution, is one users donât like ⌠you severely limit the parameters that can potentially cause overload⌠but thats a bit like saying a guitar amp can only be turned up to 5, just in case you are indoors and its too noisy!
possible solutions?
hmm⌠I guess what I would try is not rapidly increate max number of grain, rather figure out⌠in the context of your whole patch⌠what the max is that will work. possibly with the CPU meter running to help you.
how to deal with in a live setting?
perhaps use DCG or Macros as cv input, rather than using values on GRA directly.
you can then use attenuation, on these to ensure they stay in a âsafe rangeâ
not perfect, but perhaps workable?
1 Like
Itâs a hard lock up sometimes, meaning the unit stops responding at all, screen freezes, and just white noise comes out of the speakers. And it doesnât take super quick movements to do it - rather the opposite, it takes super slow movements to avoid it. This is happening on one of the factory granular presets. Is this normal or is it just mine that it so sensitive for some reason?
I totally get that overloads are problematic, similar problems can happen on the ER-301, but the handling is more graceful and doesnât freeze the unit and require a power down.
1 Like
which sample? perhaps i can try to duplicate it.
( I can also be logged into to ssp, to see whats going on with cpu load)
I canât remember if it was a factory sample or one I loaded myself, but Iâll try it tonight and let you know. I wonder if itâs related to the length of the sample itself, but thatâs just speculation.
1 Like
So I tried it with the preset called granular, using the elnatutel choir sample that came on the SD card. It happens with a high number of grains and grain length for sure, but also sometimes at other settings. I took this pic of the parameters when it had just crashed and was white noise, but it didnât completely freeze the unit, which it sometimes does. When I turned the grain duration from 191 to about 185, slowly, it suddenly popped back to normal. Then I could turn the grain duration back to 191 and it was fine. Perhaps itâs caused by crossing the zero boundary from 1 to 1000 grains? I canât figure out exactly what causes it but it seems to involve high grain duration and number.
so I had a bit more of a play with GRAâŚ
I could not get it to crash, but for sure at high GrDur/NrDur the sound breaks up, and I suspect this is CPU.
(certainly CPU meter is going high)
note: this was pretty much just one GRA (and a few LFOs) running, so im sure in more complex patches cpu overload will get more serious.
(as mentioned on another thread, Ive delete factory presets, so not sure what the above has going on in it, but I suspect reverbs and things)
BUT⌠then I started rather than testing it, and trying to break it, I started looking at it in a more âmusical contextâ i.e. how Iâd use granular - and then I found that I was not really hitting the limits, nor having sound issues.
so the thing we have to look at hear is what the parameters are doing âŚ
GrDur , changes the duration
GrCo+Fi, is frequency of grain trigs (come back to this 
)
NrGr, is max grains⌠itâs NOT the number of grains active.
so the faster you trigger grains, (grco) and the longer (dur) they are, the more grains you have 'activeâ
i.e. the more bits of sound the SSP is having to generateâŚ
NrGr is just there to put a cap on this, it IS the âsafetyâ valve, to stop you running out of processing power.
I typically use granular in one of two waysâŚ
a) lots of very tiny snippets of audio, very fast - at audio rate.
this creates a pitched effect.
b) a few grains, (often externally triggered) but of a longer duration
this when modulating start, and cause some lovely smearing sounds.
kind of based on the original sound.
usually I would not create huge number of long grains, because it becomes a kind of mess and noise, since there just so much âuncorrelatedâ grains going on.
also heres the thing⌠if you set the grain duration high and at audio rate generation, we can get feeling where the max number of grains is.
so it starts to make me wonder, why even expose NrGr to the user?
if you use a single GRA patch on its own⌠you could almost calculate the maximum allow given processing power.
the issue is in a modular environment like SSP, you might have many GRA, or other modules using up a lot of cpu⌠also the cpu load may not be constant e.g. I might be triggering grains based on midi or a sequencer.
so, they way I found myself using NrGr, was setting it as low as possible to still get the desired audio effect,
using it as a way to limit CPU load of this module.
anyway for me (and this is personal opinion only) , whilst I can see from a technical standpoint, perhaps the SSP/GRA could try to âprotectâ the user from using too much CPU (by it auto limiting NrGr),
in practice, once I started trying to sculpt sound with it, I didnât really have an issue with it.
I guess one could invoke the âguitar feedbackâ memeâŚ
engineers are encouraged to make things work as expected⌠but with musical instruments, sometimes its better for them to let the musician do unexpected things, let them go beyond what the engineer expected or designed, find the limits themselves - and let them come up with something new ⌠or break it
6 Likes
This is an incredibly helpful insight, and makes perfect sense now that youâve explained the NrGr paramater and what itâs actually doing. Thank you so much for this! Iâm enjoying the gra much more now.
1 Like