@dannytaurus I use GitHub Desktop

@Chazrox said in NEW GUI DESIGNER APP! ::: Rox Designer Suite::: is LIVE!:

@Lindon There are file-handling features that cant be done in a web-browser so Im switching to stand-alone.

..and the web version will remain "as is"?

@ustk thanks mate I will give it a go...I have no idea how to do a "correlation algorithm" but its all an adventure...

@dannytaurus Interesting, looks like they are also phasing out Intel support when they eventually limit the minimum deployment to 27.0 - probably a few years yet.

I'll just stick with my existing build system for now until it no longer works.

@eschirle I don't know, I haven't used the ci method

For anyone curious - it looks like you can get around this by linking the expected path to wherever you have Visual Studio installed

mklink /D "C:\Program Files\Microsoft Visual Studio\18\Community" "C:\Program Files\Microsoft Visual Studio\18\Enterprise"

@Jeetender said in Latency issues..:

@Jeetender said in Latency issues..:

I made a vst everything works fine, but when i open that vst into any daw like flstudio/live/reaper/reason it gives out latency.. how do i compensate the latency automatically?

i did try this.. but nothing worked, BUT i had a dynamic module in the end of the chain, which had a limiter, i removed it and then the latency was gone after compiling the vst..

can u please elaborate, coz iam not much of a DSP coding guy. but i had tha plugin at the end of the chain which already was of no use.. and i dont know why doesn't it report the latency to the DAW automtically, the other plugin ive made do this well and good, no latency with other plugins.. but i am here to learn more about this.

@dannytaurus PACE has added WoA support to Fusion 6 SDK, Eden Tools, and iLok License Support 6.

This indicates that there will be demand for this (though I am not sure exactly how soon) at some point.

@David-Healey Damn it. I'm really quite susceptible to these somehow 🙄

@dannycouture

So you got it working with RNBO 1.4?

Since...
I've found posts saying it works over 1.4, and others that it won't, and wasted half a day yesterday trying with different settings on 1.4.5 export. Today I decided to use my time a bit better and try to find what works, not what doesn't.

I've been testing things all morning, and have come to a conclusion, that after RNBO 1.3.5
something changed in their code, and the import doesn't work anymore starting from RNBO 1.4.0 upwards. I would be interested to know how in hell some people are getting it to work over 1.3.5

Here's the versions I've been testing with.
The HISE base folder being a new duplicate of the same original one on every case.
Only exported RNBO files are changed in /src
I didn't bother to try every update/downgrade, since the pattern seems quite clear.

Using HISE 4.9.3 3deb6f2a compiled with Faust

Max 8.6.5 RBNO 1.3.0 Guitar Pedals 1.0.4 Booster Working
Max 8.6.5 RBNO 1.3.4 Guitar Pedals 1.0.4 Booster Working
Max 8.6.5 RBNO 1.3.5 Guitar Pedals 1.0.4 Booster Working
Max 8.6.5 RBNO 1.4.0 Guitar Pedals 1.0.4 Booster Not working
Max 8.6.5 RBNO 1.4.1 Guitar Pedals 1.0.4 Booster Not working
Max 8.6.5 RBNO 1.4.2 Guitar Pedals 1.0.4 Booster Not working

Max 9.0.9 RBNO 1.3.5 Guitar Pedals 1.0.4 Booster Working
Max 9.0.9 RBNO 1.4.0 Guitar Pedals 1.0.4 Booster Not working
Max 9.0.9 RBNO 1.4.5 Guitar Pedals 1.0.4 Booster Not working

As with the tutorial video on the tube about the matter, you cannot see what the actual version of RNBO is used, so that doesn't really help either.

The reason posting here being really to spread the conclusion I came to with my set-up,
and maybe someone trying to exchange files between MAX and HISE can actually find something helpfull.

Here's where you can find the version of the RNBO you're using in MAX:
Go to File/Package manager, and be sure that you're in Installed packages, not the remote packages. Then from Show all versions you can find the versions of RNBO available for up/downgrade. Based on the experiments, I would advise not to go above 1.3.5 at this time, but of course, I might be wrong as well, That's how it works for me anyway :)

rnbo.png

For everyone using the Knob app, I just pushed a new update. This is the latest version that is included in the new 'Designer Suite' app that has all of the other component designer apps.

