Once again @Bloodbat a big thank you. Yesterday I was thinking of trying something along your last suggestion (with “createBaseMenu”). I’ve added a “appendInfNoiseMenuItems” that I call from decendants “appendContextMenu” method and it works fine.
Regarding my first/initial question I decided on another implementation that better fits the way I am doing things. The way I am setting up my modules I’ll have them check various knob-positions, counting connected input/output, do certain calculations (based on knob-positions, and so on) either every 256 cycles, or if “mustProcessParams” is set true (e.g. done in “onReset” or when first loading up the module). In the same manner my modules have a process-quality setting (bit-pattern), which define how often the process “needs to run” (e.g. a slow-moving LFO don’t need to update at each cycle). This process is also “forced” execute if/when “processParams” have been executed:
void process(const ProcessArgs& args) override {
bool doProcessParams = mustProcessParams || ((cycle256 & patternProcessParams) == patternProcessParams);
if (doProcessParams)
processParams(ProcessArgs& args);
bool doProcess = (doProcessParams ||
((cycle256 & processQualityPatterns[procQuality]) == processQualityPatterns[procQuality]));
if (doProcess && portsInUse > 0) {
// Only perform when "needed" ("portsInUse" is set by processParams)
}
}
What I wanted to acomplish regarding my first/inital question, was to both set a variable (based on menu-selection) and at the same time set “mustProcessParams” to true (to force “processParams” to be executed). However “processParams” don’t need to be force-executed as soon as a menu-item is selected (every 256 cycles, is still 187 times per second at 48 hKz). But the new setting of that vairable (controled by the menu) should not “change” until after “processParams” have been executed, in order to prevent the process to use new values (set by menu-selection) until after “processParams” have been executed.
Hence I’ve decided on this following struct (to use for these menu-item values), that both have the “actual” value (that is currently used by process), and it have a “requested” value that is set/read by the menu. When the user selects a menu-item, only the “requested” value is changed, and process keeps using the “actual” value (that at this time remains unchanged). It is then the responsibility of “processParams” to update the actual value (set it to the requested):
template <typename T>
struct actReqValue {
T act; // Actual value used by process (e.g. each cycle)
T req; // E.g. Set/Read by menu-items (updates "act" each 256 cycles)
actReqValue(T value) : act(value), req(value) {}
inline void UpdateActual() {
act = req;
}
inline bool needsUpdate() {
return act != req;
}
}
By both having the “actual” and “requested”-values, I can in some cases limit the work that “processParams” have to perform:
void processParams(ProcessArgs& args) {
if (someVar.needsUpdate())
{
someVar.UpdateActual();
// perform various calculations based on the value of "someVar.act"
}
otherVar.UpdateActual(); // nothing to calculate, just update in case it was changed
}