Decrease plugin initialization / load time

[LightandSound]

@gorangrooves Are the samplers preloaded with samples on initial load?

[d.healey]

This is one of the current limitations of HISE and an area where Kontakt is a little ahead. Group FX, modulators, and routing would be really helpful for situations like this.

Is it possible to at least display the interface while this is going on in the background?

There is no setting for this that I know of.

[Christoph Hart]

Group FX, modulators, and routing would be really helpful for situations like this.

Nah, that's just duplicating the existing structure. If you need to route a number of samples to a different modulator, FX chain or whatever, it's an own entity and deserves a dedicated module.

Also, using many samplers is not particularly bad, you just need to make sure that you limit the voice amount in each Sampler to the lowest possible amount, because that's where the Sampler module sucks up resources (the rest is pretty trivial). So eg. for a closed hi hat sampler a voice amount of 5 or 6 voices together with the Kill second voice mechanism should be fine.

If you leave the Sampler voice amount at its default level of 256 voices, then you'll have 50 * 256 voices = 12800 voices that need to be allocated. Each voice has two streaming buffer of 4096 samples and even with HLAC and just a single stereo mic, you're using 3.5GB of memory for one instance just for the internal streaming buffers (multiply this value for each mic position). And this does not include any preloaded samples or image resources, so I would say the 15 seconds loading time are your smallest problem :)

Try to go through every single sampler module and reduce the voice amount (and voice limit) to the very lowest number where you still don't hear notes being killed.

[d.healey]

@Christoph-Hart said in Decrease plugin initialization / load time:

Nah, that's just duplicating the existing structure. If you need to route a number of samples to a different modulator, FX chain or whatever, it's an own entity and deserves a dedicated module.

I think there is a need for some flexibility in the structure. For example it seems inefficient to have to use 1 sampler per articulation just to have independent envelope control for each articulation. If I have 10 articulations then that's 10 samplers, but if groups could have their own envelopes I'd only need one sampler. One workaround is to store the values of the envelope for articulation and restore them when the articulation is switched, but that doesn't work if you want to stack articulations. And envelopes is just one example of where group level control is useful.

[gorangrooves]

@LightandSound Yes, they are.

@Christoph-Hart Thanks, Christoph. I have lowered the samplers' total voices. I am going through them all over again to double-check and tweak. While I set the maximum number of voice to 6-10, depending on the instrument, I find that for retrigger, the most natural-sounding setting is "do nothing". This should not affect the loading speed/ memory, right?
I am a bit baffled by "amount" vs "soft limit" for voice settings. I am setting them to the same value.

I will create a duplicate plugin with no sample maps to be loaded, but with the same number of samplers to see how that affects the loading time.

Would it be the same to load a single sampler with a 12-voice limit as loading 2 samplers with a 6-voice limit?

Another thought I had: when compiling a plugin in ProJucer, there is an option for JUCE splash screen. If I were to enable this, would this splash screen pop up before my plugin is loaded? If that were the case, could I edit the JUCE popup into my own to display "Please wait. Plugin loading..."?

[gorangrooves]

I reduced the maximum number of voices to a minimum. The load time has been reduced to about 8sec, which is quite an improvement, but it is still long enough that it may spook users. Replacing JUCE splash screen would not achieve anything, since it is a small notice that comes up only once the plugin is fully loaded.
So, the only other solution I can think of is to load the interface without any samples and present a popup screen with "LOAD SAMPLES" button. I am going to test the plugin without any sample maps assigned to see what that does to the load time.

[gorangrooves]

@d-healey How would I go about loading the plugin with no sample maps, then clicking on the a button to recall them and load the samples?

One approach I am thinking of is saving a present of the currently loaded sample maps. Then, removing all sample maps and saving a preset. On plugin load, the default preset would be the one with no sample maps and user would have to click on a button to apply the preset with sample maps. Is this the best way to go about it?

[Lindon]

@gorangrooves said in Decrease plugin initialization / load time:

And there is also an advanced hi-hat with tip and edge, gradually going from tightly closed to completely open.

