God I hate my stupid brain sometimes.

So yes... that is exactly what it was....

In my c++ I run these smoothers for some parameters. To avoid discontinuities when turning a parameter. You generally don't want to flush 1000's of parameter updates on things like delay times, so you smooth it out over time. Maybe only 10ms, but it helps to make it sound better and brings down CPU too. Cool.

And that was all well and good. Worked fine.

But in my setParameter callbacks, I was only setting the target. I wasn't setting the initial value. Which now I read it, is literally the dumbest stupidest mistake that I could've made.

Time for more Guinness.

@David-Healey said in How do I flush the UI parameters on first run??:

@Orvillain said in How do I flush the UI parameters on first run??:

So now I'm thinking, maybe this is a custom C++ code or script node problem.

Could be...

ooooo... looks like it might be any of my effects that uses my ExpSmoothedFloat class to smooth the incoming parameter changes!

I've genuinely been slamming my head against this for the past 4 hours.... and it was nothing to do with the UI side after all... at least it seems like.

hmmm... no that didn't seem to work either.

Now, I might've been being dumb all along... but on a hunch, I tried a different effect.... and it seems like at least some of those parameters DO flush on init correctly... and some of them don't.

So now I'm thinking, maybe this is a custom C++ code or script node problem.

@David-Healey said in How do I flush the UI parameters on first run??:

Ok, what about using a timer that is started at the end of the callback, and in the timer you call .changed()

I'll give it a go!

@David-Healey said in How do I flush the UI parameters on first run??:

@Orvillain Are you calling .changed() from the menu's callback?

Yeah I am, there's no other callback to use right now.

@David-Healey said in How do I flush the UI parameters on first run??:

What happens if after this stage you call .changed for each of those components?

I get this in the Console:

Interface: Skipping changed() callback during onInit for grf_FXEngine1_FX1_Graph1
Interface: Skipping changed() callback during onInit for btn_FXEngine1_FX1_Sw1
Interface: Skipping changed() callback during onInit for menu_FXEngine1_FX1_Menu1
Interface: Skipping changed() callback during onInit for btn_FXEngine1_FX1_Sw2
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param1
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param2
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param3
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param4
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param5
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param6
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param7
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param8
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param9
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param10
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param11
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param12
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param13
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param14
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param15
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param16
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param1
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param2
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param3
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param4
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param5
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param6
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param7
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param8
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param9
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param10

@David-Healey said in How do I flush the UI parameters on first run??:

@Orvillain said in How do I flush the UI parameters on first run??:

run script init / callbacks

This is the important part. The last thing to run are the callbacks, in the order that the components appear in the module list.

So if you have a callback that sets the active effect, and then other callbacks that set the effect's parameter values, you might get what you want by changing their order.

oooooooo... I've just realised something .....

My generic UI parameters themselves do not have a callback assigned to them. IE: I never call uiParam.setControlCallback(blahblahblah)

I currently rely entirely on my effect load menu to do the following, and in this order:

1. Get the menus component id.
2. Derive the effect slot id string from the menu id.
3. Read the menu item text - force it to lower case.
4. Get the slotFX processor for the slot we want to address.
5. Look up the hardcoded effect name for the chosen effect; using a map that takes in the lowercase menu item, and returns the name of the hardcoded effect to load.
6. call setEffect(effectToLoad) on the slotFX instance.

At this point, my effect is loaded.

7. If the effect we loaded was the "empty" one, then just hide all of the parameters, and reset all of their attributes to blank slates.

If it wasn't "empty"... then do this:
8. Fetch the UI layout+binding spec for the effect.
9. Bind the generic UI controls to that effects parameters.

9.1 - build the UI prefix for the slot.
9.2 - collect the UI components.
9.3 - clear existing bindings.
9.4 - set processorId to the correct effect slot name.
9.5 - set the parameterId to the correct effect parameter name.

At this point, the knob does control the DSP.

10 - setup the other binding parameters (min, max, stepSize, colours, etc)
11 - Hide any UI widgets that were not used.

... so in effect.... my actual UI parameters within each of my effect slots, do not have callbacks themselves. I rely entirely on the menu... which thinking about it... feels a bit stupid.

Effectively, I'm relying entirely on HISE's attachment of processorId and parameterId - and I don't really know when that happens in relation to the callback.

As I say; my UI parameters always look correct. They sound correct when I load a preset. They do not sound correct when I load a DAW project.

@David-Healey said in How do I flush the UI parameters on first run??:

@Orvillain said in How do I flush the UI parameters on first run??:

I would guess that what is happening is, the parameters push through their values before the processorId or parameterId has been assigned.

Can you change the order that this happens? If it's all triggered by control callback then the order is based on the component list.

I'm not sure, but is that actually under my control? I imagine the order of operations that HISE uses is something like:
construct UI components
restore UI component values
restore processor graph / SlotFX state
run script init / callbacks

???

In my synth project, I have hardcoded effect slots. I have menus to load effects into them. I have a set of 16 generic knobs in the UI. These get bound to the DSP parameters when I load an effect - this is all triggered in my menu callback.

