This is not so easy. Just looping a single cycle from a waveform will produce nasty harmonics because of discontinuities at the loop point (also noise will transform into harmonic content, because it's not "noise" anymore but a periodically looped waveform). Crossfading does help a bit but it washes up the actual harmonic content.
What you need to do is to resynthesises the spectrum by analysizing the audio data with FFT and rebuild it by adding harmonic sine waves with the calculated amplitude levels. I've done this a few years ago with an MaxMSP patch, but I can imagine there are some tools available today that do this for you.
I was thinking of going a level deeper and build the normalization directly into HLAC. Consider this example:
| 24bit |
0000 0000 0011 1111 1111 1111
| 16bit |
This would be a signal with a peak of -60dB (10 zeroes at the beginning * 6dB). On 24bit you have a S/N ratio of 14*6 = 84dB. However if you convert this signal to 16dB, you discard the last 8 bits and end up with a S/N with 36dB, which is the same sound that you'll get if you put a bit crusher on the sample and set it to 6bit.
Now what I am going to do is to "normalise" the signal in 6dB steps (which means to just move the bits to the left) before the conversion. In this example, it will move it like this:
It just uses the bits that are available (note how it only shifted by 8 bits not by 10). Now when we convert the sample to 16bit literally no information is lost (this will be the case for all samples that have a peak < 48dB).
This way you end up with the full 96dB dynamic range of 16bit independent of the volume of the sample and your library can be marketed using the following claim: True 96dB Dynamiczzz® powered by HLAC :)
The normalisation value (a simple 8bit unsigned char, in our case 8) will be stored in the metadata header of the HLAC file and will be inversely applied during decompression (which comes with no performance overhead because its just a simple bit shift). This leaves the Volume parameter in the sample map unaffected and requires no manual normalisation of the input signal (of course you can still use the normalisation feature in HISE)...
Alright, I've just pushed a change that enables the mouse buttons 4 + 5 to scroll through tabs of the code editor.
There are two modes:
By default, the mouse buttons scroll through the different callbacks (and external files) of a script editor. But:
If the code editor is in a tab container (like in the scripting workspace) AND the container has more than 1 tab , then pressing those buttons will scroll through the tabs. This allows you to jump between selected code locations and not having to iterate through all callbacks (it also retains the positions).
I had to hack around in the internal OS APIs to enable this so out of lazyness this feature is currently Windows only (but if someone heavily needs this on OSX, I'll add this).
Well I have a template file I use when I create buttons that has all the states labelled on separate layers so it's never an issue. The only time I do the 1- trick is when I'm getting graphics from someone else and it's not really a big deal for me. I would be handy to have a flip feature I guess but I don't think it's going to be a deal breaker for most people - especially if they're coming from a Kontakt background