Latest version of HISE breaks existing presets....

[Christoph Hart]

Guys I really need more to work with. Just stating "it breaks older presets" or "it seems to be upsetting HISE" gives me absolutely no idea what to look out for. I get it has something to do with macro modulation and plugin parameters, but it's a shot in the dark until I get more context.

• what does break
• ideally a snippet, if not a DETAILED list to reproduce the setup
• what does break mean? crash? values not restored? weird couplings between UI elements?

Ensuring backwards compatibility is the number one priority of all bug reports, so I'm on it as soon as I get enough info.

[David Healey]

@Christoph-Hart I think this one https://forum.hise.audio/topic/14165/latest-version-of-hise-breaks-existing-presets/26?_=1777890110567

[Christoph Hart]

@David-Healey yes I saw that - the reason for this is that HISE registers all macros as plugin parameters in the backend by default which then loop back to update their value.

It should not affect exported plugins though, but it's definitely a weird glitch that I'll look into. Is this a regression? The backend macro -> plugin parameter connection is ancient (about as old as HISE).

[David Healey]

@Christoph-Hart said in Latest version of HISE breaks existing presets....:

Is this a regression?

Yes it didn't happen in earlier versions. It came in this commit I believe.

[Christoph Hart]

The code that sends the macro value as plugin parameter is already in HISE 4.1.0.

What changed in that commit is that HISE registers a plugin parameter at index 0 for the UI control (basically what the compiled plugin is doing) so before that value was sent out to nirvana (or the DAW if HISE runs as a plugin), but now it loops back to the first UI component that is defined as plugin parameter.

HISE_MACROS_ARE_PLUGIN_PARAMETERS=1

This solves the problem my registering the 8 macro controls as plugin parameters, so changing the first macro just changes the first plugin parameter (=macro) => no op.

So the proper fix would be:

if USE_BACKEND && HISE_MACROS_ARE_PLUGIN_PARAMETERS==0 => don't send the macro value as plugin parameter

if USE_BACKEND && HISE_MACROS_ARE_PLUGIN_PARAMETERS==1 => send it

Note that the compiled plugin is completely unaffected by this. All it would break is the behaviour of HISE to send out macro values as plugin parameter without that flag.

[Lindon]

@Christoph-Hart do you want a copy of my project to test with?

[Christoph Hart]

@Lindon yes but please give me some guidance on what to look for. Also if you can dumb it down so I don't have to download gigabytes of samples, would be great.

[Lindon]

@Christoph-Hart I know its a long way back but if you look at the first three or so posts in this thread I think that does dumb it down , and explain exactly whats happening.... let me know if thats not enough, I can send the project without the samples - as Im pretty sure they wouldnt be needed to see this problem anyway....your call.

[Christoph Hart]

@Lindon yes send over.

So your particular problem is that plugin parameters + macros + preset recall is not working (mastervolume +30 = 1.0 normalized)?

[JulesV]

@Christoph-Hart When I open a project previously saved in a DAW using a plugin compiled with 2024 commit HISE (I only tried in Reaper and Logic on macOS), with the same plugin compiled with new HISE, the saved settings are not loaded in the DAW. The plugin is loaded with the default state.

[Christoph Hart]

@JulesV Are you using plugin parameters? And is this affecting only controls that are linked to plugin parameters or all values?

[JulesV]

@Christoph-Hart In the plugin, all controls are set to plugin parameters. Also most of them are set to isMetaParameter. And all controls are initializing with default values