It all works. I open my menu, I load an effect. The UI parameters get assigned to the correct processorId and parameterId. Then I can control the effect on screen.

But, I save the project and reload it.... and my effect recalls correctly, and the UI positions of the knobs recall correctly, but the underlying DSP parameters are at their default values.

This only happens when saving the .xml project, or saving the host project in a DAW. If I save and recall a preset, then it all seems to work fine. Any ideas on what to look into???

The essential problem: I think I need a way to flush the positions of all parameters in the plugin, on first launch.

I would guess that what is happening is, the parameters push through their values before the processorId or parameterId has been assigned.

@Christoph-Hart Still experiencing this.

@Lindon

@Lindon For internet cool points of course!!

Start off with a tanh function.

Then put a high-pass filter before it. Set the range on the tanh to be quite high. 1-10 would do. Then tweak the high-pass cutoff and notice how it impacts the distortion.

Now add a low-pass filter after the tanh. Tweak the cutoff and notice how it cleans up the high frequencies.

Start from there.

@dannytaurus Do you know whether the mode used is resynthesis or resample?? Coz I tried the drag and drop thing, and the resulting wavetables did not sound great. Not as good as the ones I made in the resample mode inside Wavetable Creator.

Use this as a control callback on the menu:

    inline function populateSynthSoundMenu(component, value)
    {
        local wavetables = Engine.getWavetableList();

        if (!isDefined(wavetables) || wavetables.length == 0)
            return;

        component.set("items", JoinItems(wavetables));
    }

You'll also need this helper:

    inline function JoinItems(sa)
    {
        local s = "";

        for (i = 0; i < sa.length; i++)
        {
            s += sa[i];

            if (i < sa.length - 1)
                s += "\n";
        }

        return s;
    }

It means that each time you click the menu, it will update itself with the latest wavetable list.

Now each one of these can be resolved from the menu in one of two ways.

1. Use the menu 'value' to get the index of it in the list - indexes starting from 1.
2. Use the '.getItemText()' function on the menu component, to get the actual text.

Option 1 can be used directly with the LoadedBankIndex parameter. I don't know how that would slot into your project, but in principle this is how you'd do it.

@the-red_1 Right click your Script FX1 module and use one of those "copy reference" functions... there's usually one or two that pop up depending on what type of module is loaded.

@DanSound You should set the root note of your file to the same root note played when sampling the source. That will cure your transpose issue.

#pragma once
#include <JuceHeader.h>

namespace project
{
using namespace juce;
using namespace hise;
using namespace scriptnode;
using namespace snex;

/**
    Smallest possible BPM listener example.
    Demonstrates:
    - TempoListener registration
    - tempoChanged() callback
    - BPM flowing into the audio graph
*/
struct MinimalBPMListener : public data::base,
                            public hise::TempoListener
{
    SNEX_NODE(MinimalBPMListener);
    struct MetadataClass { SN_NODE_ID("MinimalBPMListener"); };

    static constexpr bool isModNode()            { return true;  }
    static constexpr bool isPolyphonic()         { return false; }
    static constexpr bool hasTail()              { return false; }
    static constexpr bool isSuspendedOnSilence() { return false; }
    static constexpr int  getFixChannelAmount()  { return 1; }

    // --- Tempo sync ---
    hise::DllBoundaryTempoSyncer* tempoSyncer = nullptr;
    double bpm = 120.0;

    // Exposed modulation value
    double lastOut = 120.0;

    // --- TempoListener ---
    void tempoChanged(double newTempo) override
    {
        bpm = newTempo;
        lastOut = bpm; // make it observable
    }

    // --- Lifecycle ---
    void prepare(PrepareSpecs specs)
    {
        if (tempoSyncer == nullptr && specs.voiceIndex != nullptr)
        {
            tempoSyncer = specs.voiceIndex->getTempoSyncer();
            if (tempoSyncer != nullptr)
                tempoSyncer->registerItem(this);
        }

        // Initialize output
        lastOut = bpm;
    }

    void reset() {}

    ~MinimalBPMListener() override
    {
        if (tempoSyncer != nullptr)
        {
            tempoSyncer->deregisterItem(this);
            tempoSyncer = nullptr;
        }
    }

    // --- Processing ---
    template <typename T>
    void process(T& data)
    {
        static constexpr int NumChannels = getFixChannelAmount();
        auto& fixData = data.template as<ProcessData<NumChannels>>();
        auto fd = fixData.toFrameData();

        while (fd.next())
            fd.toSpan()[0] = (float)lastOut;
    }

    int handleModulation(double& value)
    {
        value = lastOut;
        return 1;
    }

    void setExternalData(const ExternalData&, int) {}
};

}

This is a minimal example of how to get your custom C++ node to listen to the host BPM. Code above doesn't actually DO anything with the BPM information. But it proves the concept.

TBH, and certainly IMO.... Wavetable creation is not as optimized or fluid as it could be. The wavetable creator often crashes for no discernable reason, and the resynthesis modes do not sound as good as the resample mode does - when it works.

@dannytaurus Pretty similar to my fix above too. I just wanted a LAF solution rather than another panel hierarchy!