Just wanted to make a post to thank Christoph Hart for creating HISE. Like many other developers here, I started making sample libraries with Kontakt. I found a lot of success within this Engine and still have clients asking me to create Kontakt instruments, but I have lost a lot of passion for these projects. A friend at Spitfire actually recommended HISE to me a few months ago and I've been obsessed with learning about this incredibly versatile engine ever since. It has been a little difficult transitioning over, but it has been made significantly easier with the the built-in API reference tab, HISE documentation, active forum, and the many generous members of this community.

I plan to release my first commercial HISE-built product before the end of this month. My excitement for this release is far greater than any of my recent releases of Kontakt instruments. Thank you Christoph for creating HISE and helping me to rediscover my passion for developing sample instruments.

I'm back after ripping apart my project and putting it back together. The "Mother-Network" that was originally structured in the exported scriptnode has now been recreated in the Module Tree.

The minimal module tree from before will be missed. RIP

I have a few important notes. You need to use Synth.getSlotFX() not Synth.getEffect() when making a reference to the HMFX processor when using the setEffect command. This allows you to load in the exported scriptnode to the module.

Other notable functions are exportState() and restoreState(). These can be used to copy/paste control states of the processors after they move. Use the Synth.getEffect() for this one. The exported string even stores the loaded effect. This means you can simply use this command instead of having to load the effect and then the parameter settings. Both processes are accomplished by this single command.

I still need to set up a system for all the UI controls to adapt their connections depending the updated locations for each module. That should be fun.

@gorangrooves This was exactly the issue. You are incredible. I know you posted a similar image as this in the post you linked, but I'm posting a screenshot here for anyone else that had a similar issue.

When building the AAX SDK (in my case 2.6.0), you must change the runtime library to Multi-threaded. If you don't do this, the VS project will not work. My previous solution to this problem resulted in a bloated file that could not be signed.

This change to the SDK allowed HISE to export both an AAX and VST3 with no alterations to the built VS projects. I then ran the single line of code previously recommended by @gorangrooves

I then created an executable that a friend used to install both the VST3 and AAX. They were able to load it into Pro Tools! I am officially one of the unicorns that has confirmed that a Windows-built AAX CAN be signed using an Apple Developer Certificate. Of course I did still have to go through the process of communicating with AVID and PACE to obtain the required tools and credentials for signing AAX plugins. Thank you everyone!

Issue was unrelated to HISE. The "User Preset" folder had admin privileges set to "Read-Only". Altered the settings of the installer to fix the issue.

@Gabor-K Were you ever able to find this version of the SDK? I've been searching all over for it.

@bendurso Thank You! This helped me resolve the issue. I wrote the prompt for the LinkWindows file to look inside of the samples folder instead of the samples folder itself. Everything is working great now.

@Lindon I understand that. I'm not comparing Ableton's display to the plugin's performance label. I'm referencing Ableton's while my plugin is inserted vs other plugins.

I'm mostly focused on the lack of difference with the performance label within HISE vs the same label on the exported VST. The Mac export has a significant performance upgrade, while the windows export does not.

Is anyone seeing a notable performance improvement with their windows exports?

@bendurso I am not using convolution reverb. I did try activating IPP, but this did not improve the performance.

@d-healey I am using the floating tile control set to performance label. I'm also referencing the CPU display within Ableton to compare its usage to plugins made by other developers.

@whoopsydoodle This was a really good guess, so I compiled the plugin directly from the VS project making sure it was set to "Release". This did not resolve the issue. I even went back to old projects to find that they have the same issue. It actually seems like the exported VST is less efficient than the project within HISE.

Does anyone have any other guesses?

I'm working on an effect plugin that uses multiple compiled scriptnodes. All of these have been compiled as DLLs and loaded into hardcoded master effects. The CPU usage of the HISE project is very similar on my Mac and Windows computers, but there is a significant difference upon exporting the 2 FX plugins. The performance of the Mac plugin is optimized as expected, but the Windows version performs similarly in HISE vs DAW.

Has anyone else experienced this and found a solution? Maybe I accidently toggled a switch that prevents the Windows build from compiling correctly?

I'm back after ripping apart my project and putting it back together. The "Mother-Network" that was originally structured in the exported scriptnode has now been recreated in the Module Tree.

The minimal module tree from before will be missed. RIP

I have a few important notes. You need to use Synth.getSlotFX() not Synth.getEffect() when making a reference to the HMFX processor when using the setEffect command. This allows you to load in the exported scriptnode to the module.

Other notable functions are exportState() and restoreState(). These can be used to copy/paste control states of the processors after they move. Use the Synth.getEffect() for this one. The exported string even stores the loaded effect. This means you can simply use this command instead of having to load the effect and then the parameter settings. Both processes are accomplished by this single command.

I still need to set up a system for all the UI controls to adapt their connections depending the updated locations for each module. That should be fun.

@Lindon The advantage to the current system was that it was built in a single HMFX processor. Each module retained its state after it was moved to a new parent container within the scriptnode. I believe you are suggesting that I create a series of HMFX processors in the module tree and swap the loaded effect depending on the order set by the user. Looks like I can export/import the state of each processor to achieve a similar effect as the current system.

Not really a "problem", just unfortunate that I have to pivot from the simple system I've already created.

@Lindon Thank you. I figured that was the case. A little unfortunate since it is a multiband effect and the current system is pretty clean. I'll go down that route and check back into this thread when I'm done.

I am attempting to make a modular DSP network comprised of 4 effects that can be rearranged. The current system works perfectly in scriptnodes. This was possible thanks to this forum post https://forum.hise.audio//post/39430. The interface controls successfully trigger the commands within the scriptnodes script.

My issue is that the command does not trigger after it is exported as a dll and used as a hardcoded master effect. Is it possible to rearrange processors within a dll through the "setParent" method presented is the forum post linked above? Thank you for your help.

@aaronventure That was it! Thank you so much.