Fix presets being set and state restore

[yamadapc]

This PR tries to fix an issue where preset changes and state restore are not working with RNBO v1.2.0 due to a fix to 'notifying' parameters, that will make it so that certain parts of RNBO state aren't updated with the new parameter values on those two scenarios. I need to test further to see if this will address the issue and am not familiar with the bigger picture of this project to tell if it'd be okay or problematic for rnbo.getParameterValue to return a different result than the state objects or parameter values.

I'm not sure if preset handling will be totally correct with this change since the parameters would not be notifying the hosts depending on how they are called.

RNBO::JuceAudioProcessor::setCurrentProgram does not set _isSettingPresetAsync as far as I can tell. Therefore parameter change events for setCurrentProgram and setStateInformation are being dropped.

This change makes it so that these events aren't dropped but still skips notifying hosts. Perhaps a more robust change could be to set a flag while the setCurrentProgram and setStateInformation run and handle them in the same manner as "_isSettingPresetAsync".

I might be totally wrong about the whole thing as well!

This fixes the test suite referenced in #2.

Closes #2.

• rnbo.adapter.juce/RNBO_JuceAudioProcessor.cpp

  Lines 412 to 421 in dd23360

  	void JuceAudioProcessor::setCurrentProgram (int index)
  	{
  	if (_presetList) {
  	_currentPresetIdx = index;
  	if (index >= 0) {
  	UniquePresetPtr preset = _presetList->presetAtIndex(static_cast<size_t>(index));
  	_rnboObject.setPreset(std::move(preset));
  	}
  	}
  	}

All the best, happy patching

[x37v]

I think this workaround shouldn't actually be needed once we resolve 18483 in rnbo's ticketing system

[yamadapc]

Hey, this issue is still present in v8.6.0.

Additionally, now it seems a new zeroed preset is getting output after codegen. The extra preset is output even if the preset.json only contains one item.