Is there any way of someone creating a Convolution Module like the Mungo c1? As far as I’m aware it’s the only module that could do two live inputs convolving each other, audio rate modulation etc. BUT … it’s discontinued. Then I thought if any module has the capability to do it, surely the SSP. I have 0 knowledge of how but I’m sure there are a few people who could and may be interested in giving it a go. Perhaps it needs something different under the hood to pull off the same thing I don’t know but thought I would ask
1 Like
ECR1+ has 2 convolver cores, so can handle 4 ch audio (!)
you can feedback it on itself
the Rossum Assimil8or can also PM (phase modulate) which is very similar to convolution
but i agree the SSP is ideal for this
if only there was some development
I considered this a while back, and started playing with FFTs using (max) RNBO,
but I found the fft was a huge performance hit, to the point of not being practical.
even my simple fft patch, that just extracted the frequency and amplitude in 8 buckets, was very heavy in cpu.
for a convolution reverb,
you’d need to do this once for the IR, which is fine.
but you’d then need to do a FFT on the live input, which you then ‘mix’ with the IR fft.
then use IFFT to create the audio signal.
I suspect the main processing overhead is the fft of live input.
but, I fear to have a decent fidelity, you a larger fft than I used (512) for this test.
Im not sure if anyone has created a convolution reverb patch for rnbo, but may be worth looking into, as it trivial to then get that working on the SSP using my rnbo project.
even if it wasnt performant on the SSP (likely), it be a good way to initially model on a desktop and then find a more optimal solution.
its quite possible (no evidence either way) that the rnbo fft objects were not optimised, so there may well be better (low level) libraries would have better performance.
anyway, last time I looked I couldn’t really find an open source project that was doing something like this, so after disappointing initial experiments I dropped it.
note: I last looked at this a couple of years ago so everything has moved on - rnbo is much improved, and there no doubt are other projects and libraries around now.
1 Like
I didn’t actually realise that as I don’t think I’ve seen anyone use the ECR+ like that, so good to know. But is it quite doing the same thing as the c1? Same ballpark probably a bit more polished sounding I imagine and reverby rather than an actual process (if that makes any sense). I don’t think it’s quite actually doing sliding cross convolution. But interested in hearing what that sounds like on it.
About to get hold of an Assimil8or for the PM stuff as I am interested in this whole field. But the live Convolution seems really interesting and it would be great to see the SSP really shine in these kind of audio processing areas that it must be the only module capable of doing some of this stuff
1 Like
I’m really not a technical guy but could the c1 be using super small fixed ffts which may be less of a knock on CPU? And it sounded pretty decent to be honest. As surely the SSP can’t have less computing power than the c1? He must have optomised it really well. But completely excuse my ignorance, I’ve never made a plugin in my life.
It would be really cool to get some experimental max type audio processing patches in the SSP. That would really stand it apart even more than it already is. I didn’t realise the SFFT patch is already in the SSP, completetly missed that will have a look now!
1 Like
the answer is simply, I don’t know, what the technical specifications of the C1 or the EHR+ are - or how they are implemented, features etc.
(e.g. a quick looks shows the c1 is only 1 sec of IR which is pretty short, so that helps)
however, what I will say is, if you write a firmware that is specific to ONE function, you can do a lot of optimisation.
the SSP does have a few overheads e.g. its running (an optimised) linux, its also running the host that connects multiple modules together, as well as a lot of IO, and large screen to drive. midi implementation , usb audio interface.
all these ‘small things’ add up.
ofc, its easy to forget all these thing when we talk about adding a module, esp, as it may not need them, but they are still there, and ts these things that make the SSP so flexible.
also, when I said the FFT struggled, I meant to be useful within the context of SYNTHOR. i.e. what is the point of having a module withing synthor that uses 99% of the cpu !
ofc, with a dedicated module llike C1/EHR+ it can run at 99%, thats perfectly ok, thats all it needs to do 
anyway, not saying it cannot be done, as I said, it was a while since I last looked at it, but fft / convolution reverbs are certainly heavy on cpu, and so harder for multi function modules.
with the ECR+ you can have +10s of IRs (stereo!)
it sounds what you put into it + on top of that the IR of course
(which can be excellent, since you can apply 24bit 48Khz IR files of high quality to it)
-nothing the SSP could do too of course, it’s processor is still many times more powerful
Convolution reverb sounds interesting. (Because the fake spring reverb vst I made with an all-pass filter sounds way too fake, lol)
The book I have includes a basic convolution reverb Max patch and its explanation, so it might be worth trying to see if it can be replaced with rnbo.
2 Likes
Very good point, yes the one task per module definitely helps streamline CPU usage.
Having a play around on SFFT and getting some cool results!
Can you actually do it live or pseudo live on the ecr though that would be ideal? Sounds awesome either way. Just really interested in the idea of live convolution with 2 sources.
Im also exploring max and ircam land seeing what other weird and wonderful variations there are. Although my expertise for implementing them into a plugin is 0 
I run the exsample Max patch, from Electronic Music and Sound Design volume3, I intended to use as a reference, but whether it was due to excessive CPU load or not, the sound didn’t play smoothly at all on my a bit old laptop. So just converting this patch to RNBO and running it with SSP doesn’t seem like it will be easy.
unfortunately, I realised I only have vol 1 and 2 so can’t check this out.
I was looking for a simpler convolution reverb implementation, based on fft, to allow me to explore this further, but tI couldn’t find any - most just relied on other libraries
but yeah, Id not expect an example in a book to just work ™ , rather be a kicking off point.
overall, convolution reverbs are a pretty complex subject, and there are many different approaches, so implementations can vary a lot.
the issue is not just cpu load either, for a real time reverb, we also have the issue of latency introduced by using large block sizes. which is where we get into the practical necessity of using partitioned convolution, which basically are a mix of time based convolution and fft (partitioned = chop it into smaller blocks aka partitions), to reduce this delay.
so, this goes back to what I said before - about not knowing exactly what these other reverb modules are doing - there are many different approaches, and some are more performant (and quality cost!) than others, and the developers have to find thier ‘sweet spot’ for the hardware they have.
thats why I wanted to play with it in RNBO, not because I thought it would perform well on the SSP , but rather to have a model to try different approaches and combinations i.e. a kind of desktop prototype - as frankly, I dont have a very deep knowledge in this area, so need to experiment.
for actual implementation, there are quite a few ‘fast fft’ and other libraries, that could be used, once you know exactly what you are trying to implement.
(this is the approach, I suspect was taken with by mungo and tasty chips to get to their end result, to find the right compromise of quality and performance)
note: why is algo latency important? because usually you want to mix the real time / input signal with the reverb, so you have to delay both by the latency introduced by the block size. obviously we also get into the area of phasing issues, if you dont get this right.
I tried a few convolution reverb Max patches that use FFT without external—latency aside—but although the reverb itself works, every one of them introduces glitch‑like noise here and there already at the Max on PC.
Optimizing a convolution reverb patch seems pretty challenging for me and I’m not good in math.
So, I eventually gave up.
2 Likes
One of the Max convolution patches I tried is the patch here.
1 Like
yeah, this can happen for a variety of reasons…
if you were using multiple partitions, possibly you were not synchronising them correctly,
If I get time, I’ll see if I can come up with a simple example.
there are also some other tricks, like having a hybrid reverb.
so basically use convolution just for the early reflection, then switch to a conventional algo reverb for the tail.
this should use less cpu, as the expensive fft stuff is done on much smaller fftsize.
in theory you could do that algo reverb using the existing ssp reverb module,
though you might get some phasing issues.
but I guess, it be an easy start/test, and is a ‘modular’ approach 
1 Like
I was actually trying the exact same thing you mentioned (though it didn’t work very well with my skills, haha).
I experimented by connecting a very short convolution I made for early reflections in series with a reverb that uses RNBO exsample code to add the tail.
1 Like