@Kaih

--- Edit 2: Now, spending around 5 hours with the software, I have to say the application is a golden resource for an interface designer and non-designer as well.

The possibilities to change parameters are vast, and all the parts of the software have been working as expected. This is well worth the asking price, and I urge you to just get it if you're doing work with interfaces in HISE. Absolutely golden.

One thing that bugs me a little, is the application logging in to the server when started, Probably for the licence checking, but might be used for the code generating as well. That always makes me think of the future with that kind of softwares. It gives a possibility for subscription based licensing, which is the pestilence of this time, or if the company goes down for reason or another, it renders the software useless.

Quite a number of presets is always a welcome thing and possibilities for community generated presets seem to be integrated as well. The developer seems to have big vision for this, and not without a reason, I could see it widening to other application targets as well with the code base, although it's already useful with the javascript, filmstrip and .png exports. There hasn't been too many of this kind of softwares over the years, some come to mind like jknobman, knobstudio, and those aren't exactly modern.

Anyway, for the time being, damn, this is excellent and takes off the unneeded pain of manually going through the code line by line. Brilliant!

@LucaL check what's in that array, I don't know without seeing the rest of your project

@ustk Haha I am launching HISE with the cli most of the time and there it worked so I never bothered…

hise-cli -hise launch

@Morphoice
Ah, no but that is a reason to reset everything!
Under many conditions, changing parameter values all at once can produce monstruous audio. Like, if the DSP effect has feedback, if you don't clear all the buffers, the audio from before the switch, could blow up under the new parameters. There are scenarios that can sound really horrible or blow out your speakers. I mean, let's say the new preset has different reverb parameters, you'll get all the reverb knobs yanked while it's still playing, and get all that washy doppler... Of course that's not a horrible situation, but you can imagine that certain DSP would produce really loud nightmares. Which is why it's quite sane for Hise to send reset() on a preset change, to clear out all the buffers and start from silence. It's the safest thing to do.

But I agree that creatively, there are situations where this is not what you want. But you can understand why Hise went with the blanket solution.

@ustk The man is too good! 🔥 @lalalandsynth 🏆

@aliabr_prod You can see all the latest developments here

Make a bug report at github and link back to this thread so it doesn't get lost.

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

@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! ☺

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