Multiple instruments, single project or multiple projects?
-
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
/bigobjin 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
0x0000000005and 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.
-
Alright, the crashs should be fixed (it was the same reason that caused the REAPER crash so it's two for one :)
-
Brilliant, I'll give it a try later today
-
Good news! The crash is fixed, not so good news, found a new bug :)
When using the last snippet I posted:
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.If I load this from clipboard and then add a container to the Master container, and then try and add a sampler (or any other sub-module) to the new container it doesn't do anything. If I then delete the container and click the save button on my script I get an error that the container I deleted can't be found.
-
Yes this is because scripts get recompiled if you add a sound generator, which interferes with the possibility of adding sound generators via scripting.
This is a rather annoying design flaw and I have to think about a clever solution (perhaps just removing the possibility to restore containers might be enough).
-
Would that affect the contents of containers too?