Heres the link to the updated Knob-Builder:
https://rox-knob-builder-for-hise.netlify.app/

Link to the Full Rox Designer Suite:
http://roxdesignersuite.com

@Kalliopei In this case you could get the Display Buffer Source of the network and then the Index of each Peak Node and then do whatever you want with the value you get. You can do something like this:

CODE:

//Get the FX Display Source Reference const var dp = Synth.getDisplayBufferSource("Comp"); // Get the Displaybuffers const var input = dp.getDisplayBuffer(0); const var output = dp.getDisplayBuffer(1); input.setRingBufferProperties({ "BufferLength": 1024, "NumChannels": 1 }); output.setRingBufferProperties({ "BufferLength": 1024, "NumChannels": 1 }); const var inBuffer = input.getReadBuffer(); const var outBuffer = output.getReadBuffer(); const var inMeter = Content.getComponent("inMeter"); const var outMeter = Content.getComponent("outMeter"); const var subMeter = Content.getComponent("subMeter"); //Timer Object const var reductionTimer = Engine.createTimerObject(); reductionTimer.setTimerCallback(function() { //Befor Comp inMeter.setValue(Engine.getDecibelsForGainFactor(inBuffer.getMagnitude(0, inBuffer.length))); //After comp outMeter.setValue(Engine.getDecibelsForGainFactor(outBuffer.getMagnitude(0, outBuffer.length))); //Difference subMeter.setValue(Engine.getDecibelsForGainFactor( (inBuffer.getMagnitude(0, inBuffer.length)) - (outBuffer.getMagnitude(0, outBuffer.length)) )); }); // Start the timer with ~30Hz. reductionTimer.startTimer(30);

SNIPPET:

