Decrease plugin initialization / load time

[gorangrooves]

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

[Lindon]

@gorangrooves said in Decrease plugin initialization / load time:

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

No worries - and its not very clever - its a pretty standard approach I think.

What you shouldnt under estimate - is this user drawn curve for the CC values... every beta tester with an electronic kit wanted it..

[Christoph Hart]

@gorangrooves said in Decrease plugin initialization / load time:

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

Ah ok, because images are the number 1 memory killer.

350MB doesn't sound unreasonable though. Also you didn't take the actual preload buffers into account, that's a few kilobyte per sample, but it might add up with big sample sets. The streaming buffers are independent from the sample count.

[gorangrooves]

@Lindon said in Decrease plugin initialization / load time:

What you shouldnt under estimate - is this user drawn curve for the CC values... every beta tester with an electronic kit wanted it..

Is this because some hi-hat controllers are limited to CC4 value of 90, instead of 127, and user can't reach the full range?

If so, this is easily resolved by multiplying the vdrum's CC4 value output by 1.41. I've done that when using/ recording vdrums into Cubase. I use Cubase's midi modulator to achieve this and record the resulting values. That way, what gets recorded is what would get recorded if a vdrum module that supports full dynamic range had been used. I guess I could include something like this in the plugin settings.
I can see this being the only major reason to tweak the curve. I have 6 stages of hats articulations evenly spread across the dynamic range and considering how physically little electronic hi-hat controller has to travel to cross between the stages, I can't imagine someone needing to adjust those crossing points in the plugin. If you want more physical movement on the hi-hat controller to go from one articulation to the next, that is done by physically adjusting the controller.

[gorangrooves]

@Christoph-Hart I can't imagine the images are the ones taking up the memory. All up my images take 2.14MB (including the background). The ones that repeat are only 7kb in size. It must be the streaming buffer and pre-load buffer then.
Seems like I have the structure down to the bare bones, so the only way to provide better user experience will be to load an empty plugin, then recall a preset to load things, while displaying the loader.

[d.healey]

@gorangrooves

All up my images take 2.14MB (including the background).

All images are uncompressed to bitmap when they are loaded into memory, regardless of what compressed format you have saved them in.

Check the image pool to find out the bitmap size of your images.

[gorangrooves]

@d-healey Thanks, Dave! Yes, those sizes are a different story :)
Does an element that is re-used several times also get re-loaded several times in the memory? So, if a decompressed image is 4MB and there are 20 instances of it, does it end up taking 80MB of memory?

[Christoph Hart]

Nope, the images will get shared across plugin instances (but anything else won't).

[gorangrooves]

@Christoph-Hart Thank you. Good to know. So, the conclusion is that the sample-loading is the main resource-sucker :)

[gorangrooves]

@Christoph-Hart Is there a relatively simple way to defer the loading of samples on plugin initialization and just display the interface with the loading progress animation?

I saw this script of yours/ D Healey for progress bar:
https://github.com/davidhealey/HISE-Scripting-Framework/commit/dbdbb4b04c447043fe4df221e6ff080c1d3d4e26?diff=unified

It would be ideal if such a function were built into HISE.

[Lindon]

@gorangrooves said in Decrease plugin initialization / load time:

@Lindon said in Decrease plugin initialization / load time:

What you shouldnt under estimate - is this user drawn curve for the CC values... every beta tester with an electronic kit wanted it..

Is this because some hi-hat controllers are limited to CC4 value of 90, instead of 127, and user can't reach the full range?

No.

Its about playing style - how far the drummer lifts or presses their foot on the controller(Hi-Hat pedal in this case) and the sound they want to hear when they do that, remember drummers can adjust the height of the upper hat on the stem - to get a specific set of articulations based upon the range they want to use for their foot pressure - you are going to need to account for this. We did it by allowing the drummer to define a remapping of the incoming CC numbers: CC4 - or any other - so they would get the articulation they wanted when they wanted whilst not changing their playing style.

[gorangrooves]

@Lindon Yes, something to keep in mind for sure. I won't introduce it at first, but it is something I will look into adding for future updates (along with a few other things I have in mind) if there is enough interest.