@David-Healey said in Opening plugin UI disables active automation in Ableton Live:

@Lindon Christoph said in another thread that he's currently busy with a theatre project but will get to the PRs soon.

https://forum.hise.audio/topic/15026/au-component-version-is-always-0-in-exported-plugins-xcode-exporter-misses-versionashex/8?_=1788803845075

yes I know I read it- Im just tagging this one as one I think needs to be included - of course Christoph is entitled to tell me to F'k right off with my view of what is important or not :-)

@dannytaurus another useful and helpful PR...@Christoph-Hart ??

@dannytaurus its an attempt to offer an alternative to Kontakt from Mike Greene and friends...

@resonant - I think Dave's right there are not any real problems these days getting the plugin into the "system" folders on a Mac (but its been a while since I've done it as Im nearly exclusively on Tracktion these days) so caveat emptor... but every other problem (locations and content) are still there which is what the CR Setup componentry is there to resolve.

@resonant said in HISE made Plugin Installer:

I think I’ve seen a few users (maybe @Lindon @ustk @orange) try this before; I’d really like to know what the risks are or what needs to be done.

Okay heres what I've done over the last few years, first the problem:

HISE products(especially those using samples) require a number of "additional" steps to any set up e.g. the Link file, putting the samples in a user-defined location, putting presets in the AppData folder as well as images, IR's, wavetable; files and any meta data, json or js files you want to ship with your product (the list goes on, and on, and on and - well you get the picture).

PackageBuilder, Packages etc and inno etc on windows dont really understand these locations, or any interaction required with the user whilst the install is underway - its possible but its fiddly and in my experience very time consuming.

So first I built a separate stand alone installer in HISE, it required the user to download one(or more) zip file(s) and point the installer at these...not massively friendly end-user tool, but it dealt with all the problems above....

Next I took it a step further and got it to use a defined manifest file(a json file) that allowed it to download its own zipped up content files (it asked the user where they wanted to put these temp files and cleaned up afterwards). So more friendly, and also on its way to being a "generic" Channel Robot Installer system that I could use for all my plugins.

Biggest outstanding problems: 3rd-party distributors (like Tracktion) and their insistence on using their own in-house installer systems and I'd never been able to get the installer to put the plugin in anything but the "user" plugin folder structure on MacOS.

So in the end it became clear that this read-a-manifest-down-load-some-files-and-install-them-where you-are-told componentry would fit inside the plugin itself pretty easily.

So my current system? Every plugin is a simple VST3, AU, AAX plugin that any 3rd-party installer can put where those plugins belong, so now you can use packages or whatever to put the plugin in the "system" plugins folder, or you can hand your plugins over to some distributor based system (e.g.Pulse) and they can install it their way....

When the plugin is fired up for the first time it recognises its not got all it needs and starts the download and write to disk process for all it's "content":

• it first asks where the user wants these temp file to be located
• it then asks the user for the Sample folder they want to use
• it then starts downloading, using its manifest to know what to download, and where to unzip it to
• once everything is downloaded it starts its own set up process
• puts samples in the user selected samples folder and creates/updates the link file
• puts images in the AppDat/images folder
• presets in the AppData/User Presets folder
• meta data in the AppData Folder
• tells the user its done and offers to clean up after itself, telling the user to just restart the plugin to get it all to work.

You could easily define more locations for "stuff" as you need it but right now the plugin set up componentry knows about these locations:

• sample folder
• images folder
• expansions folder
• Audio folder
• AppData folder

Here's a list of the constants it currently users for locations:

const var USERSAMPLE_LOCATION = 0;   // a user defined sample location - i.e. the contents of the LINK file location(folder)
const var EXISTING_LOCATION = 1; // whatever is in linkWindows/linkMacos (read, or write this if missing/empty)
const var APPDATA_LOCATION = 2; // the location of {APPDATA}
const var AUDIOFILES_LOCATION = 3; // Appdata/AudioFiles  -- for the Loops and HWT files
const var PRESETS_LOCATION = 4;  //  AppData/User Presets
const var EXPANSIONS_LOCATION = 5;  // APPDATA/EXPANSIONS/<the expansion name>  where the expansion json goes...dont forget to add the exp name ot teh install file
const var EXPANSIONS_MAPLOCATION = 6; // APPDATA/EXPANSIONS/<the expansion name>/SampleMaps
const var USERDOWNLOADS_LOCATION = 7;
const var IMAGES_LOCATION = 8;
const var SKINS_LOCATION = 9;

It turned into a pretty simple effort to extend this to allow download and install of expansions, and theses sell pretty well, here's an example page for Atmosia :

https://www.tracktion.com/products/atmosia

scroll to the bottom and you will see there are 5 expansion packs users can buy.

