Given added CPU draw of 2.5.1 on any 2.4.1 patch the answer is ‘likely’. It is far from insignificant.
I also suggested they don’t release a version of something that uses way more CPU on identical patch as older version, as older version patch uses none of the new features.
I don’t know either, but I’m sure there is an adoption curve still in progress. Let me restate it this way: I don’t know when it is safe to publish a patch (say on PatchStorage) that includes stacked inputs without someone’s VCV Rack crashing.
@Squinky, yep, here’s the assert in 2.4.1:
// Check that the input is not already used by another cable
assert(!(cable2->inputModule == cable->inputModule && cable2->inputId == cable->inputId));|
@pachde, a very similar approach would be a needs_version indicator saved with the patch. That would also handle the exact situation here, which is that some but not all 2.5.1 patches are backwards-incompatible. To specify: if needs_version had already been implemented in earlier versions, 2.5.1 (when it’s serializing the patch) could add needs_version = "2.5.1" if and only if stacked inputs were actually used. No false positives that way.
That would also be a reasonable way to go. It would be burdensome on Rack to “know” all the things it did, and in what version they were implemented. But it would work. I’m not sure that’s the approach I would take, but that doesn’t mean it’s not a good one.
When the smooth param api was deprecated a few of us had a concern that because the old function was also changed there was no way to write a plugin which worked in 2.2 and 2.3. Looks like with the new exported symbols here (gaintodb and stuff) if you use those in your plug my guess is you will get a failure-to-load in 2.4.1. This is always the case with new symbols.
oh, ok, so the issue was not compatibility between plugins and the std c++ runtime. tx.
I have a general problem that the macos runtime requiring osx 10.9 precludes me from bringing some of our code to rack but that’s a different version requirement issue.
yes, a different issue, but of course related in that VCV modules require you to use the same runtime.
exactly–it saves you from needing a time machine (or alternate versions, like the 2.4.2 you suggest), but it requires an exact grasp of the history. Rack does have fairly infrequent version bumps and only a few backwards compatibility breaks so far (AFAIK), so maybe it wouldn’t get too complicated to maintain in this case.
I was referring to the text coming right after, from the changelog:
" Add parameter value functions gaintodb() (gain factor to decibels), dbtogain() , vtof() (1V/octave voltage to frequency), and ftov()"
I don’t know whether this implies a potential incompatibility or not.
I don’t
I’m just confused. Why were these not in the API section of the changelog, if one can use it for plugin development? Are you sure this is something related to plugin development?
Good morning,
Ok I am not a coder, just a very simple user with just 7 months experience in VCV rack. I can’t solve the problems myself. I can only watch how other people try to work around the problems, which is of course a great thing. The only point I can make is that this update has brought a lot of issues. First of all I don’t see the relevance of stacking cables and then the trouble with CTRL-SHIFT? Then why the cable colour stuff. We have so many other modules that already do the same thing. And now the compatibility between the two versions. I tell myself always. “Never touch a running system” By the way, I have seen several patches with stacked cables.
Sh…t UpDaTe???..I do not know…
i was wrong and had misread the changelog.
I see now. These functions are functions added at runtime to the tiny expression parser, not to the C++ SDK. My mistake.
So presumably a patch using one of these would fail to run properly in an older version. But a plugin has no access to them.
I just did a build of airwin2rack with the 251 SDK and loaded it into 241 just fine, if that helps.
just tried this with current Cardinal, it loads without crashing 
There is an assertion printed for the error:
[dpf] assertion failure: "!(cable2->inputModule == cable->inputModule && cable2->inputId == cable->inputId)" in file override/Engine.cpp, line 995
but it does not trigger a crash or abort the program.
I always felt that crashing the whole program is quite the nasty behaviour, best to just log an assertion and return an error.
The lazy approach of simply calling assert() doesn’t feel right, the log is useful when debugging but almost never on runtime. And outright removing the safety check on release builds feels bad too.
So my approach to this is typically “assert badly if debug build, otherwise log an error and try to keep going”.
Glad to see a real case where this stance has been useful.
So, uhh, if staying on 2.41 for the time being (too many problems reported with the newer version at the moment, and it wants to move the data to different locations, so… meh) is it “safe” to update the modules that hit the library yesterday? 
I do have my VCV folders backed up, and just thinking out loud, are there potentially compatibility breaking aspects in the plugins themselves already, if they are built very recently, making them not co-operate with 2.41?
I see, that makes sense now.
I’m not sure “a patch can use them” as such, and if you type in an expression on a control I don’t think it leaves any traces in a patch. I believe the tinyexpression facility is simply a bit of usability sugar, that we can use to conveniently convert common values (e.g. “C4”) to CV.
Agreed! Sometimes it’s the only thing you can do but best avoided.
It should be. The only incompatibility would be in any patches made with Rack 2.5.x using stackable inputs, they will crash Rack 2.4.x and earlier.