@ustk Thanks for the suggestion. I just tried calling th.setSyncMode(th.SyncInternal) and it does trigger setOnTransportChange the first time the DAW is stopped. After that, the function is not triggered again by playing or stopping. The clock actually stops altogether.

I'm building a plugin that includes a step sequencer that can either sync with the DAW or a custom BPM. This is done using a transportHandler that is set to PreferExternal or InternalOnly.

While using a custom BPM, I would like the transportHandler clock to reset when the user presses play within the DAW. I tried using th.setOnTransportChange(), but it is not triggered when using th.setSyncMode(th.InternalOnly).

Do you have any ideas of how to reset and retrigger the transpotHandler on Transport Change?

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

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

I'm currently having an issue with an instrument not allowing users to save presets on Mac. Have any of you had this issue and found a solution?

Here's some info to possibly help determine what's causing the issue:

• Instrument was made by altering one of my previous HISE projects that does not have the same issue
• Presets CAN be made on the windows build
• Presets CAN be made within HISE on mac, but not within the exported plugin
• Project has a unique Bundle ID and Plugin Code ID
• Preset browser can be used to view and load presets, but not create. "Add" button works, but no .preset file is created after inputing a name and pressing "OK".

I believe this issue is the result of a mistake I made with the project settings. Do any of you have any guesses? Your advise is much appreciated.

@aaronventure Simply updating to the latest release did fix the issue. I can now export through HISE without having to edit the auto-built Xcode project.

BUT I was reminded of why I have been sticking with the release from September 2023. I have a separate project that uses FAUST and Scriptnodes. The newer versions of HISE crashes immediately upon trying to load this project. Can't remember if it is FAUST or Scriptnodes that causes this.

Solved one issue, and rediscovered another. I'll mark this post as solved since the main focus was resolved.