I think I have found an unfortunate side effect of the change. I just updated my Rack to 2.3.0, and now I am getting inconsistent behavior from my patches that use Mind Meld Patch Master to remotely control other module parameters. For example, in my Benjolin patch I have a knob that is supposed to control the rate of change to the Benjolin patterns. At fully counterclockwise it should be -5 V, meaning always preserve the shift register values, resulting in a rock steady 8 step pattern. And fully clockwise equates to 5 V, meaning always invert the value, resulting in a rock steady 16 step pattern. Values in between introduce variability. But now the extremes are giving me values of ± 4.9xxxx, and the patterns are no longer locked. The exact values are never quite the same. Before the 2.3.0 update, the Patch Master was very reliable.
I have submitted an issue to the Mind Meld plugin github.
I’m instead calling setScaledValue(), and since there is no setImmediateScaledValue(), to fix the issue I’ve changed line 423 in PatchMaster.cpp from this:
effectively implementing my own version of what should be in setImmediateScaledValue() if it existed.
I think for consistency given the last changes in 2.3.0, @Vortico could perhaps consider adding methods called getImmediateScaledValue() and setImmediateScaledValue().
For example, setImmediateScaledValue() could be this:
Just curious as a fellow module developer… what happens if someone with an older version of VCV Rack downloads the newer plugin that tries to call setImmediateValue, which didn’t exist in that older version of VCV Rack? Sounds scary, and possibly breaks compatibility?
Interesting question, I’m not well versed in these kinds of things, so I hope someone else can chime in, it would be good to know the answer. Of course, I’m sure Andrew has thought of that when making the changes, and so it’s surely ok, but as for the mechanics of things, I’m definitely curious also…
No worries. I think I can just download SDK 2.3.0 in a different directory and build your stuff from source. Let me take a whack at it. I really want to know what happens!
My wager is that it will work, and the trick is likely to keep all the binary interface the same (ABI), so that if what’s already there has the same “foorprint”, so to speak, but we just change method names and add extra methods at the end, then it will work. And so perhaps setImmediateValue() is now in the same memory place as the original setValue() and the new setValue() is in the same place as the former setSmoothValue(). Going out on a limb here, but I think that’s the thing here, and Andrew would not have made a massive change that breaks things in a minor version change. If he added completely new code to Rack, then it wouldn’t work, but this is more like renaming things I believe.
Wow, got me there. This means that as soon as we push this update to the library, users must be on version >= 2.3.0. to use MindMeldModular. Interesting…
