Just a quick question about the default granularlooper instrument in nebulae. I’ve noticed when using it it my live fx rig in a parallel fx loop some phasing issues due to some latency in Nebulae’s processing when passing thru the dry sound.
I checked in the a_granular_looper.instr file and found the following parameters:
nebconfigbegin
ksmps,64
-B,2048
-b,512
sr,48000
2048 and 512 look like buffer and block size. Could I try and reduce the values without risking to harm or block the module?
Hey @bmoussay, welcome to the forum and great question!
You can reduce the buffer and block size on Nebulae to reduce latency. However, at certain reductions Nebulae’s settings will begin to underrun and distort. Keep this in mind when adjusting these numbers!
Thanks for your reply! Would you advice to reduce rather buffer size or block size or both?
Anyway I’ll experiment and check what fits better.
For now I’m using an alternate version of the granular looper where in live input mode the dry signal is not present at the output (blend left= phase vocoder, blend right = grain sampler, center = silent). This fits my parallel FX setup. The only drawback is that the crossfade between either phasevoc or granular and silence (when turning the blend towards the middle) is a bit abrupt (it jumps suddenly from low volume to silence).
I’ll try with dry back and different buffer and block size, and if not convincing, I’ll try to figure out how to change the crossfade behavior.
In any case this module is really really fun to play live!!
For the benefit of others, reducing -B to 1024 and -b to 256 makes a huge improvement on real time latency and doesn’t seem to cause any glitches or underruns. Seems pretty stable.
I’d actually quite like an instrument which took out the granular engine and file playback and just focussed on live loop grabbing and mangling cause it’s by far the most performance centric element of Nebulae and it does it pretty much better than anything else I could find. Beyond my coding capabilities tho.
Hi, @dtnl actually I didn’t have time yet to test SR and buffer sizes.
The alt instrument I’m using (always record dry, no dry signal at the output, blend = crossfade between PV and Granular) can be dowloaded here:
When you open the instr file in a text editor it is quite easy to understand which part of the code does what, maybe your wanted functionalities would be too hard to achieve.
-b is the software buffer, whereas the -B is the hardware buffer.
According the doc, using a 64bit RPi, -B could be the half the size of -b as a minimum (two 32 bit floats in 64 bit buffer), but I would not set -B smaller than -b.
It will also show you a way to calculate optimal values. The result of the ‘sr/ksmps’ can be considered as ‘how many times will parameters be checked/applied’. This is 750 times per second. So every 1/750th second it will check knobs, apply slew etc etc. depending on the csound function used. Audio rate calculations are at 48000 times per second.
Like michael says, sounds can start to distort, but I also have tried ‘extreme values’ which would hang the module*. Don’t overdo it.
Because it digitally processes audio, there will always be delay compared to the unprocessed analogue signal. The shorter it gets, it will go from phasor like sound to flanger, but will never be ‘0’.
Cheers, Airell.
*) I was really pushing the Nebs hardware with 24 mincers, where the Granular instrument uses only 2 (stereo).