Thanks for asking this. After two years of initial development I thought now it is time to have a selection of people who use other samplers regularly check out this system in order to get it "peer reviewed" - reporting bugs and crashes, make performance benchmarks, give feedback about workflow annoyances or feature requests that they are missing at other samplers.

So by doing one of these things (which you already started) you are helping me to drive the development of this project up to the point where it can be distributed to a larger public.

About the financial support: This won't be an MIT licenced open source project but (similar to the JUCE model) a GPL framework with commercial licences available, combined with some closed source parts (I am thinking of making the HISE player closed source to allow stuff like encrypting patches and basic copy protection).

So in the long run, I expect this project to yield some income through licening fees, but in this development state, adding a donation button would neither speed up things (I am already putting every free minute into this project) nor would it lead to privileged feature requests. If a feature seems to be useful for the general application I will implement it as soon as its reasonable. But if you need a custom module for a unique use case or something like that, we can still talk about to some contract work for implementing this.

But I might reconsider the donation button once its actually published :)

@2l94v5ko:

What's the difference between buffer size and loading size, and what is the number unit type? kilobytes? What is the kontakt equivalent?

The streaming engine has two intermediate buffers for each voice which are periodically swapped (one is used for providing the sample data to the engine while the other fetches the data from the disk). The buffer size controls the size of those buffers and the loading size (aka Preload size) is the buffer which contains the start of the sample (until the first intermediate buffer is filled).

The units for all buffer sizes are samples so in order to calculate the actual memory amount you will need this formula:

memoryAmount = preloadSize * 4 * 2 * numSounds + streamingBufferSize * 4 * 2 * numVoices

4 because they are saved as float (4 bytes) and 2 because the stereo configuration is hardcoded for now (I will add multichannel stuff later, but this will be a rather heavy redesign).

Also it gets a little more complicated if you want to use sample start modulation (because then the whole area that can be modulated must be preloaded…
But you don't need to calculate this actually (the "Memory" label does that for you). So in order to keep the memory usage down, you could:

1. lower the Preload Size
2. lower the buffer size
3. decrease the voice amount (if you don't need full 64 voice polyphony)
4. Don't use sample start modulation (it is of course turned of by default).

1. and 2. come with the usual performance vs memory consumption tradeoff and 3 and 4 can be applied if the instrument design allows it.

BTW all these properties can also be changed via scripting, so you can add this to your instrument's setting page if you want.

@2l94v5ko:

What is the difference between voice amount and voice limit?

Voice amount is the actual amount of voices (you can see the impact on the memory label if you change this value. Voice limit is some kind of "soft clipper" for polyphony (so it starts killing voices if this value is reached, but the actual voice amount remains unchanged).

If the voice amount is reached, the old notes will be chopped off with no fade which will result in clicks. So you can use a little less value for Voice limit (eg. 62 for 64) to reserve two voice slots for the fade when killing voices.