setMultiGroupIndex vs. discrete Samplers
-
@tonewolf said in setMultiGroupIndex vs. discrete Samplers:
What are the benefits/drawbacks of using or not using separate Samplers, and at what point does it start to cause issues? What are some of the issues I should be aware of? I'm already at 8 separate Samplers, and the way I'm currently building things, I could easily see myself with 24 separate Samplers.
You can use as many as you want, just be mindful of the memory footprint. I'm unsure about the impact of the sampler itself as a class object, but each sampler also has a voice limit.
Setting the voice limit increases the memory usage, because the engine preallocates the memory for voice handling.
For each sampler you use, you should manage the voice count according to the maximum number of samples you expect to be playing there that still have an audible impact.
-
@aaronventure Thanks for this. So, all things being equal, is a Sampler just as RAM efficient as setMultiGroupIndex()? In other words, setMultiGroupIndex() would only be more efficient if I wasn't mindful of Sampler voice count?
I suppose my (perhaps misguided) concerns was because I came across a couple of posts here saying that with 32 Samplers the engine started to struggle. Perhaps that was only to do with not managing voice count?
-
@tonewolf setMultiGroupIndex tells the sampler which group can be examined for the event regarding whether to launch a voice or not. No sample in that note*velocity slot for that group = no voice.
The voice limit determines what's the maximum number of samples that a single sampler can play. It's set for each sampler individually.
If you have a 4 layer piano and want to have a maximum of 10 notes being played at the same time, the total voice count you're looking at is 40. If you have release samples in the same sampler, add that to the count as well. Or don't, if you consider that the releases only play after the key-down sample is killed.
Separate samplers will all use some RAM even if they're not playing, because you have to preallocate the memory for the voice limit. In a single sampler, if you're managing your events effectively, multiple sets of samples (releases, noises etc.) can make use of the sampler's voice capacity, as the limit needs to only be as high as the number of total samples that will ever be playing at the same time.
It really depends on the project, your requirement for the number of simultaneous samples playing, event logic complexity (whether it's easier to handle multiple scripts or do it all in one) etc.
Do some tests with sampler voice limits to see whether what you need results it massive RAM use differences when doing multiple samplers with smaller voice limits or fewer samplers with bigger voice limits.
@tonewolf said in setMultiGroupIndex vs. discrete Samplers:
I suppose my (perhaps misguided) concerns was because I came across a couple of posts here saying that with 32 Samplers the engine started to struggle. Perhaps that was only to do with not managing voice count?
I don't seem to recall seeing any mentions of struggles, just that it will be a bit crazy. And it will, if all are left at the 256 voice limit.
CPU usage will have some sort of say here as well, depending on the amount of MIDI processing each of the samplers does.
You can always try it out, compile the plugin and see the performance numbers for yourself. You can trace the CPU usage for each call over time with Perfetto. Check the docs, it's super easy to use and will give you a lot of data regarding your plugin's CPU performance.
-
@tonewolf said in setMultiGroupIndex vs. discrete Samplers:
I'm already at 8 separate Samplers, and the way I'm currently building things, I could easily see myself with 24 separate Samplers.
Why are you using 8 samplers?
To my mind, you only need to use a sampler when you want to play multiple instruments - ie; a drum kit, or multiple pianos at once.
For one piano with a ton of microphones and articulations, I would think one sampler with the right midi scripts is the best way to do it.
-
Yeah one sampler is probably the way I would go here.
Multiple samplers when you need to have different module chains for each set of samples.
-
Thanks for the feedback. In case you're wondering why I'm asking such newbie questions, for context: I do have a lot of experience in sampling and was behind the ns_kit7 drum sample library (if any of you remember that https://douglaswhates.com/work/ns_kit7). And then a few years back I recorded a vast piano sample library which has been on hiatus and mostly edited but as yet unmapped. Since then HISE has come on the scene and it will allow me to overcome some issues I was having with Kontakt (until this stage I have relied on HALion and latterly Kontakt with very my limited scripting ability). HISE has got me super-excited because I am adept at JS through web development work, so I'm finding the scripting in relatively straight-forward. But, having developed huge sample libraries in the past, I'm just making sure I'm not going to deep down the wrong rabbit hole!
So, yeah... this project I want to use HISE for is a super-detailed piano library with over 25,000 samples. It may not be necessary to use multiple Samplers. I'm still at the getting-used-to-HISE stage of things and very much leaning on this community of experts here (as well as your great videos @d.healey).
In a way, some of the articulations I am using are like separate instruments, even if they combine to create one sound. Without giving too much away at this stage, I have several different components which would be triggered on a note-on event, all with varying degrees of delay. The release samples, in particular, are pretty comprehensive. Any given note-off event would be selecting from potentially a dozen different release samples, all of which would have separate attack curves depending on a) note-on velocity, b) note length, and c) note number (pitch).
I'm just kind of improvising with HISE at this stage and getting a feel for it, but what I've been liking is having big groups of samples grouped into separate Samplers, as it's allowing an easy overview of what's going on. I find using the RR groups for layers a bit awkward.
Also, it is unclear to me at this stage whether different Groups (RR) within a Sampler can have different envelopes applied to them. It seems to be a thing which is applied to the whole Sampler module. Having stuff in separate Samplers, I'm liking the simplicity (from the developer's point of view) of inserting those attack envelopes and using velocity and note number to modulate them.
But, to repeat... I am very new to this, which is why perhaps some workflow and HISE logic is not completely intuitive to me yet.
-
For release samples you definitely want to use a separate sampler.
Groups are just for organising samples, they have no module chain of their own. If you need to apply different modulators/effects to different sets of samples then you need multiple samplers.
@tonewolf said in setMultiGroupIndex vs. discrete Samplers:
But, to repeat... I am very new to this,
I would start with a few simpler projects before diving into your big one. You'll probably save yourself some time in the long run.
Libre Wave - Freedom respecting instruments and effects
My Patreon - HISE tutorials
YouTube Channel - Public HISE tutorials -
I would start with a few simpler projects before diving into your big one. You'll probably save yourself some time in the long run.
^
I second this.
That is the route I have taken and it is paying off well. -
@d-healey said in setMultiGroupIndex vs. discrete Samplers:
For release samples you definitely want to use a separate sampler.
Groups are just for organising samples, they have no module chain of their own. If you need to apply different modulators/effects to different sets of samples then you need multiple samplers.
Yeah, this is what I suspected, but I wanted to make sure that I wasn't missing something obvious.
@tonewolf said in setMultiGroupIndex vs. discrete Samplers:
But, to repeat... I am very new to this,
I would start with a few simpler projects before diving into your big one. You'll probably save yourself some time in the long run.
Yes, I hear you. I suppose I am kind of doing that, building little components of the instrument for myself as I go along. And I do have these piano samples just sitting here to be messed around with :)
-
Yeah one sampler is probably the way I would go here.
Nope.
For release samples you definitely want to use a separate sampler.
Yup.
The rule of thumb is: Use a dedicated sampler as soon as you would start treating groups with a different logic. If the hammer releases should behave differently than the normal ones (eg. the normal ones need to adjust their gain depending on how long the note was played, while the hammer sounds are always at the same volume), then these things should go into a dedicated sampler.
8 Samplers is absolutely no problem and if you follow the advice of @aaronventure and set the voice limit of every instance to the absolute minimum that you can tolerate, then there is almost no overhead in memory footprint as compared to using one sampler.
-
@Christoph-Hart said in setMultiGroupIndex vs. discrete Samplers:
The rule of thumb is: Use a dedicated sampler as soon as you would start treating groups with a different logic. If the hammer releases should behave differently than the normal ones (eg. the normal ones need to adjust their gain depending on how long the note was played, while the hammer sounds are always at the same volume), then these things should go into a dedicated sampler.
To add context, it's because if you need different envelope, pitch, poly-fx behavior (as soon as the polyfx voicing bug and the event data ignoring 0 bugs get sorted) for different groups, you will have to turn most of your modulators and envelopes into scriptfx and manage things there, either in the script callbacks for voice start, directly in scriptnode, or both.
You're now playing Starcraft in HISE and are managing events on several fronts, none of which necessarily throw errors to tell you that you're being silly.
-
@Christoph-Hart said in setMultiGroupIndex vs. discrete Samplers:
Yeah one sampler is probably the way I would go here.
Nope.
For release samples you definitely want to use a separate sampler.
Yup.
The rule of thumb is: Use a dedicated sampler as soon as you would start treating groups with a different logic. If the hammer releases should behave differently than the normal ones (eg. the normal ones need to adjust their gain depending on how long the note was played, while the hammer sounds are always at the same volume), then these things should go into a dedicated sampler.
8 Samplers is absolutely no problem and if you follow the advice of @aaronventure and set the voice limit of every instance to the absolute minimum that you can tolerate, then there is almost no overhead in memory footprint as compared to using one sampler.
Thanks for the input Chris. Your rule of thumb is where I was intuitively heading, so good to have it endorsed.