Generally its a pretty fail safe system and I get few support calls for it, maybe 1 in 100 (but that's a guess)

If the HISE shop ever gets up and running - I intended to offer it as a set of script files, widgets and guideline documents so you can add it to your own plugins.

@Lindon so as a work around you can create a Faust based FX and drop it into a Hardcoded Fx slot, heres the faust code for a simple FM FX (as provided by Gemini):

import("stdfaust.lib");

// Modulator Controls
modFreq = hslider("Mod Frequency [unit:Hz]", 100, 10, 2000, 0.1);
modOctave = hslider("Mod Octave Offset", 0, -3, 3, 1);
modDepth = hslider("Mod Depth", 0.2, 0, 1, 0.001);

// Calculate the effective modulator frequency using the octave offset
effFreq = modFreq * ba.semi2ratio(modOctave * 12);

// Modulator oscillator (sine wave oscillating between -1 and 1)
modulator = os.osc(effFreq);

// Convert depth to a delay modulation amplitude (in samples)
// A small maximum delay (e.g., 2ms) keeps the FM effect tight and clean
maxDelayMs = 2;
maxDelaySamples = ma.SR * (maxDelayMs / 1000);
delayMod = (modulator * modDepth + 1) * (maxDelaySamples / 2);

// Apply Phase/Frequency Modulation using a fractional delay line
fmEffect(x) = de.fdelay(maxDelaySamples, delayMod, x);

// Process stereo or mono input
process = _,_ : fmEffect, fmEffect;

I cant set the carrier and modulator manually , the one Im not setting flips back to unassigned, and programmatically assigning seems to set it only after a couple of compiles, and even then Im not sure it works, and if you try and set another synthesister group the first one unsets itself....

HiseSnippet 1338.3oc6Z80aaaCDWx1JnwsqaEHacOJTrGRGBBrT9iSwvPbhcbpwpSLhSa2acLRmiIhDoFEUVCF12s89dYeDxGg9MXiTxNlJV0wwKIKcS9gfv63Q8iGu62IdPcXTGHLjxzzKe3YAfl9iL5dFg2udeDln0pgl9iMZiB4.yLQz1mEfBCAWMc8h6JEnOeIs3eeXysQdHhCLRjl1anXG3UXeLejzN09ArmWSjKbH1WY1qVqkCkTm5QiD3onQEs.jyInig8PxoUvP6knv9Z5eqw5t8Pq6VcsJVvJa3V01p5ZuX0pqWoRO2MrpdT0iVA4hVuZEM841wEyortbDGB0zKsM08rt8o+BI4A7FbH9HOPNvRqq3ImHtI0yUtEk+uV89XO2NCcTgZhEsyH2VwD21BFswt3KjOx88EwJLGYgpCTuPZ3ULE7r9XvKCHoq.oRIP5IFccX3.9HMR77PiVDwoYOj3bREJIyUqvOUvnNULCBeYezIPSlXvEVrnvEujo3OO+6JWVbVExMOEwLiiXfPbHv1kQiBrL+9DYKeLviwZ7nEelxDMSl4yDqzXlubHv2hyY3ih3vhiqtNhwv.qEwEd+RVyxJzl5F4gDd9j0vdx6G6od+Xm09wdxnw9p2OW4JL99oWDwgioDSJYOJG1mr3yK+qkmu7uU17xp50KScxv.F0yCXYpVl6xljgKRh7OBXKIbodQvESTDelNnetoKn2IIpTYhTRKBlue.LX7nrVqLRQzFDVK9uW2pAhijYMCjIlW.v3XIbza.mJ3rRxgl2nADdBmFHXsFKASjZOzsqluKYEGnP3ORkjISjHgX9YprlWlDnzG2eTISNpL2sSIbehQGL2oe13sPF3U30tsw6.J0OyXmd8.G9HvVxn4ONQ9yabn74oJJFmrEijELFmJ6lnzXvTWZbGBRryZ1V8gnxinJOM6fBFp8ZBNjRnwPYKeZDgqZ2.sM.dDIEzGnna.CPtpVHQeWP.U23kLLUbdwzGVFSWde5zIk4eEEoevsUQ56z7y+4zIEmN3dEuSw7CwXWrefGrC4TvSvYNfCoAzCE4wuPpJHaKBTB5SIXG0HnC.QwriOFXpPOy8inrm3s.GIYgZG.d.JTIf7ap8JLAPLgaBlQWw0+0qx735qMRfqoL807+FUAJ9+9p.Sx08HiD5Q4g887SYQUrXB66IP8oIP8gFuEcJDWNMFkeY73dTlu4t.AXx8vjps9m270V22gKfvgLDILfFBVpqbWvGeHk.gojdIKryzhTRShZrFWTpYIcEMEtBk48fZCEZqJrChjZwDiSsRswpE9G75CIkp2OzQ3Xj9Y0y+NQdgvawt79Jq64JhsUE+RDSdonTb7Wtf+rS+NWds77hBeBUTPFC99OcJ++TCAEfsY7ws4+9m2GPi3XxwsQhWQTPZYrWjeWA2rCHPLg.dx6NnWPdi9jwUjiSXZItwC9KwuAJsji0GnzZnRUOyiGVGpq3kHGUG5qhGaJIamlBQu3ON+VuPjxB+6WTUI08xBglL3mOPd7oJuNEwxT0G1roXSloMcQ7HVbbvkuX3MIydobl8bl86CL62EjN2wDaWilWYOgWvVSKu4U4MuJu4U4MuJuZVdyqxad00s4U14Mu5Fs4UmuYdyqxuhSdQg7lWk27pqUyqrua+BExadUNydNyddyqtm8L7QNL56bR9FEi60RrDgukD+YFOuQa4XSKs3uaQ03HeQF76bbRuTiYn8rZ3JypgqNqFt1rZ35ypgUmUC23pMTRvtUDm5mPKHt1Pmch+PO00StwPbFn1ey11qGM

@dannytaurus
Perhaps report this - and your findings on the JUCE forums?

@dannytaurus said in Customer support software:

By the way, I think your 5% number is too high. I just checked and Wise will convert 1k EUR to GBP at a rate of 1 EUR = 0.8553 GBP with a fee of 4.78 EUR, which is more like 0.5%, not 5%. Maybe the fee varies by amount converted.

Sorry yes my typo...

@dannytaurus said in Customer support software:

@David-Healey I had Claude run my last 6 month's Gumroad sales through the Moonbase fee/surcharge matrix.

Moonbase came out at 12.6% (similar to yours) versus Gumroad's actual 17.6%.

But Gumroad's 'Discover' system brings in a percentage of my current revenue, which I will lose when I move.

If Moonbase do GBP holding at 1% (same as USD) it goes down to 11.8%. GBP holding at 0% (like EUR) takes it to 11.4%.

We found the easiest and cheapest way to manage these cross-currency costs was to set up a Wise account (you can add a truck load of different currencies incl UK, US etc) and let each service you are using deposit in its "native" currency and then manually do the exchange (costs about 5%). But this depends on your distributor/web site being able to drop monies into Wise

@Christoph-Hart said in HISE with Claude:

just fyi at this point the hise-cli contains the functionality of the mcp server and the lsp server so it's the all in one solution going forward.

so we'd just need to point Claude at the HISE-CLI then? (Asking for a friend)...

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

@ustk said in Measuring plugin delay times....:

@Lindon My process is to automate this from Hise itself.

You can write a test script that:

• loads the FXs one by one
• play a test signal
• record that test signal before and after the FX in 2 scriptFX module process callbacks (or 1 unique recorder with 2 passes, bypassed/unbypassed)
• perform a cross correlation between the two buffers to get the sample diff
• and populate an array that will hold the latencies per FX

Claude can easily create this for you if you need

And as @griffinboy said group delay can be tricky and give weird results, especially with impulses. I'd do it with white noise since cross-correlation is very effective with it (I do this in my Align-IT app)

do you have an example(snippet) of this cause I dont(yet) use Claude and its all new to me.

@Chazrox ok well this is getting a bit out of hand - I cant work out what Im getting, and its asking for a LOT of personal information....Im beginning to think this is a bad idea.

Okay, so I have a massive multi-fx plugin - there are 6 slots in it, and each slot can load any of the FX that ship with the plugin.

There are 133 FX.....

Yep, thats not a typo ... 133 FX.

Any of these can be loaded into one of 6 Hardcoded FX "slots", there are C++ FX, Scriptnode FX and Faust FX all in there....

So now I'd like my plugin to report to the DAW some consistent delay time...

So the plan is, nothing special here, to have a variable delay at the end of the chain....whos value can max out at the worst case scenario (6 copies of the worst "performing" FX loaded across all slots in the plugin), and to calculate every time a new FX is loaded what the current delay is - and add "make-up delay" to get us back to this worst case scenario - and thus always report this worst case to the DAW.

Now I realise that some of the actual delay any given FX induces may well be changable based on the params the FX are set at, the sample rate being used or even the type of content arriving at the plugin.... Im going to live with this inaccuracy.

Heres the plugin layout - its pretty simple:

So, to the question:
What currently the best way to measure delay induced by any given FX?

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

FOUNDERS100

So Im confused now, whats happening with the web-bazed solutions?

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

1. 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.
2. 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.

1. 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.
2. 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.
3. recursive, sendToHost and the global enablePluginParameterUpdate then become deletable. (deferNotifyHostFlag can stay - batching host notifications is an optimization, not a correctness guard.)
4. 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......

@Christoph-Hart yep, as soon as I can I will test it out, though I did send you a version of the project and I think the thread documents the problem well enough....

@Christoph-Hart - is there any chance of ever getting a fix for this?