Oh yes, its a good thing, sorry if I gave the impression otherwise. It's just, as Dave says, it's very very early in the life cycle of HISE to see this sort of request.
Dave and I (amongst others here I'm sure) are Freelance Developers for "that other Kplatform", and as Dave was nearly as early on HISE as me, and he's done A LOT more work here than any one else, I think he's right - too soon I'm afraid - I suggest you wait until he (or I or someone else), has released a product (or two) and ask again.
It contains a saw generator with a polyphonic filter modulated by a AHDSR and a script that toggles between the different filter types (currently you have to use magic numbers for this, but I might think of something to avoid this.
Not sure what you did to make the envelope not work though :)
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)...
Ah yes, this is a bit misleading. I mean monophonic in contrary to polyphonic (FLAC and all other codecs have to work with fully mixed and mastered songs, which isn't the case when just using samples).
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).