Got it thanks....

Thanks so much for the detailed explanation and it is much appreciated.

Encrypting of the samples would not yield any security but would increase the CPU usage by at least 200% for all your users.

People could still run your plugin through something like SampleRobot to get the „raw“ samples anyway.

@staiff -- plus adding yet another extension makes the .htaccess regex even more nightmarish....

@Christoph-Hart said in More Error Logging with .hr1 Extraction Utility:

subclass from HlacArchiver::Listener and you'll get verbose logging info

Awesome!! Thanks!

@dustbro What do you mean by that?

Yes if your material is 16bit from the start, you won‘t get any benefits from using Full dynamics. Just disable it at exporting and the end user will not have this option.

Oh and the .hrx compression / decompression is 100% bit equal, the Full Dynamics is something baked into HLAC directly.

@christoph-hart ok Good info and thanks!

@christoph-hart said in Feature Request - Monolith/File System:

The samples are protected and the end user won't have to move them around individually. I can even remember that some people wanted to delete a few unused .ch1 files of a library on hard drives where space is tight.

So True!!!

@danial You shouldn't need to change any paths for the SDKs, just put them in the tools/SDK folder and it should already be setup in JUCE. I believe ASIO is only required for Windows but unless you only plan on providing your plugins for Mac users you will need it. You need an account with Intel to get the IPP. I use a burner email and it's a very quick process. IPP is needed to improve the performance of all the FFT effects but most of them will still work with out it, just less efficiently.

@midiculous That's a lot of sample maps! How many samples?

A better question is that how can Hise have the same Build and Version number, yet have completely different results? I figured we would build the latest and greatest this week to make sure all bugs were gone and the new version actually lost the feature that the May build had correct.

I don't think the MultiMic concept is suitable for your use case as you can't use different LFOs/ modulators on different mic channels. The idea behind this is exactly to prevent having multiple LFOs and envelopes when you only need one. There are more limitations (the loop points must be equal) etc. so it's really only usable for multi-mic configurations (hence the name).

Just use multiple samplers, the overhead of having multiple instances should not be a big problem (or in your special case use multiple JUCE synthesisers which load the streaming sampler sounds).

You might want to experiment with the SynthesiserGroup module which basically allows to coallescate multiple samplers on the voice level which allows stuff like having one envelope for all AHDSR. But after all since you want to go full C++ anyway, you can just hardcode this structure and get the exact signal flow you want.

Yes, this is possible, but highly complex and subject of many proprietary algorithms. The problem is to resynthesise the samples without loosing the sonic quality.

Yep I was talking about the old REASON-defined plugin format.But VSTs - should (as Christoph alludes) work out of the box... But Propellerheads...tsk tsk...

FYI, I've just pushed a change that allows unisono voices (until now voices with the same notenumber were killed).

Just call Synth.setShouldKillRetriggeredNotes(false) on the synth you want to enable unisono.