Additional project settings (as available in ProJucer) and defer samples loading until the interface is displayed

[gorangrooves]

Hey @Christoph-Hart ,

I am always having to abort HISE exporter so that I can open the autogenerated project in ProJucer and set the additional parameters which are missing in HISE project settings. I have a couple of requests, which I am wondering if you could please implement.

1. Could you please add the following:

• Company email
• VST/ VST3 options (select which ones you want to export)
• plugin category (for VST, VST3, AU...)

I won't be able to take advantage of @d-healey's awesome new batch export tool, without these settings.

2. Could you please implement a feature in HISE where a plugin would first only load the interface (happens quickly), then display a loader progress bar with "Loading samples...." dialog while the samples are being loaded? In other words, defer sample loading until the interface is showing. This would be really, really helpful for end-users to know that their DAW didn't just suddenly freeze. It would provide for a much better user experience.

Thank you.

[d.healey]

@gorangrooves said in Additional project settings (as available in ProJucer) and defer samples loading until the interface is displayed:

VST/ VST3 options (select which ones you want to export)

This is already there, but it's not too convenient. You have to go to project preferences and enable VST3 support, but it would be better if it was an option in the export menu. My tool already implements this in its own way.

[LightandSound]

@gorangrooves Just FYI, you wouldn't want it tied to the interface loading - that's a very backwards way of programming, the interface should just reflect the data, not be part of it.

And an example of why it'd be a really bad idea; If a project starts with plugins already saved, they wouldn't load until you opened up the plugin, a plugin UI is actually completely disabled deleted when the plugin is hidden in a DAW, or even VE pro when you select another instrument (you can test this by resizing some plugins and then swapping between different plugins in VE pro - those that haven't properly coded their ui to save the resolution in the editor destructor, like SINE [at least in a previous update, don't know if it's still like that], will revert back to the original size).

That said, I've implemented this in my own sampler though by moving the creation of the readers (and mapping the file) to a background thread, rather than in the constructor of the samplersound, which has the benefit of skipping mapping samplersounds that purged on init, saving a lot of virtual memory, definitely something that's possible to port in to HISE.

[gorangrooves]

@LightandSound The idea is that the interface doesn't have to necessarily be displayed in order for the samples to start loading. It should be available prior to samples loading. If a project is opened, which has a plugin present, but the GUI is not opened, it should first gather the resources for the GUI, then load the samples. GUI display should not have to wait for the samples to load. If that is impossible, then a plugin pre-loader should be displayed.

The main point here is that there should be an indication as to what is going on, whether it is a spinning wheel with "loading" or GUI with the progress bar...whatever, as long as there is something informing users as to what is happening. How it is implemented is not important, as long as the goal is reached, which is to inform the users.

[LightandSound]

@gorangrooves I understand, but it's sort of a bad solution to an underlying problem - that being that hise instruments take a long time to load initially.

The cause of that is not the samples loading directly, but instead the memorymapping that happens when each sampleSound is created - my solution above (to move the memorymapping and creation of the readers to another thread) resolves that, which means the UI loads virtually instantly, allowing the UI to then properly relay the information of the samples loading.

[Christoph Hart]

But the sample loading is already deferred and put in a background thread (this is one of the first things I implemented). However it is so old and I haven‘t worked with a project with a huge sample set that maybe something slipped in.

[LightandSound]

@Christoph-Hart https://github.com/christophhart/HISE/blob/2cf72ddab4374aa10fba46da539e9abb945d9470/hi_streaming/hi_streaming/StreamingSamplerSound.cpp#L885

HISE/hi_streaming/hi_streaming/StreamingSamplerSound.cpp at 2cf72ddab4374aa10fba46da539e9abb945d9470 · christophhart/HISE

The open source framework for sample based instruments - HISE/hi_streaming/hi_streaming/StreamingSamplerSound.cpp at 2cf72ddab4374aa10fba46da539e9abb945d9470 · christophhart/HISE

GitHub (github.com)

Also looks like it's on the monoloth audio format directly, but I haven't been using monolith myself, but from the differences in our implementations that looks like where the loading issues would be

[gorangrooves]

@Christoph-Hart If you need a project for implementation/ testing with a large number of samples/ sample maps, I can provide that. Just let me know.