rolling back Max to 8.5.4 resolved an issue with JUCE not seeing RNBO parameter updates.
I've been using the rnbo.example.juce project for my plugin for months.
In an earlier version of Max the GUI would update when parameters in RNBO would have their values change programmatically without user input. RNBO would generate a new parameter value, and it would be reflected in the JUCE GUI. Great.
In the current Max version I noticed that's not happening. Parameter changes from within RNBO are not reflected in the JUCE GUI until the plugin instance window is closed and opened again. The parameter change is not updated in the DAW host either.
I spent a whole day trying to debug C++ code for the JUCE example, only to find that rolling back the Max version and exporting and rebuilding fixed it. Perhaps it's a problem with updateSliderForParam
So this seems like an unintended change if not a bug! I'll be using version 8.5.4 in the meantime!
The latest version of RNBO attempts to fix some issues with automation that previous plugin exports have. We've changed the default for a parameter notifications and added metadata to allow for altering those defaults: https://github.com/Cycling74/rnbo.adapter.juce/blob/dd233609adc495828fa9efcf756ab2a155a3bd1d/RNBO_JuceAudioProcessor.cpp#L144C5-L148
I believe you should get your old behavior if you define RNBO_JUCE_PARAM_DEFAULT_NOTIFY in your build process.
Here is some more information about the metadata: https://rnbo.cycling74.com/learn/using-the-vst-audiounit-target
Well, that's pretty cool! I missed the memo :)
I just added the metadata to the parameter I needed and I'm good to go, thank you!
edit: But now presets don't recall until the window is reopened... well, more to do.
As the plugin is no longer recalling save states or presets properly, I would like to follow your advice and "define RNBO_JUCE_PARAM_DEFAULT_NOTIFY in your build process." I haven't figured out how to make that work yet. I tried putting "set(RNBO_JUCE_PARAM_DEFAULT_NOTIFY TRUE)" in the CMakeLists.txt file, but that's not working... Any tips?
In the meantime I've added the metadata to each object individually, but with this global change, was there any other change I should know about that would allow saves and presets to be recalled?
Here is an example compile definition:
https://github.com/Cycling74/rnbo.example.juce/blob/cab65fd46cc1398152f088c82f0ac4cc61388c95/CMakeLists.txt#L54
What you did only sets a definition within the cmake build setup, it doesn't actually become a `#define`
you can expand the one i linked to:
add_compile_definitions(JUCE_VST3_EMULATE_MIDI_CC_WITH_PARAMETERS=0 RNBO_JUCE_PARAM_DEFAULT_NOTIFY)I'm curious to know how presets behave after you do this. There is something going on with presets in the latest rnbo code that I haven't quite figured out yet, I'd like to know if you're still having issues after this or not.
Thanks! I've implemented that as above, which works as expected which is great!
EDIT: I had to delete and rebuild builds and exports, but it's all working as expected now.
Yeah, re-exporting the source code is expected, some of the codegen/interface likely changed between your previous rnbo version and the latest.
I'm happy to hear that this new setup is working for you. So, presets work okay too?
BTW, this thread was a good reminder that I hadn't actually merged the juce template develop back into main for this release.
I have a cmake cache variable already set up to do all this there now: https://github.com/Cycling74/rnbo.example.juce/blob/299823760bdd28f2f73d525479844b2b306b4bd7/CMakeLists.txt#L26
So, for future readers, you can simply change the value of that instead of augmenting the build as suggested above.
Yes, presets seem to be working as expected, thanks again Alex!
So there are no other changes in the latest juce template I should look out for? Any straightforward way to get a buffer from RNBO to JUCE for analysis GUI? I know there's a workaround that's still slightly over my head. That's the next step for me.
Happy to hear that this is all working for you!
I don't think there are significant differences in the template.. you're probably good with what you have.
RE buffer output, I'd start a new thread with that topic and see if anyone has something to say about it?