maybe just renaming the function by "CC" learn than "midi" learn.
Most of time this function is used to control via CC (keyboard controllers has CC buttons and/or knob - as my UMX-610) but it's controlled via MIDI out/IN.
Yeah - sort of.... but no nice favourites processing and only two columns - as I said I could build my own and it would likely use a viewport or two, but then... see my first post here..
Yes, implementing a sleep functionality in a multithreaded environment is the worst. I have played around with this, but it involves stack unrolling and restoring the value of every local variable.
@d-healey Thanks! I was trying to figure out how to make that work, but not having much luck- haven't done any programming since a college course on Unity over three years ago now; more than a little rusty.
I thought of another use case for this. If I load in multiple instances of my plugin and I want to purge a mic position in all instances I have to go to each instance individually and click the purge button. If I could link all the instances together and just set the purge state on one it would be much faster.
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.
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.