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

@Christoph-Hart That was my first thought, so I replaced the secondary dots with one single blurred shape. This basically halved the number of objects, but did not fix the issue for Intel macs and only reduced the draw time on my windows computer from 10ms to 9ms. On Mac M2 it takes ~2ms to draw each frame including blurred dots.

I checked on a friend's Intel computer today and confirmed that the frame rate does not change whether there are 4 dots or >100.

I have created this animation within my plugin and it works smoothly on Windows and Macs with M chips. All users with Intel chips have reported a reduced FPS for the animation. It is important to note that Intel mac users see a constant reduced framerate regardless of the number of dots drawn. So I do not believe the draw time is exceeding the duration of the timer.

I am building the plugin with a M2 mac. Is it just as simple as me needing to build on an older mac? Or maybe just an adjustment to the Xcode project?

Do you have any theories for why this is happening and how to resolve this issue? Thank you for your help.

@obolig SOLUTION: Turns out the statement in the generated header file that reads #include "src/FaustReverb.cpp" is not searching in reference to the header file, but instead in reference to your HISE path set in your compiler settings. I dragged the "src" folder (including .cpp file) to my HISE folder and it created a DLL and allowed me to export the FX plugin.

I'm guessing this is not the intended process for this. I'll report the issue over on git.

@obolig Update: I moved the "FaustReverb.cpp" file up in the folder structure and edited a single line in "FaustReverb.h" from #include "src/FaustReverb.cpp" to #include "FaustReverb.cpp" to account for the changed location. This allowed me to successfully build the DLL and use it in a HardcodedMasterFX.

Now the issue is that when I try to export the FX plugin, I get the error "DSP Network sanity check failed ... Hash mismatch".

I will continue to try and find a solution. Any help is appreciated.

@fazzitog Did you ever find a solution? I'm having the same issue.

Edit: Are you saying you went to version 2.4.8 of HISE? That doesn't seem right. I thought maybe you meant an older version of Faust, but that didn't work either.

Edit 2: I switched over to mac and got it to work easily, but I still can't get it to work on windows. I'm getting the same error stating

...fatal error C1083: Cannot open include file: 'src/FaustReverb.cpp': No such file or directory...