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.

@aaronventure Sorry. I meant the release in September

@aaronventure

• Mac OS 14.2.1
• Xcode 15.3
• Yes
• Yes
• No
• I believe I'm using HISE 3.6.2 with no modifications. I did have a period of time where I was trying other versions because of issues with Faust, but came back to the 3.6.2 in the end.

Is this maybe something I can fix via extra definitions in HISE's settings window?

I do not have this issue on windows, only mac.

Every time I export a plugin via HISE, the generated Xcode project does not successfully build until I manually edit "Installation Build Products Location", "Installation Directory", and "Architectures". This adds a couple minutes for each export, so I would love to find a way to correct these parameters once and they stay that way for ever future export.

Does anyone know how I could permanently change these settings?

I ended up recreating the background and glass in affinity photo. Also removed the blur from the dots. All of this brought the time per frame down to 45ms. I'm happy with this. Especially since it means it will be slightly slower for ~1/3 of users.

Thank you for all your help @Christoph-Hart and @aaronventure

@Christoph-Hart I use blur all over the place (including glass). After commenting out ALL blur, the framerate was improved significantly. I would have suspected this did not affect separate timers since the glass and background should only be drawn on initialization. Why is this only an issue on Intel?

@obolig I figured out the issue, but I wouldn't really call this a solution. Turns out Intel Macs HATE LookAndFeel. My images folder is literally empty because everything was made with LocalLookAndFeel's/PaintRoutines. This includes static objects like the background and glass overlay. I replaced these two panels with image controls and the lag went from 174ms down to 40ms. This is including the visible animation.

I have run the same test on my windows computer and found that removing these 2 panels does improve the frame rate, but only by 3ms. This is compared to the 134ms improvement on intel Mac.

I would also like to point out that it is not just an issue with panel controls. I enlarged the top horizontal slider (not animation) to fill the entire UI and found that the frame rate went from 40ms to 85ms. This means it is connected to size of ANY control that uses LAF.

I hope all of this information helps to fix this bug.

@Christoph-Hart I set up two clocks to measure how long it is taking to draw each frame and the wait time in between each timer callback. I've set the timer to 30ms. On windows, the max draw time is ~10ms resulting in a wait between timer calls of ~25ms. When it takes less time to draw, the wait in-between TimerCallbacks becomes larger, as expected, because the two clocks should add up to 30.

On intel Mac, it takes nearly the same amount of time (13ms) to draw, but it is waiting much longer (174ms) to retrigger the timerCallback .

The draw-time is well below 30ms on this 2014 macbook, so it should be good. The wait between timerCallbacks is the issue. This is with no drop-shadows/blurred-dots. Any theories of what could be causing this?