Essentially, some of these sea changes to hardware historically have been really painful. IMHO Apple did an amazing job with the M1/ARM transition (especially the quality of the emulation of Intel code). And before that, the migration to 64-bit, in terms of what was within their control (which could not entirely mitigate client code that was just not safe on both 32- and 64-bit systems). The “endianness” issue (the order in which multiple bytes are stored for types larger than 8 bits, including integer and floating point types) was when Apple moved from PowerPC to Intel chips, and again that was not something they could entirely mitigate. We still have to deal with that since the AIFF format is Big Endian and WAV (along with Intel and ARM chips) is Little Endian. It is much more of a PITA than the current change. But assumptions about memory ordering regarding atomic operations is perhaps a subtle thing we need to keep an eye on.
Something has come up where I’d like to change a parameter from within the processor (and have the gui update etc.). For a laugh, I tried doing
*param = newValue;
on the atomic (derived from getRawParameterValue) and to my surprise it worked!
- why is it a bad idea to do *param = newValue; ?
- am I correct in thinking that setValueNotifyingHost should be only used in the editor and setValue can be used in the processor?
- what is the correct way to use setValue? I’ve never had to use that before
Now I am as surprised as you are.
Maybe I have to revisit that statement. I am curious what happens under the hood.
The host controls if a value is accepted or not. That’s why your processor shouldn’t call setValue(). The reason are the different automation modes. If the automation is set to read, no value change from the plugin should be accepted.
The flow is you are calling from the knobs setValueNotifyingHost(). The host will then in turn call setValue(), if the automation allows that.
The problem is, some hosts don’t implement automation at all. That’s why the wrappers call setValue() as a fallback. I haven’t dug into it, how it decides if to send it or not.
Third remark: To know in that flow, which setValueNotifyingHost was due to touching a knob or calling a preset, a meta parameter or whatever could have triggered it, you are supposed to call beginChangeGesture when a knob is touched. It is also important for the “latch” mode.
My understanding is, that you should never call setValue, always call setValueNotifyingHost instead.
But I am happy to hear more about that. I think there is a lot to learn for me as well