HiseSnippet 2083.3oc2Y07aabbEeVIsxgzoo0EIH43BgBT5BWYRZEakzFHpOsEpoDgnhSxImQ6NK4Ts6LK1cVIwDjhbrG60zKM+Izq8l+CHG5GG6k9mfu1Ks88lYWxcIYjoHbsRhBP.m27dy7998aV2IV5xRRjwDqpGOHhQrdc6tCDp9a2mxEj82gX8F1soIJVrigzVChnIILOhk0hODIXUYIh9umuwVz.pvkMhDg7DI2k8XdHWMhZmV+FdPvdTO1w7vBbuVq8ckhskAxTPeVztNIh5dJsG6.Jx1B1jGQS5Sr9E1dMVqg+5tz6udi0Z551b8Gz78dfKi56ytei28Aqst+Z9T25MIVKuqGWIi6pnJVBbnaI8Fzsu7bg4BdBOgeR.CWzfzEtYCYx184AdcxcNIDhkcmQtpEMtp2ztM2iOj9HW1OQugyHIJ5zrV3xToFWAUxpfJsjQktkcW2XdjZzNn9bS68EPDDbIrRphgWxBw11aKANDpUComx1KFVLThZ2ud863.+ua+qpV8t28gLkipOyYuO1YGdRT.cfSWHd4xbNh4yhYP7uJDESTNmQic7hb9.GcB0p8XpLA1JEhSwFopsx1xvnULmsS9gmw3IZFSJbdbQTpBNRunINuZnBNhSYp5am0F38oOqUSXpi3hdlM.2VDKVwYI097pNNqXn9Xlnmp+JuuSi5MW6NH8CRCgnsPvBRPxU+B77L23KwCrnYaDDLGiVCVzQLpWl4LtgOj4LUZBtKczsYJMy4o..2XLQJfE0VIa+UF+NtboxYnrXIomb4hkyPV9.1dH14vS9sLWUgiIl4k5p3RgY+OvYWQOtfspaLCJozDMxnM0xbigG8O1lFDbBzdolepPucsaW8yqV4t2cKluDZ1AJU0JYFOJzSnAorZY2DlPwb4m.gq8jwXav8ntPMcs7.ExQaZOAWk5wpA0OC2HPG6u8sAUqBdca5iNDW80k60l86aXvdhKbzNitwJlqbGtedkZkbO9rek3YbErSmeoyURKwi2npULUAPaAnUYrowfRGwOmq5676tW8G8YqNQ3EYU+yZ2CZHjGbcjhCjJ1gYQ4peQUmw2x2ep6gIpwxf.rvYJaatpKQvZhzvSXw2AxbAu6PFgN1kGCr7rMFv0T2TfQoXevedXDKa8dx.Or8N96IGZPxJ7fe8g6uCUQw4HYzF0rBnsC6LXxsYpRE6cXImpjQvoNrZEPFnz69FYyb5Fv8XwDtGJPVkC4hhi2GTbQhZ.ZdUseBdmtz.RH2yKf0QlvQWHxqkl2lOCveD0k+YZrB+wuB+6urQXQrGexyBoWTD2QBjUwAJ11NdaQRnmw1WzIlAY43fuy4dJ.Hgs0uFXsOi2quBWUeABIT5kYw5jezgMCFbU67Z2hV7m7CZKNu0QAK9K8+9oEOIPJ.BmzKMfpJiqC6ClsAp9EASg.lDfYMnHh3q.Xu5WJXuYUEukcGtxs+z0wElhNB0+++PGyfH+ir2E5t6pFofKYu2GOu3gqO63gsM2e0rDW3NwKeYaL2tz0CHuJgMLASRfbDRF3Xqeu8nt5QwrHZL6XYGf+ZIzvn.1QfZeGmSBjtmhouSNJHxnUagbTyMCk27LwX4WRObfbDzrBfn1lph00OfOvfFOGCZtOHaccbMlpzkI7zK9uveYa1.WaksYi7MKLm4.l5bY7o5HT1uIV2.CGutch1I+T+KZP1LHPdNFd3YItPvQSqiLXPTeof6hjLbjqoaFJSEpb0Edd3wTd.lo2MMAlH5cnnKvr9MoVKBMgRzG7MrquJ7ePl+A5NAKaf1LnCE6XbKabHKjuBvIbGl2VRWKk.oebZoswSM+YrFGGn0g5FpviXsVrvfVSVKtBpIWvbQ6mLrcoFRFZO5yDYewLU1jNGwnmRJo82Dz9X1p5MlTMyj3EnfKUTAIi5kbLMF.vYPQfo9WjCfXrJnwofVlvicQ9ksKje6AfTzhmmvzgFCpnRKOojQhfiKaj+XauABZH2MYU2IJnyLT8FWiFJZTuPC0xd3JHsrMWjEvGMyqM8hwnAUZEFUBK+ZbTY2SYma7QYTeVu+7a0xjPcbeXpX+9.vPRgyp0666+ye1NLeZZfZh6fb4JF3sFWwZIaMSJ1mt1e3etApXul8lJE7DLxDm8zUp8a8JPopXeDKfQSXE0p24O8U+6Or0bpUOeiIigslMs5q+G+m+tVqtg8QXhYQc5K+aey2buuEc54ab08TfRMlNoOnIzIMUyWUpKfFzzgbFifkqrugtYTiqR+qbQtFqqsloFXkVrkTdZHUOBbtd0UQfUusYyaZ+Q.dW8WVSOd5szq8kwgNOjAStPTgMtjOV6ecV+XsQy7Gq8PWEnBGGSEIQxDViRcrXg7ig2TjTh5XRzbpRzrbZkJUT9nMjJwE5J1CbEE360ZkSrYQhcnhRGFrtzI0lW3EG+qM1UPADVcYfk6cXhK3XniUXzIMHg8Q3SOZTTvQjaVj7inwdPLzsDb7EKCyaoYClW4WlTf+o.Td4qguk8Kmm2bM9BrROunRtN1ki8Q1UbFK.Ji053O0Nq4WN0x0gskBYNb1QQ8iX.V7d8Xk6xNMCJal4PJuYq7AVCI8yZ8X.8JMts4ctyiu3p+O8vTiWuS1HdGr4gy2ee47h+f9kyyd0GzO761Qw21F5K2zQGJctdhkuJdc8qh6Hj5FKepq4iRfE8U0T.6VnwhUwtMt1oA4rwQ4EBiLdpqa4iZBAaNuBdu4Uv0lWAe24Uv6OuB9f4Uv0mWAeuqpfUyS.p+hkDAQrYpRFZJGAjUc10fd1x.pRWYR9eO6K.TA

@Christoph-Hart I was afraid of this but in the end yes, I guess I could. The blocks should just need a global cable so I can have a unique sender network for all the cables and then make a module per FX receiver... And it'd probably simplify things a lot instead of having just one giant blob... Should have just have thought about that earlier! ☺