So "multiple samplers" isnt the way most instruments achieve this. Basically what you are saying (I think) is that each drum has multiple articulations - and most drum instruments use a single sampler with the articulation assigned to individual notes - you can still manage your note decay/velocity on a note by note basis if you wish - So in the end you only have as many samplers as you have "channels" in your mixer (usually 8 but 12 or 16 wouldn't be a problem..)

[Christoph Hart]

So in the end you only have as many samplers as you have "channels" in your mixer

Well if you have release samples, you would use another sampler but run them through the same channel as the sustain (or whatever) samples, wouldn't you?

But I get that it's pretty hard to make generic statements about how many Samplers to use for a particular project, but I can imagine that there's a possibility of using less than 50 samplers but achieve the same effect.

Would it be the same to load a single sampler with a 12-voice limit as loading 2 samplers with a 6-voice limit?

That's the real question here :) From a loading time perspective / memory consumption, it doesn't make a big difference whether you have 2x6 or 1x12 samplers, but if you use 12 samplers with one voice you get a worse performance than with 1 sampler.

Anyways, a good idea is to load a basic sample set at the beginning (maybe purge a few mic positions in the default state), because my guess is that it's the sample loading that takes so much time. That being said, 8 seconds is not super unreasonable for a VST with a high sample count.

[gorangrooves]

@Lindon I am aware that other drum samplers use a different note for each articulation. Just because others have done something in a particular way, it doesn't mean that is how it needs to be or that it is a good way to be. I find this to be a very impractical and messy way of doing this. I believe that what I designed is an improvement, an elegant, tidy, and logical solution. You could playback a groove, and use the mod wheel, set to cc4, to vary the openness of the hats. When you look at the piano roll, you don't see a mess of notes going all over the place, but just two notes with cc4 controller lane.

@Christoph-Hart Thank you. After further tweaking, the initial load time (the very first time the plugin is ever initiated) is around 11 sec, while every subsequent time (even after the DAW is restarted) is about 5sec. I am going to experiment with putting hats tip and edge on a single sampler for each articulation and see if I can achieve the same playback. I believe I should be able to and that will allow me to cut 12 samplers out.
If that cuts the load time to perhaps 3sec, I can forgo the initial loading of empty sample maps. Otherwise, that would be my solution.

I was wondering, is it possible to have the plugin load an empty set of sample maps (preset #1), wait 0.3sec, then automatically load the full set of samples (preset #2)? Basically, automate the step where a user would have to press the button to load the preset #2 while displaying "loading samples...".

[Lindon]

@gorangrooves said in Decrease plugin initialization / load time:

@Lindon I am aware that other drum samplers use a different note for each articulation. Just because others have done something in a particular way, it doesn't mean that is how it needs to be or that it is a good way to be. I find this to be a very impractical and messy way of doing this. I believe that what I designed is an improvement, an elegant, tidy, and logical solution. You could playback a groove, and use the mod wheel, set to cc4, to vary the openness of the hats. When you look at the piano roll, you don't see a mess of notes going all over the place, but just two notes with cc4 controller lane.

Err, you dont see that if you have note-2-articulation maps either. Its an internal re-mapping. I used it all the time in the DrumDrops plug-ins, where you can use a cc value to open/close the hi-hats too.

Message.setNoteNumber() - is your friend here.

But hey you may well have an elegant solution, but it seems to be an elegant solution with a loading issue. Just pointing out a way to do this that removes your problem - if its not for you then - sure please feel free to ignore what I say and work out your own solution.

[Christoph Hart]

Message.setNoteNumber() - is your friend here.

Message.setTransposeAmount is your real friend if you don‘t want to handle the note off manually :)

[Lindon]

@Christoph-Hart said in Decrease plugin initialization / load time:

Message.setNoteNumber() - is your friend here.

Message.setTransposeAmount is your real friend if you don‘t want to handle the note off manually :)

pwnd again...

[gorangrooves]

@Lindon If I understand correctly, for the end-user, the experience would be identical as what I have now, but things would just be laid out differently inside the plugin back-end?

[LightandSound]

@gorangrooves Probably possible with the timer callback, just stop the timer after you're done (regarding loading after a short interval)

[gorangrooves]

@LightandSound Thank you.

[Lindon]

@gorangrooves said in Decrease plugin initialization / load time:

@Lindon If I understand correctly, for the end-user, the experience would be identical as what I have now, but things would just be laid out differently inside the plugin back-end?

yes.

The user always presses (say) G3 to get Hi-Hat edge, and A3 to get Hi-Hat Bell, and how open or closed the hi-hat is set to depends upon a CC message (say CC 4) - so in your midi track you only ever see the articulation notes (G3 and A3) and a single CC track showing how open/closed the Hi-hat is.

In your Hi-Hat Sampler you have your Hi-Hat edge samples mapped say like this:

G4 = Hi-Hat Edge Closed
G#4 = Hi-Hat Edge 1/4 open
A4 = Hi-Hat Edge 1/2 open
A#4 = Hi-Hat Edge 3/4 open
B4 = Hi-Hat Edge open

When the Hi-Hat Sampler gets CC4 it uses the CC value to decide on the current open/closed note it should play if asked to, by looking it up in a table/array.

When the Hi-Hat sampler gets a G3 it Transposes it to the correct open/closed note to play.

Simple really - The added advantage here is that most of the players with Virtual Kits(Roland or Yamaha) we worked with at DrumDrops wanted to match the CC message to their "playing style" - so we let them edit the CC-to-open/closed table - it was a simple 127 x 127 table with marked off areas for each articulation

[gorangrooves]

@Lindon Thanks for the explanation! That's very clever.

I did some simple calculations to see if memory usage would be improved if I were to adopt such an approach. I created a new sampler and placed all samples from 12 samplers into it, setting the maximum number of voices to 5, just like the other samplers.

Results:
The 12 samplers utilize 26.71 MB of memory, while a single sampler with those same samples utilizes 23.44 MB. The saving is negligible 3.27 MB, so for the 24 samplers being converted to 2, would save me maybe 6 MB which wouldn't justify the structural change.
I guess this is a good thing, since using additional sampler results only in a slight memory increase while offering extra flexibility.

What I am now baffled by is why the total actual memory consumed by the loaded plugin is around 350 MB, while the total amount of memory used by the samplers' buffers is just under 150 MB. Where is this additional 200 MB going to and what for? Any clues @Christoph-Hart ?

[Christoph Hart]

Do you use filmstrip images?

[gorangrooves]

@Christoph-Hart I use 3: slider, meter and mute button. They are re-used many times throughout the interface.