Multiple instruments, single project or multiple projects?
-
"(along with the functions for restoring synths as a whole)."
Could you tell me a bit more about this?Also I noticed an issue with the script I'd made, if you add a modulator to an envelope and then click the save button, then you remove the modulator and then hit load the saved modulator won't reappear until you add another modulator to the envelope. Playing around with this and changing the values in the modulator etc can also cause HISE to crash and close.
-
Just use
Synth.getChildSynth()
and call the export / restore methods on this object to restore whole sound generators (and even samplers with sample maps).Adding modulators programmatically is a bit difficult because it sometimes doesn't update the interface (if it's of any help, the compiled versions won't have this problem...)
I'll need to check this a bit more thoroughly. Can you reproduce a crash with certain steps or is it just random?
-
I made a quick video to demonstrate how to cause the crash using the script I posted yesterday. Also how do you post code here so it's on one line like you do? I use the ``` but it's always placed in a large box.
-
Thanks, I'll investigate.
You are posting XML snippets. If you post HiseSnippets (the ones you get using File -> Export -> Export as Web Snippet), you'll get a String without line breaks which fits nicely in one line...
-
Cool, I found another way to crash HISE :) this time I'm using restore and export on childSynths, basically whenever I make a change and hit save and load it crashes. Try adding a container and a sampler to the container and it crashes instantly without having to press any buttons even!
HiseSnippet 1184.3ocsV8+SabCE2GvM0KaTsNs+.73mBprzj1xV0XnUR.1xJDh5QQUpppy4NGN2dwNxmu.YH9mX+kt+C1d19tbWBWYDjVDBc980O989X6WeoHfljHjHmu7zoioHmux0eJWE0Ihv3nt6ibdn6wjDEUhshZOcLIIgFhbbV8W0Bb7VCY982+RaRLgGPKDgPmIXAziXiXpBo+wKeEKN9PRH8T1nRV+7W1MPv6HhEo.dV0sIZLI3Sjyo8HZyVwEMgQuHA4zz8YOsg7SsF7m603y9axYGz3iu3T8mnfTojxUmAtibbc9G3mi6AgLkP5qHJJDy0ZKBm5GItfaS8YrD1fXpdQKjOfIq3CEwg5Mu9aTmHVbX+7RXBBhR+hB5p1B525dLKjMSdQg8qMJvEdTtz5rxsAuV2S34TBdqYg2ib8CjrwpBMZr8MYR+LnypDsxe459jmzsWmidy9G3Wql96tmVqifqfpciDp52nryiT02t4l6nUi6Hov9ASvIvdC5r3wDNMdKbDKjhYpsvDdHNgLQu.y3XUDXhjBQpFPMRT3IDYtu80th2EmmNRXnQT8MJavFagaB+A4urTM1puwDaQDLYHINgVoMZvzk22fAvPkLkt3d47Xw.RLVL3iz.E.YhBeAPvwQPyvrClPhSoI3gBoYo.9GrKL0vjF0xbOMgJsoYehh.6qqt1lGepx3Vlc4UNRBjkvyoJa3mEcnTFR41BaCs+cGMVHUDt5m.8rDK13BENHVvoVDYf9V3AoJbRDQp2UR5PJbnIf9c2npblNg0mGv5hRQKZfhejfDNe2ocpRI302vnYVEs01P+oktAMm69ZRPktazLy8bmK4MOcjg5atHKABh4iFPop2bZpOWNClyk28dHj5RZcFrp4NXF9mWHvfrG+3MqcUMuRt9N16KmvByaOsKOjdYcFjzq080CeSuNm18jdlyMc16niZuWmW4WaXJOPwDbrf2SnnmvqaRA3yhZFNrJU5BlTDGSkUoUegq7VbqNrEGPkaY4TF6XCwYRw6t6bm81rlGn2CnXulNNlDPKSSyNMbASEYoX.UanTLxrPScxOW64cCluI463UyCJTKj+LhUVpuSMHOioKzjZ.4C1JTy8qKPkA0PSxCxtmmMyEjdMUqZXook2CXciTCts.ToWpO.aQ5+EvtFt6e9WNpc2d4HvdPqjgBdWNScxX5r0VBYtjlnYDwxhJHfkkZHdUXVgna9bEJ6vO7v0pYlCeoLOasd9yVZhHhEpmSoL2DY3PHmG3969mz6pqsAqbDdXVDrWqXBw5tktZJOBdeQ9rL2sPT55oJBwMe.FFCPDlFSTyOafd1pLEvIz4d8sqtpjvTSKO60RLvPyJGXnUUcf6HbejaelJHpZ7tRE3EZo+ei2rwuV28fgCgahJ.6ZtG9166rVKATdsHUw3meLQIYWBScBu83CC1FPAjvAFZhdRzUzrJ65l505JiOkG1LeL0LkszqcxT1JWIZDIPJ9PfkVpGv6AFI.l3lQl8fY2g03V4LQMtGASc9gf.cg36AjWsGOco83YKsGOeo8X6k1ieXo83GWZOdws3gdD+8RUhQ1iEHz+B3sqkq.
-
Alright, thanks. BTW, do you know how to run HISE in debug mode from within Visual Studio?
Just change the configuration to Debug in VS2015, compile and it should open a debug instance. If you get a crash there, it stops in the debugger and points to the line of code which causes the crash.
This information will vastly improve the efficiency of tracking down those bugs - not that there are any left :)
-
That's a good idea, I shall do it :)
-
Just tried building the debug 64bit and I got this fatal error:
"1>D:\HISE Development Builds\HISE-master\projects\standalone\JuceLibraryCode\hi_native_jit.cpp : fatal error C1128: number of sections exceeded object file format limit: compile with /bigobj"The regular standalone 64bit build worked fine though.
-
Ah yes, that one. Go to Project -> Properties (Alt+F7) -> C++ -> Command Line and add
/bigobj
in the
Additional Options box (which should be empty).This happens because the Debug version creates a bigger intermediate object file before linking it to the executable and your computer is maxed out on RAM for these steps.
-
With the code I posted a few days ago and the crash I described with the container and sampler the debugger breaks here:
Using the same code, adding a sampler, making changes, saving and restoring them using my scripted buttons crashes HISE at this point
I'm really not sure what I need to be looking for in VS it's been many years since I did any work in it and nothing on the scale of HISE so hopefully these images are of some use!
-
That's what I suspected, thanks for checking this. BTW, if you click on "Break" in the last picture, it should point you to the line (that would be interesting, because the second error is a bit more critical because it wants to read from an object that was already deleted (and even then, it should say
0x0000000005
and not0xFFFFFFFFF...
. :) -
Have you found a solution for this crash?
-
Nope not yet, I got caught up in writing a lossless audio compressor the last days :)
-
Oh that's even better :) how's it going?
-
It works well for decaying samples (with ~60% size which is equal to FLAC but the decompression is way faster because the algorithm is much simpler).
For sustain samples it's not that good though (80-90%) but maybe I can improve this.
For general audio files it's horrible - when compressing a mastered music track you still end up with 99% file size.
I'll devote a new blog entry to this once it's done where I'll explai how it works.
-
I am using three compression algorithms, each with different decoding / compression ratios:
- the "Block" algorithm is a simple bit depth compressor without any processing
- the "Delta" algorithm detects a cycle in the waveform and stores delta values until the cycle is invalidated
- the "Diff" algorithm uses 4x downsampling + bit depth reduction for the error signal (basically you take each 4th sample, draw a line between them and store the deviation of the second and third sample).
I made some more tests & first decoding benchmarks:
===================================================== FLAC ratio: 33.1% file size Block ratio: 74.2% file size Delta ratio: 66.8% file size Diff ratio: 57.3% file size ===================================================== PCM speed: 11842.3x realtime FLAC speed: 1705.3 x realtime Block speed: 10086.3 x realtime Delta speed: 8175.8 x realtime Diff speed: tba.
The performance limit is uncompressed PCM decoding, which works at about 12000x realtime speed. While offering a far better compression ratio, FLAC's decompression speed is far behind the others (14% of PCM speed). The Block algorithm comes pretty close (and in a streaming context it might surpass the uncompressed PCM performance because it has to load fewer bytes from the disk). I didn't implement the Diff decompressor yet, but I expect it to yield something like 6000 - 7000x realtime speed, which will be the bang for the buck algorithm.
Another speed advantage will come from using memory mapped files for this (the FLAC reader in JUCE doesn't support memory mapping).
This format will also be used for the preload buffers so it'll drop the RAM usage significantly (currently the preload buffers are stored as 32bit floats!)
-
This looks awesome! well done. The drop in RAM usage will be very welcome but what is the effect on CPU?
-
Well if you can decompress 8000 voices in realtime the CPU usage for each voice is 0,0125%
-
Is the compression tool part of HISE or is it a separate app?
-
It will be of course embedded into HISE but I am using the seperate tool for testing & tuning the algorithms until it gets to a stable state.