I think I'll do that then :)

Well another reason for the HISE Player :)

So welcome back :)

Swapping samplemaps is about as fast as purging / unpurging. However I would not try to load them directly from a note on callback, because the loading is asynchronous.

But if you select the sounds from the UI, you should get away without any noticable latency if you just swap a few samples.

I don't think they are still affiliated with Google, not since Chrome was released. - https://en.wikipedia.org/wiki/Mozilla_Corporation#Google

Actually it keeps a list of recent projects in the app data folder and I don't think the uninstaller removes these (the installer routines are still pretty simple). I didn't see that error for myself for years :)

Thanks for this great job!

Regards

A ballbark figure is that it takes about twice as much CPU than sample playback with a few modulators.

This is indeed also a bit too far away from what HISE is supposed to be (although it would be possible to enable MIDI output, chances are great there are a multitude of other things that need to be done in order to achieve this).

But there is another open source project based on JUCE which aims exactly at what you are trying to do:

http://ctrlr.org/

You can also design custom interfaces and control hardware with it. I didn't use it myself, so I can't guarantee it will work, but it seems legit.

Yep codeacademy looks brilliant so far, thanks Chris :)

This sounds very good.

You can always copy a module to the clipboard, delete it and paste it at a new place, but I want to add a more user friendly way (dragging or something like this) for a long time.

Probably yes (I'll have to change a few lines of code) but even then with decreased performance because there is no memory mapped file reading for those formats in JUCE and implementing it myself is very complicated and not on my priority list.

The Wavetable synthesiser is a module with hardcoded wavetables used for a virtual clarinet. Since they are chromatically samples, I just used linear interpolation (like the sampler).

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.