Who else misses the wonderful HISE Exporter app?

[gorangrooves]

Compiling plugins one by one makes me wish there was an easy solution to queue them all and let them compile overnight, without my input.

Then I remember @d-healey 's HISE Exporter, an ideal tool for the very purpose. To me, it was without a question the most useful app for plugin development since the invention of HISE.
Unfortunately, it hasn't been updated in well over a year, and the queuing functionality had a bug that prohibited it from leaving it on its own to render overnight. Now, it doesn't seem to work anymore with the newest HISE.

I miss it so badly as it would benefit me so much, that I would be willing to pay handsomely to Mr Clever to revitalize it and make our lives easier.

Who else misses it and would love to see this amazing app at its full potential?

[d.healey]

I stopped working on the exporter app because I started using build scripts which are much more flexible. I made a few videos about my OSX build script. It does everything the exporter app did.

I use one script per project but you could use a single script with a loop to build multiple projects.

[Christoph Hart]

+1 for build scripts. One for Windows can be found here:

hise_tutorial/BasicSynth/build.bat at master · christophhart/hise_tutorial

The Tutorial project for HISE. Contribute to christophhart/hise_tutorial development by creating an account on GitHub.

GitHub (github.com)

I'm building all products I ship with a build script that is hooked on some kind of build server to be fully automated.

[gorangrooves]

@d-healey I know that build scripts may be more flexible. Doing it by hand as I am doing it now is even more flexible, but neither are as easy. Theoretically, I could be writing this text in binary using only 1's and 0', but it is a lot easier to use a keyboard with the alphabet on it.

You could have expanded your Exporter app with a few more options and added the ability to save settings.

These scripts require yet another level of brain-drilling, as opposed to a super easy-to-understand and use tool.

Sorry @Christoph-Hart, but your vote doesn't count. For you, the script may be a better option, but this tool is not meant for geniuses.

[d.healey]

@gorangrooves It's a lot more work to make an exporter app than a few scripts.

You don't need to do any work except add some paths and credentials - same as for the exporter app - because the scripts have already been provided for you.

[gorangrooves]

@d-healey I looked at the scripts. The Windows one is gibberish, and the Mac one (you posted on Patreon) has a lot of extra things and things that are missing for me. Right now, it is a lot easier and quicker for me to just power through manually with each plugin.

Honestly, an up-to-date version of your HISE Exporter would be 100x more helpful to someone like me, than any scripts. You've already spent time building that wonderful tool. I imagine that the vast majority of the work is done. That time was either wasted (if the app is not updated), or invested (if it is).

How much time precisely would it take you to bring it up to date?

[d.healey]

@gorangrooves said in Who else misses the wonderful HISE Exporter app?:

@d-healey I looked at the scripts. The Windows one is gibberish,
and the Mac one (you posted on Patreon) has a lot of extra things and things that are missing for me.

What's extra? what's missing? Did you watch the videos?

Honestly, an up-to-date version of your HISE Exporter would be 100x more helpful to someone like me,

The current version should work as it did before, nothing has changed - what do you find is not working (other than the queue bug that has always been there)?

That time was either wasted (if the app is not updated), or invested (if it is).

Time is never wasted when doing something creative. I learned so much from making that app, especially about unit testing!

How much time precisely would it take you to bring it up to date?

That's impossible to say. Firstly, what is "up to date"? One of the main reasons scripts are better is that they can be easily tailored for each individual and each project. For example I have no need for IPP, AAX, VST2, etc So adding all that to the app is/was a waste of time for me personally. But with a script it's like a few extra words and it's done.

I think you can learn to change a few parameters in a script more quickly than I can change an exporter application. And once you learn how to do it you will be able to do so much more. Scripts are incredibly useful for automating all kinds of day to day computing tasks.

[gorangrooves]

@d-healey I did watch your videos.

I don't use HISE to export my plugins. I only use it to create the AutoGeneratedProject, and then I customize it further in the Projucer.
What it misses (as well as any scripts that depend on it) is the VST3 plugin category (and any other category), what type of Mac it targets (Intel/ arm64), what version of MacOS it should target, and whether or not it should copy plugins after compiling. I also switch on the hardened runtime for the project in Projucer.

I assume those could possibly be somehow added to the scripts.

I didn't test HISE Exporter on Mac recently, but I did on Windows. It just wouldn't do anything after I click to start compiling. It would start, then come right back to the batch list.

I could probably repurpose script pieces for signing, notarization, and stapling, so I don't have to copy+paste and type them one by one.

And by "up to date" regarding your HISE Exporter, I mean it to include binary compiling for Intel/arm and anything else relevant to the currently available OS's.

JUCE could have also told developers to create hieroglyphic scripts, but they made the Projucer to make developers' lives easier.

I stand by what I have said. I think you made a wonderful, extremely helpful app, and it is a real shame that you haven't updated it. It had a wonderful premise for batch compiling, which lacks in both Projucer and HISE. It was like a bridge between the two. I understand that you don't feel like doing it, but I personally find it way better than messing around with any scripts.

[d.healey]

@gorangrooves

