Decrease plugin initialization / load time

[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.

[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.