Granular Engine
-
@vewilya my experiments in this seem to show you dont need anything down as low as 20 ms anyway - 50 ms is plenty....
-
Thanks guys for the infos. I’ll have to get my head around a couple of basics first before tackling this. But from what I hear you say it should be possible to do!
-
So I've been advancing my granular engine idea in the last couple of weeks... A lot of stuff still isn't working (timer is not behaving how I want it to for example... among many other things...), but it's progress. I started off with a first version but wasn't happy with it and felt like I needed to re-write it from the start to really get to grips with it... So I wrote the 2nd version. Lottie doesn't go along nicely with granular... I had to disable it completely in the 2nd iteration for now...
Updated version 2:
-
@UrsBollhalder
These sound great! What is the original sound source in these?
How are you handling voice stealing and voice count? I either run out of CPU headroom or get crackles from voice stealing trying to create a granular fx using timers as a midi effect.
-
@crd I am not entirely sure anymore, but I think the examples shown are using full library music tracks of mine as source material. I think the right source material is crucial for granular. But it's also trial and error lots of times. Stuff you think sounds awesome will just come out flat boring and other recordings that might not even be considered "good recordings" in terms of playing or quality etc. just sound awesome in such an engine. It's also a lot about tweaking the knobs I think and finding the sweet spots to create nice-sounding presets.
As for the CPU... I have never had a problem thus far with it! With just one engine running, without many fx, I am under 4%. But I have different itereations of it at the moment... so it can go up to 8% and voice count over 200... so... it varies greatly... Retrigger mode is normally on "do nothing"...
EDIT: Well. I just recognised the source material for the last example is some sound design recordings I made with various kitchenware and sea stuff like pans, knives, sand, bowls, seashells , etc.
-
@UrsBollhalder
Got it. Thanks for sharing.
I am working on something that could be used for pianos etc but am starting to think manipulating the onNoteOn isn't the right approach. How Hise's sampler's deal with voice stealing seems to cause crackling regardless of my sampler settings. Even extreme fade settings don't seem to sound any different. Two three notes work fine but over 4 notes always leads to glitches.
-
@crd Really? That’s interesting... I suppose you’ve been tweaking the AHDSR settings? No result?!
-
@UrsBollhalder
yeah. Maxing out the voice count makes it disappear but I get up to 800 voices real fast when I use multiple samplers. Here is a quicktime of what I am talking about. I'm not sure if I am missing something obvious. (The obvious thing may be this type of thing works in Kontakt but not Hise :)
-
@crd Hmm... I realized that my sustain level is all the way down... just using attack and decay mainly to control the envelope of the grains... Honestly, the fade time doesn't do much of a difference on my system here... I mainly use the AHDSR to shape the sound and also get rid of crackles. Also maybe also try using the attack curve to find the sweet spot... and yeah, the voice count does get pretty high sometimes when I crank up the attack and decay... But I am also not out of the woods yet with this, to be honest...
EDIT: Also I noticed that when using a timer object in my onInit Callback of the interface and playing the engine with my sampler module open, that resulted in some weird behaviour that I still can't quite explain... as soon as I closed the sampler module or switched to the main workspace that issue was gone. I now use a separate script processor for each sampler and also use the "regular" onTimer callback instead of creating a timer in the onInit.... that helped to get rid of the issue...
-
@UrsBollhalder
Changing the midi script from the top layer to per sampler helped a lot... I'm not sure why but everything is working much smoother now.
-
@crd That’s good news! Well, I made the same experience. Not sure why that is but I think that is in general more the way to go with HISE: More compartmentalised scripts doing their thing, instead of sticking everything in the interface script, including stuff that has absolutely nothing to do with the interface.
-
@UrsBollhalder this * 9000.
It requires a bit of a brain warp coming from KONTAKT where you have to cram everything into one gargantomanic code sausage but this is one of the main design principles in HISE that I wanted to do differently.
This being said, there‘s a granular synth available in scriptnode which you can modify (I wrote this as a real world use case for SNEX so if you want to change parameters, you can just copy the code and fiddle around with it inside a SNEX node), so abusing the (rather heavyweight) sampler module for these little grains might not be the smartest solution going forward).
-
@Christoph-Hart :astonished_face: That's some interesting news... Well... The cpu consumption is reasonably low but I definitely look into this! I'm a bit scared of scriptnode tbh. But I'll have to get into this eventually...
The problem with the scriptnode_codegen_rewrite branch is that it doesn't like loading my XML user presets (crashes almost every time) and that it sort of messes up all kinds of things (AHDSR Envelope, etc.) When switching to that branch would you generally recommend starting fresh with a project and set it up from scratch or shouldn't that make any difference?
EDIT: I love the look of it as well (codegen_rewrite)!! The new font for the script editor etc. is really nice and also the subtle changes to the UI in general I really like!
-
No, in the end this branch is supposed to be 100% compatible to existing projects so it doesn't matter which one you use, I just had to change so many things that it's inevitable that some things break (eg. the AHDSR module needed to be refactored so that I can use the DSP logic in a node that shares the code with the HISE modulator).
What would help tremendously is if you try to make minimal example patches that works on the scriptnode branch, but fails to load / crashes or sound different on the scriptnode codegen rewrite branch. I've created a issue on GitHub for this so that we keep that all in one place:
scriptnode codegen regression tests · Issue #187 · christophhart/HISE
This issue tries to collect all issues that occur when moving from the scriptnode branch to the scriptnode codegen rewrite branch (which is going to be the master branch for HISE 3 in the foreseeable future). If you notice a different be...
GitHub (github.com)
-
@Christoph-Hart Sure! Of course! I’ll have to take things apart a bit and isolate the issue and see if it persists. I’ll have a look later today...
Edit: At the moment it doesn't want to load any of my XML anymore... also the autosaves are crashing HISE...
-
@Christoph-Hart said in Granular Engine:
@UrsBollhalder this * 9000.
It requires a bit of a brain warp coming from KONTAKT where you have to cram everything into one gargantomanic code sausage but this is one of the main design principles in HISE that I wanted to do differently.
This being said, there‘s a granular synth available in scriptnode which you can modify (I wrote this as a real world use case for SNEX so if you want to change parameters, you can just copy the code and fiddle around with it inside a SNEX node), so abusing the (rather heavyweight) sampler module for these little grains might not be the smartest solution going forward).
How do I get the granulator node to do its thing? I can setup a mod chain with a sine to modulate the grain size f.e. but how to get it going through the audio file? I have it set to scriptnode synth or what it’s called not fx... midi input is there and an audio file is loaded as well...
-
This is a bit counterintuitive, but the granular node is not polyphonic so you need to use it in the monophonic slot.
Granular synthesis normally handles multiple notes by distributing the (fixed amount of) grains across all pressed notes. So if you press one, key, 100 grains will play the single note. If you press another key, 50 grains will play the first note and 50 grains will play the second note (in a random order of course).
However this means that you do not require a polyphonic system which contain a state for each voice.
So:
- put in in the FX slot
- put it into a
container.midichainnode (this will make it process the midi data which is disabled by default for effects) - use the
Positionparameter to scan the waveform.
-
@Christoph-Hart Ahh... Ok... I tried a bit today and was using it in the scriptnode synthesizer module... so midi was working already... But that note distribution that you are describing thing is interesting and will prevent it from blowing up the computer I guess... I'd love to have some control over the attack and release values of the grains, but for that I'd probably have to go down the rabbit hole a bit further...
Edit: Does GrainSize alter the chunk of audio that is being played and adjust the triggering (timer) accordingly? So it'll play more audio but less often?
-
I'd love to have some control over the attack and release values of the grains,
Yes I also thought about adding that. I prototyped the entire node in SNEX and there you could just change the attack and release time as some internal parameters (similar to fiddling around with Shadertoy stuff lol), but that's certainly a useful parameter to expose.
I'm currently working on multisample support for this (and the other file-based nodes) so you can drop sample maps and SFZ files in there.
-
Is this node in the scriptnode_codegen_rewrite build? I am not finding it in the current scriptnode version of Hise...
