Different filter response between editor and compiled plugin

[dannytaurus]

Here's an audio clip of 3 notes playing in the compiled plugin, then the same 3 notes in the editor.

Notice how the filter closes much more on note-off in the second set of 3 notes (editor). Which I believe is the correct behaviour.

https://f000.backblazeb2.com/file/meat-beats-links/Logic-versus-HISE-filter-difference-Rel-30.wav

Any ideas what's happening here? Claude is investigating. Just thought I'd ask in the meantime.

EDIT: hopefully goes without saying the settings are exactly the same in the compiled plugin and the editor. The notes are different lengths to rule out any note-length influence.

[ustk]

@dannytaurus Just throwing this in the case it might be related, I reckon there was a preprocessor for the filter or EQ to use the SVF, so perhaps something to check if Hise is in a certain state and compiled plugin in another

[dannytaurus]

@ustk Good instinct! It is indeed caused by a preprocessor mismatch between editor and export, but not the SVF one.

UPDATE: this is not a HISE bug. It was Claude sneaking in a preprocessor without taking the necessary steps to make sure if flows through to the export. It already had those steps in memory, just didn't do them

Claude's words (now partially invalid):

The editor and exported plugins apply filter modulation on different frequency scales.

The HISE Standalone app is built with HISE_LOG_FILTER_FREQMOD=1 (it's set in projects/standalone/HISE Standalone.jucer). The library default in hi_dsp_library/hi_dsp_library.h is 0, and an exported plugin only gets the defines from the project's ExtraDefinitions, so unless you add it yourself the plugin is compiled with 0.

The flag decides how the Frequency modulation chain is applied to a filter's cutoff (MultiChannelFilters.cpp, FilterHelpers::RenderData::applyModValue):

• 1 (editor): the modulator value scales the cutoff in a log/skewed frequency domain
• 0 (export): plain linear multiply of the cutoff in Hz

Same project, same envelope, very different result. Simple repro with a PolyphonicFilter at 20 kHz and a FlexAHDSR in its Frequency chain with slow attack, slow decay, 50% sustain level and slow release:

• Editor: the filter display rises from 0, decays to about 50 % of the display (roughly 630 Hz) and releases back to 0
• Exported plugin: rises from about 50 %, decays to 90 % (10 kHz, i.e. 20 kHz × 0.5) and releases to about 40 %

That's exactly what was in the audio clips in my first post: the plugin's envelope spends most of its travel in the top octaves where nothing audible happens and then falls off a cliff, so it sounds snappier, and the release sounds cut short. It also affects LFOs on the cutoff and the bipolar frequency chain, so it explains a bunch of small "it sounded different in HISE" quirks I'd been putting down to my ears.

The fix for a project is one line in Project Settings > ExtraDefinitions (both OSX and Windows):

HISE_LOG_FILTER_FREQMOD=1

Re-export and the plugin matches the editor. The editor can't be changed from the project side since it's a plain compile-time #if, so aligning the export is the only option.

Suggestion for @Christoph-Hart: the comment on the define says it's off by default "for old projects in order to keep the sound persistent", which makes sense on its own. The problem is that the editor and the export currently get different defaults, and nothing flags it.

Two possible fixes:

1. Have the exporter emit HISE_LOG_FILTER_FREQMOD=1 whenever the editor itself was built with it, unless the project explicitly sets it to 0. Then what you hear in the editor is what ships.
2. Expose it as a Project Setting with a visible default, so opting out is a deliberate choice rather than something you discover by A/B-ing against the export.

As it stands, anyone with filter modulation in their project is shipping a different curve to the one they voiced against, and it's subtle enough that most people won't notice until they compare closely.

[David Healey]

@dannytaurus said in Different filter response between editor and compiled plugin:

The problem is that the editor and the export currently get different defaults, and nothing flags it. Two possible fixes:

I thought you had to build HISE with the flag in order to get it within HISE?

[dannytaurus]

@David-Healey It's in HISE by default, unless you disable it yourself. The problem is that the default in the editor doesn't get set as the default on the exported plugin.

[David Healey]

@dannytaurus said in Different filter response between editor and compiled plugin:

It's in HISE by default,

I see it in your fork:
https://github.com/weavermedia/HISE/blob/meatbeats/projects/standalone/HISE Standalone.jucer#L335

But I don't see it in Christoph's upstream:
https://github.com/christophhart/HISE/blob/develop/projects/standalone/HISE Standalone.jucer#L333

[dannytaurus]

@David-Healey Good catch!

This is not a HISE bug. Claude enabled HISE_LOG_FILTER_FREQMOD in my own fork's standalone jucer back in July (to get the log modulation curve in the editor) and forgot about it..

What does still hold, in case it's useful to anyone building HISE from source with modified module options: anything you change in the standalone jucer's JUCEOPTIONS only affects the editor. Exports take their defines from the project's ExtraDefinitions, so you have to mirror the option there or you'll voice presets against one curve and ship another. That was my whole "bug".

Side note: I've noticed Claude getting a lot worse in the last couple of weeks. Even Fable 5. Way too wordy in responses (gobbling up those output tokens) and missing more things than it did before. Making bad assumptions too. And overstepping when I ask for a discussion and it just starts coding.

Now to retract a bunch of Claude's stuff in my earlier post...

[David Healey]

@dannytaurus Yeah I always ignore most of its output and just ask it to give me a summary once it's finished blabbering away. I aint got time for it. :D

This thread brought the preprocessor definition to my attention though so I've just enabled it in my fork by default, and for exported projects: https://github.com/davidhealey/HISE/commit/565865a3ca8808f89c0d9054ea607a5b796c711d

[dannytaurus]

@David-Healey I've found it rock solid for months, but just recently it's got worse.

I think it's trying to over perform, which ends up being annoying in the end.

Lots of people moving from Claude to Codex, Grok, etc.