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.

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.

@aaronventure My bad. I should have made that change before the previous screenshot. I was more so focused on the fact that displayed setup continuously repeats the cycle between 0 and 1 without stopping.

Let me try again to describe what I'm looking to do. The part that I'm stumped with is making the output signal stay at 0 after a single ramp cycle is complete. It should wait for a new trigger before jumping to 1 again for the set period of time. In this case of this graphic, 1 second. Sorry for the confusion.

@aaronventure Thank you for the help! Either I'm missing something or I didn't clearly explain my goal. The current setup does restart the ramp when the resetter is triggered. This is very useful, but I'm looking for the chain to output the value of 1 only for the duration of one ramp cycle. After the cycle is complete, it will default back to 0 until the resetter is triggered again.

I'm attempting to set up a system in scriptnode where a value of 1 is sent for a limited period of time, after which the value would default to 0 until the process is triggered again via a button on the interface. Is there a node or series of nodes that could do this?

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.

@d-healey That would have made sense, but that box is not ticked.