Resurrecting this topic because normalisation is something I keep coming back to.

Here's my current problem. I have a sample recorded on three mics, when normalised the close mic gets boosted +38dB while the other two mics are only boosted by about +30dB (these are for ppp dynamic samples).

So if I bring my samples into HISE and merge the multi-mic I could drop the volume of each mic accordingly using a simple gain mod, not a problem for this simple example. However that is only one sample of one dynamic, when I look at a higher dynamic the close is boosted by +20, the decca +3, and the hall mics +9. So now dropping each mic overall no longer works. Even if I could control the volume of each mic for each zone it would take hours to get the volumes where they should be. :(

What about if I could put the volume boost into the sample meta data and HISE could read it and restore each sample to it's original volume?

@christoph-hart Yeah as long as the loop points it settles on are the same across all mics to avoid phasing/chorusing. The XFade also helps to hide the seams nicely. Is there a way to enable/disable looping via scripting? Or a way to limit the number of times the sample is looped?

@jackburns Yes

but saveUserPreset() write PRESET FILE at the root of the drive where the executable is running from...

This is of course complete bullshit and shouldn't happen. How the method works is that it creates a sibling file to the currently loaded user preset, but if nothing is loaded, then it does weird things like you described.

A temporary workaround until I find the time to fix this correctly is to make sure that a user preset is loaded before you call Engine.saveUserPreset()...

@christoph-hart
Thanks, It works perfectly in lastest Hise.

alt text

Yeah I just realized that would probably be pretty impractical with this large of a project

I've added this along with his friend isBypassed()...

@jadg
If you wan´t to know how "Expressive Clarinet" sounds like:

Expressive Clarinet

@christoph-hart Just the MIDI ones. I forgot about those console commands though, they are pretty useful!

@christoph-hart Well as it turns out I don't think in my particular use case I'm going be able to use this anyway (I've been experimenting with a slider pack) but I shall explain it anyway.

In my main GUI script I have a CC remapper, so the user can send CC1 to CC11 for example, and I use a table to allow them to adjust the curve/skew of the CC values. One table per CC (the instrument only uses about 5 CCs).

What I want to do though is defer the MIDI callbacks in my GUI script and decouple the MIDI parts, such as this CC remapper into a separate non-deferred script. I'd then use the GUI script to set the CC mapping up in this other script which will actually handle the redirection of the CC data but I'd need to be able to pass the table values across as well.

Will deferring this CC mapping stuff actually make a big efficiency difference?

Fixed now. There's no fallback yet (just deactivates the FFT Analyser), but at least it compiles.

I've added a method Engine.isControllerUsedByAutomation() which might come in handy for some other things too.

No, only when enabled is false

I don't think it's viable to add this to the streaming engine, since it's a very limited use case.

If you use a sample start mod value that is not too high, you might still get the RR effect you need without wasting too much memory.

For example, if you set the SampleStartMod value to 16384, you have almost half a second of different material, which might be enough to kill the machine gun effect.

Also, if you use HLAC, memory consumption will drop by 50% (because it uses 16bit for the preload buffers).

Yes that looks like what I'm after. Thank you!

Good idea!