Decrease plugin initialization / load time

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

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