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

@Lindon also, I think it's recommended to use the latest version from git

Link Preview Image GitHub - packagesdev/packages: Integrated Packaging Environment for OS X

Integrated Packaging Environment for OS X. Contribute to packagesdev/packages development by creating an account on GitHub.

favicon

GitHub (github.com)

@aaronventure I built last night so yes, but I had not deleted the build folder first... I think that's the door ghosts like to pass through to haunt us by the night... 😏

Yeah that solved it, woohoo!

@Mors In the combobox callback you can just use the value parameter

@iamlamprey glad that worked out for you!

@d-healey ok now I've seen what I've doing wrong

@pgaudioworks One trick I have learned if you download UI knobs and they do not come labeled with # of frames. Is to look at the pixel size of the image and divide height by the width. Just how David made his knobs in the video. Great work!

Example: Filmstrip size is 43x2752 2752/43 = 64 frames

Most prob knew that one, but it has allowed me to use some more options.