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 It says this in the technical documentation

Construct a time and pitch stretcher object to run at the given sample rate, with the given number of channels

https://breakfastquay.com/rubberband/code-doc/classRubberBand_1_1RubberBandStretcher.html

Yeah sure, why not. I wonder why I didn't add it already (normally I add both getters and setters whenever I add a property).

I've just been doing some stuff with HISEs LFO, trying to imitate something I was doing in Kontakt previously. To get the same LFO response in Kontakt as I get in HISE I have to set Kontakt's LFO phase to 275, so it would be handy if I could adjust it in HISE to get it to match Kontakt.

@christoph-hart said in Sample editor spectrogram:

Might be worth it...

I think so :)

@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!!!

@christoph-hart fair enough

I have added a RebuildPoolFiles setting which makes sure that the cached files are cleaned before exporting. For bigger projects it does add some overhead to the compilation time so the pro-option is turning it off and knowing when to delete them manually :)

@christoph-hart wow! I was playing with STK on Faust and it rocks!!!

Ah, that's just the print function. If there are no digits, it will print an integer. If you need a certain amount of digits, use Engine.doubleToString():

Console.print(Engine.doubleToString(2.0, 2));

@aombk HISE is really great for making instruments, which is what it's designed for. It also has some limited capability (which I haven't explored) for making effects but it's not really the best platform for that as that isn't its main focus. You'd probably have more luck with something like Cabbage, although as far as I know that doesn't provide a node based GUI.

You could write your own C++ module for HISE which would probably be better than writing your own effect from scratch in JUCE because you'd be able to take advantage of the things that are already part of HISE, such as the routing system and existing effects. You could also incorporate your module into the HISE source so that others could benefit from it and build upon/off it.

@christoph-hart heheh I can't write anything on C++ :)

Noticed snippet fails. Load then reset manually delay time to 0ms on both left and right to hear some kind of Karplus Strong

@d-healey example found https://m.youtube.com/watch?v=AIzhYPBm6Cw

@d-healey It's all good :-p

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