@Elezeid

Identified and fixed (sort of )

• Combo box with script swaps between factory and expansion content
• Combo box saves in preset
• Changing presets seems to re-trigger the combo box's value, even if it's the same as the previous preset, which initializes the expansion content and bumps the scroll window back to the top

Fix: Turn off "save in preset" for the combo box.

Voila! Bug gone. This is a slightly less than ideal way to browse content, as the user will have to manually swap content libraries via the combo box, but it is a small inconvenience when compared to the joy of browsing presets.

Hope this helps anyone else that runs into the issue in the future!

Hey all,

Ran into some minor issues with the preset browser after introducing expansions to the project.

1. Favorites have disappeared entirely. Even if you save a favorite, it doesn't persist if user switches between factory and expansion content. Expansion type is files only - just samples, samplemaps, and presets.

2. When browsing or choosing a preset, the browser jumps back to the top of the list in the rightmost column.

3. I had some "left and right" buttons to cycle through presets, but they now don't seem to work unless you press the button, choose a preset within the browser, and then press the button again.

Nothing here breaks the plugin and everything is still accessible, but it does hamper the UX a bit. Any advice would be greatly appreciated!

@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.