@d-healey Thanks David, unfortunately this is indeed the only occurrence.

Am I really the first to run into this issue? If so, that definitely suggests user error of some kind, but I really don't know where I might have gone wrong!

@d-healey Yes. When this line is commented out, the issue is gone.

@dannytaurus Yes. I used ctrl+F to make sure.

@Chazrox there aren't any other functions like that tied to the combo box, the script is copied line for line from one of David Healey's tutorials. It's possible that it's become outdated?

I'll try unchecking "save in preset" but it's sort of an integral component of my presets, so if that does fix it, then I'll be in some trouble haha.

@d-healey Dang, I thought there was gonna be an alternative

Thanks anyway. I'll check back periodically hoping that someone has a solution or workaround.

@d-healey

Yes. Is there a better way?

Hey folks, I have a handful of IRs linked to a ComboBox, and I'm using:

const irs = Engine.loadAudioFilesIntoPool();

It works fine, however in the DAW if you stop the playhead and restart the track, or close the plugin window (with plugin still running) and reopen it, it seems to load those audio files, which are already loaded, thus doubling the amount of RAM in use by those files. Over time, this becomes a huge memory issue, and projects become unusable. It's saved in the plugin state, so closing and reopening the DAW doesn't solve the issue, assuming you are running the same project file.

Issue persists in Cubase, Reaper, and FL Studio.

I couldn't find a solution for this, but I thought something like

Engine.purgeAudioFilesFromPool(); above it might do the trick, so it purges before loading.

Unfortunately no such thing seems to exist.

Does anyone have a potential fix, or alternative for this? Thanks in advance.

@aaronventure This is great advice. I've actually been using git to backup my project after every session, but I'm fairly new to using it so I didn't realize I could revert to a previous version.

Thanks for pointing this out (and for the other user who mentioned this). I appreciate the guidance!

This is a bit frustrating, considering it looks like many hours of work must now be redone.

I have meticulously set loop points for over 400 individual samples. I set the loop points first in an audio editor, but HISE only really recognized embedded loop points about 20% of the time, thus I had to manually enter the loop points (a second time) into the samplemaps by hand. One sample per sample map. Every single one of them was rigorously tested for quality and accuracy.

I converted the samplemaps all to HLAC monolith, and every single one of the loop points has been offset by anywhere from 1, to 5000 samples. Now I'm seemingly forced to jump in and manually set all of these loop points again, but I'm not certain I trust that they'll remain.

This is a major setback. Is there anything I can do here? Are there any quirks of how HISE handles samples that I should be aware of so that I can avoid this happening again?

Thanks in advance for any guidance.