Okay, thanks for your quick answer. I think this works nowBildschirmfoto 2026-08-11 um 14.51.44.png

Here I am experimenting with Figma and Webview

The idea is a moving field of hex cells with a lot of parameters.

Main ones are the Cell fracture, Sparks, moving exclusion zones, Hotspots, orange comets, cyan frames that capture a bunch of cells, cell size.

Spectrum is also done via webview.

I am really hoping that Webview matures in Juce/Hise as its a great way to design any intricate moving graphics although at the moment its great for prototyping and I am exploring converting a design into GLSL ? If even possible.
I gather that the current issues are platform compatibility, overall stability and sample accurate response, hopefully this will advance.

HEX GRAIN UI

Main hexgrain.png

HEX GRAIN UI
Hex 2.gif

HEX GRAIN UI
Hex 3.gif

HEX GRAIN UI
Hex 6.gif

HEX GRAIN UI Controller
Interface.png

HEX GRAIN AD 4:5
Texture In motion.png

Thank you for helping.

Wow that's amazing good job as always 👍

@dannytaurus said in Latest version of HISE breaks existing presets....:

@Christoph-Hart Here's what 'my' Claude says:

The pattern so far

Since a92a701de (the unified automation base class), every automation actor - host parameter, macro, MIDI automation, UI widget, script, preset restore - is both a reader and a writer of shared values, connected through the dispatch library. The regressions since then have all been the same bug wearing different hats: a listener can't tell an echo of its own write from a real change, so it feeds the value back around the loop. Each fix so far suppresses one specific edge:

633626eeb - gate refreshParameterValue() on enablePluginParameterUpdate, and switch MIDI automation's setAttribute from async to sync notification e1fb54695 - carve the backend macro-to-parameter-slot routing out behind HISE_MACROS_ARE_PLUGIN_PARAMETERS

Alongside the pre-existing guards (recursive, sendToHost per parameter, deferNotifyHostFlag, the exclusive-mode conditionals in loadUserPresetInternal()), that's now seven or so overlapping mechanisms all answering the same question by inference: "is this change an echo?"

Why I think flags can't fully close this

Two structural limits:

The global flag suppresses the wrong scope. enablePluginParameterUpdate is one boolean for all parameters. While parameter A's update is dispatching (flag false), a legitimate concurrent change to parameter B hits the early return in refreshParameterValue() and is silently dropped -the internal value updates but the host never hears it. I suspect this is exactly the DAW-project-vs-internal-preset drift you were hypothesizing about at the end of the thread. The guard isn't just failing to fix that bug, it's a source of it. Scoped guards can't survive deferred dispatch. A ScopedValueSetter protects a call stack, but this system defers across threads by design. By the time an async-queued listener runs, the guard is long restored and the echo sails through. That's why 633626eeb had to change MIDI automation to sync notification - to drag the callback inside the guard's scope. Changing threading semantics to make a boolean reachable feels like the approach hitting its ceiling.

Proposal: make provenance explicit

The class structure from the rewrite is good - I'd keep all of it. The change is to what a notification is: value plus origin, instead of value alone.

Add a small source token (Host, Macro, MidiAutomation, UI, Script, PresetRestore) to SlotSender::sendChangeMessage() and the listener callbacks, threaded through CustomAutomationData::call(). Because the token travels with the queued message, it survives deferral and thread hops - the thing no scoped flag can do. Each writer passes its own token and ignores incoming messages carrying it. MacroPluginParameter::setValue() writes as Host and skips Host-tagged notifications; same pattern in HisePluginParameterBase, MidiControllerAutomationHandler, CustomAutomationParameter. recursive, sendToHost and the global enablePluginParameterUpdate then become deletable. (deferNotifyHostFlag can stay - batching host notifications is an optimization, not a correctness guard.) Preset restore becomes a first-class source: "macros must not clobber freshly restored widget values" becomes a one-line filter rule instead of an ordering convention plus exclusive-mode conditionals, and the MIDI sync/async choice stops mattering for correctness.

For precedent: JUCE's own ParameterAttachment solves the identical loop the same way - each attachment filters its own echoes at the attachment point.

Hmm, I must give this Claude malarky a bit of a go......