What it misses (as well as any scripts that depend on it) is the VST3 plugin category (and any other category), what type of Mac it targets (Intel/ arm64), what version

My build script won't set the plugin category. It will build a universal binary for Intel and M1 on MacOS.

What version of MacOS it should target

If you want something other than the default that HISE uses (I think it's 10.9) you need to fork HISE and change the jucer template generator (it's not hard) but what's wrong with the default?

whether or not it should copy plugins after compiling.

My build script will always copy the plugins to the packaging directory, ready to be bundled into an installer - the exporter app does the same thing.

I also switch on the hardened runtime for the project in Projucer.

The build script does this automatically too.

It would start, then come right back to the batch list.

What version of Visual Studio are you using? Did the app show any errors?

I mean it to include binary compiling for Intel/arm and anything else relevant to the currently available OS's.

That's automatic. By default XCode will build a universal binary.

JUCE could have also told developers to create hieroglyphic scripts, but they made the Projucer to make developers' lives easier.

JUCE now tells people to use cmake scripts and there are some features missing from Projucer that you can access with cmake. I'm waiting for Christoph to make the transition.

[Christoph Hart]

I'm waiting for Christoph to make the transition.

I'm afraid this will not happen very soon. Unless there is a really hard reason to do this switch, this step will wreak havoc for the entire build process that has been so tedious to setup to get to this point and the amount of build issues that will spam the forum will be unseen. I was tempted for a short while because of CLAP, but that hype is in the past :)

I don't use HISE to export my plugins. I only use it to create the AutoGeneratedProject, and then I customize it further in the Projucer.

Yeah that sounds like a terrible approach, your hands must hurt from all that clicking. I'm happy to add more customizability to the Projucer exporter (it's just a few lines of code and a wildcard in the template), but let's talk about the necessity of your changes:

• VST3 plugin category: sure that's solid, I didn't bother too much about VST2 yet because I still have the precious VST2 SDK.
• macOS architecture: why would you want anything else than a Universal binary that runs on Intel + M1 Macs?
• macOS version: What do you need that for? There's a minimum version because the C++ SDK needs to be C++17 compatible, but if we can get lower than 10.9, I could do it.
• hardened runtime: sure I can make a tick box for that, but that option has a few implications that you might be aware of (I'm not sure what those are exactly, but I thought about this and opted to leave it disabled for now back then).

JUCE could have also told developers to create hieroglyphic scripts, but they made the Projucer to make developers' lives easier.

They also made the Projucer command-line accessible so you can hook it up in hieroglyphic scripts. Also its purpose is not to avoid automation, but to coallescate the IDE project management across all OS which it still does a great job even if there are more industry standard tools (CMake) around.

[gorangrooves]

@Christoph-Hart

Yeah that sounds like a terrible approach, your hands must hurt from all that clicking. I'm happy to add more customizability to the Projucer exporter (it's just a few lines of code and a wildcard in the template), but let's talk about the necessity of your changes:

• VST3 plugin category: sure that's solid, I didn't bother too much about VST2 yet because I still have the precious VST2 SDK.

That would be great.

• macOS architecture: why would you want anything else than a Universal binary that runs on Intel + M1 Macs?

No, I would only want the universal binary, but when I open the autogenerated HISE project in Projucer, only the Intel one is selected and I have to manually select the arm64 and arm64e.

• macOS version: What do you need that for? There's a minimum version because the C++ SDK needs to be C++17 compatible, but if we can get lower than 10.9, I could do it.

I was compiling AUv3 (which I am yet to figure out how to distribute and install) and it was giving me an error saying that the minimum target system should be 10.11 for both the plugin and the app. So, I have been changing that to 10.11 before compiling.

• hardened runtime: sure I can make a tick box for that, but that option has a few implications that you might be aware of (I'm not sure what those are exactly, but I thought about this and opted to leave it disabled for now back then).

If it is not compiled with hardened runtime, it needs to be done afterwards in the command line or script. It won't sign apps without it. (I am not sure about the plugins now at the top of my head.)

JUCE could have also told developers to create hieroglyphic scripts, but they made the Projucer to make developers' lives easier.

They also made the Projucer command-line accessible so you can hook it up in hieroglyphic scripts. Also its purpose is not to avoid automation, but to coallescate the IDE project management across all OS which it still does a great job even if there are more industry standard tools (CMake) around.

Yes, but the objective of the Projucer is to make it easier for everyone, especially for folks like me. Reading an option in English and selecting from the drop-down is a lot easier than scouring the internet to figure out what in the world would be needed/missing in a script.

Interesting thing: I tried using a script just for just signing the plugins. After I dicked around with bash vs zsh shell, it was giving me like a typo error as it wasn't liking (). While it works as a command line typed directly into the terminal, it wasn't working in a script. After wasting my time with trying to make it work, I just went ahead and, within a few minutes, manually signed 90 files. It took 1/10 of the time to do that that I wasted trying to get the damn script going. See my point here?

@d-healey I am using VS2017. HISE Exporter would not show any errors. It starts, stops, and comes back to the batch queue.

[d.healey]

@gorangrooves I have no idea why it's not working then