@DabDab there's no standard method for this and most of the solution will be on the server side.

I ended up recreating the background and glass in affinity photo. Also removed the blur from the dots. All of this brought the time per frame down to 45ms. I'm happy with this. Especially since it means it will be slightly slower for ~1/3 of users.

Thank you for all your help @Christoph-Hart and @aaronventure

UI.png

@parabuh show code

@Christoph-Hart @d-healey Hi guys, any one can tell me if this is planned to be fixed? or theres any workaround? Still getting the same issue on Mac Silicon/Intel and Windows

Screenshot 2024-04-05 at 12.22.31.png

@treynterrio In HISE open the pool tables window (you'll need to add it as a custom popup if you haven't already). Check what file size it is showing for images.

@Christoph-Hart is the hise c++ api still working with the latest version of hise I reckon It could be possible as an external floating tile.?

@Christoph-Hart Of course. Inno Setup also lets you do it with a bit of scripting seeing you already have the variable.

But if the user moves the library after install, you need some sort of mechanism for adjusting to that and the baseline is Kontakt which lets you pick a folder, it searches the entire folder and all subfolders and you can set it to use the folder you selected for all other attempts in a session, automatically correcting all missing samples no matter the developer, if you e.g. moved your entire library collection to another place.

If they load up a session with 20 instances of my instrument, I don't want them to have to close the entire project to reload the samples (your built in solution requires an instrument reload; all you have to do is call Engine.reloadAllSamples() if the folder contains the samples).

@modularsamples ...then just use two modulators...

@d-healey ok thanks - looks like it likely a security config. issue for the user machine....

@d-healey sorry I was answering @clevername27 's question...

@yall try exporting your plugin and check the load times in the DAW everything will be loaded on init and will be very very slow

@d-healey Thankyou, as usual your help was invaluable.
Ironically I have been using autocomplete quite a bit recently but it didn't even occur to me in this case.

Thanks again, it is doing what I want it to do now

@ustk yeah, that's what she said. 😂

@d-healey Ahhh , i see
Thank you

@clevername27 said in Share Your Best Practices for Compiling for Compiling for Commercial Distribution!:

So some explanation first:

I think Im in a slightly different place to Dave, he does consulting but I think most of his build work is for in house products, where as Im nearly 180-degrees opposite to this. I build a LOT of stuff for my client base, and only occasional stuff for my own product set, so I'm often very driven by deadlines - and very often limited in which version I use of HISE - it MUST MUST MUST include a reliable repeatable set of functions, so for example I haven't been able to run anything new since the Filter display bug (which doesnt seem to be fixed by the way) came up several months ago...

How do you go about getting the fastest, most reliable code?

A few sample questions…ha -

Do you have two versions of HISE - one for development, and one for building releases?

Nope, see item 7. One only is all thats allowed

Do you use the "CI" or "Release" schemes?

I just (mostly) use the native in-HISE menu option of compiling the product, if for some reason this is failing then I'm not keen on off-product work arounds and I try and get my product into a position where I just press EXPORT>target plugin...

Are the any definitions/preprocessor-directives you use?

Well as a base place to start I go with;

HISE_SAMPLE_DIALOG_SHOW_INSTALL_BUTTON=1
HISE_SAMPLE_DIALOG_SHOW_LOCATE_BUTTON=0
HISE_DEACTIVATE_OVERLAY=1
ENABLE_ALL_PEAK_METERS=1

I'm pretty sure the first two are no longer needed as they are replaced by the Deactivate overlay - and a note on this - I use my own in house installer for all assets(samples, images, wav files, met data etc.) so I don't want the plugin loading and trying to do installs, so really if you are wanting the plugin to load and save your Sample spot then the Overlay isn't any use to you.

What Settings do you use in HISE (for building your plugin)?

Pretty standard out of the box - Im again not keen on introducing specific dependencies for products - I want to build them as efficiently as possible so that means as little fiddling about as possible.

What Settings do you use to build HISE, itself, for the version that will compile for your final plugin?

Its a std build - and as I say only one build on the machine at any one time.

What are the safe optimisations?

Nearly all the best optimisation are going to be in your instrument design, layout and HISE Script not in complier flags.

What should ABSOLUTELY not do, but most people might miss?

One version of HISE on the machine at any given time fail to use git -this is a double negative so let me say it clearer - GET. GIT. NOW! and then get a GitHub account and use this to backup (and occasionally restore) each project.

OK, that's a lot, but I think we can all agree it would be helpful to have all this in one place.

On my end, I'll keep it all updated, and you can see the tutorial I've written so far.

Cheers.

@orange Yeah, that's a good point.

@d-healey ah that's fantastic thankyou. I'll try that when I fire up the laptop shortly.

Thankyou for testing and finding the solution, it is much appreciated. I don't think I'd ever have found that!

@Christoph-Hart Thank you very much.

@Christoph-Hart Sweet 😊