What Can Make a Component Callbacks Execute When Defined?

[clevername27]

@griffinboy Thank you - this is my concern. Is there any further clarity anyone can offer here?

[d.healey]

@clevername27 What's the issue you are having?

[clevername27]

@d-healey Some control callbacks seem to be executing when they're defined. At first, I thought I had mistyped my question—but I had it right the first time. If there is no default preset, then callback shouldn't fire, because there is no preset to read from. (Thank you for your reply.)

Already, broadcasters seem to be misfiring when they're defined—twice.

And something…I don't know what…seems to persist even after my plugin halts.

[d.healey]

@clevername27 said in What Can Make a Component Callbacks Execute When Defined?:

then callback shouldn't fire, because there is no preset to read from

If they have saveInPreset enabled then the callbacks will be triggered after on init completes. This is unrelated to a default preset being set or a custom preset system being used.

[clevername27]

@d-healey Thank you for the clarification. Do you know how why this is a sensible thing to happen?

[d.healey]

@clevername27 said in What Can Make a Component Callbacks Execute When Defined?:

Do you know how this is a sensible thing to happen?

I'm not sure what you're asking.

[clevername27]

@d-healey How is this not a bug?

[d.healey]

@clevername27 It's the intended behaviour, always has been.

[griffinboy]

@clevername27

It's not a bug because it's simply the parameters setting themselves.
I think that the xml or project itself has the knob values stored, and when opening this / compiling, each ui element goes through and sets itself up.
It's likely just the design of Hise. If it didn't, each knob would have nothing in there.

But yes, it means that making call-backs becomes tricky if you don't want the initial setup to trigger your code.

[clevername27]

@d-healey @griffinboy I appreciate that (and you both sticking with me on this). I'll rephrase -

In this context, a control callback is a function that is executed when a component is accessed. That can happen in one of two ways:

1. The user accesses the component. The value of that component is correct because, in this context, that is defined by what the user chose.

2. If the component is flagged to be saved in a preset, then the correct value is whatever was defined in the preset. But if there is no preset to read that from, then the value cannot be correct—because there is value to restore.

@griffinboy I hear your rationale. But if that's not a bug, it's something far more serious. (Or, I'm missing something.)

[d.healey]

@clevername27 said in What Can Make a Component Callbacks Execute When Defined?:

if the component is flagged to be saved in a preset, then the correct value is whatever was defined in the preset. But if there is no preset to read that from, then the value cannot be correct—because there is value to restore.

It will use the value stored in your project's XML, this is also the initial state that will be seen when you compile your project.

For example in this project the slider "knbVibratoRate" will be set to 64 when I reopen the project or when the user loads a new instance of the plugin - https://codeberg.org/LibreWave/BellAndBone/src/branch/main/XmlPresetBackups/bellAndBone.xml#L26

[clevername27]

@d-healey I appreciate the extended information, and will move on. Thank you both for helping me out here, I (sincerely) appreciate it.

[griffinboy]

@clevername27

When the ui elements get created (plugin was not loaded into daw, one becomes loaded into daw) it needs to create all of the ui elements and set them to the correct values.

Settings them to the correct values triggers the callback because the values have been changed.
This can be an advantage depending on the way you've scripted it.

[clevername27]

@griffinboy Thank you.