Are plugins built against 2.51 compatible with version 2.41? And vice versa?
How about patches? Are patch files forward and backward compatible? If a 2.51 patch has stacked input, what happens whey you load it with Rack 2.41?
thanks.
4 Likes
Rack 2.4.1 will crash in any patch if you create it and stack inputs in 2.5.1
Stack on arm64 is:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x1814c6a60 __pthread_kill + 8
1 libsystem_pthread.dylib 0x1814fec20 pthread_kill + 288
2 libsystem_c.dylib 0x18140ba20 abort + 180
3 libsystem_c.dylib 0x18140ad10 __assert_rtn + 284
4 libRack.dylib 0x1053516c0 rack::engine::Engine::addCable(rack::engine::Cable*) + 868
5 libRack.dylib 0x1053533c8 rack::engine::Engine::fromJson(json_t*) + 964
6 libRack.dylib 0x1052b6744 rack::patch::Manager::fromJson(json_t*) + 672
7 libRack.dylib 0x1052b518c rack::patch::Manager::loadAutosave() + 236
8 libRack.dylib 0x1052b4d50 rack::patch::Manager::launch(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>) + 144
9 Rack 0x1044826c8 main + 3148
10 dyld 0x1811760e0 start + 2360
P.S. pretty easy to test 
ah, the age old argument - should one put asserts into a release build. i.e. let’s make it crash for the customers so they will report an error.
2 Likes
I’m lazy. Hopefully my other questions will get answered, too.
1 Like
Hey guys…I probably have this compatibility problem which I described before. Now I have sent VCV an email about this compatibility problem between 2.41 and 2.51. Let’s see what these gentlemen have to say.
Looking at the changelog I’m not quite sure what this means:
Add parameter value functions
gaintodb()(gain factor to decibels),dbtogain(),vtof()(1V/octave voltage to frequency), andftov()
But if it’s something that can be used in the coding of a plugin, then I guess it can be made incompatible with earlier releases.
Yeah, easy answer confirmed above - using that feature makes it incompatible with earlier releases.
There really should be a compatibility log somewhere…
Got an answer from one gentleman:
“there is no way for older versions of Rack to “see into the future” to be able to adjust behavior to features enabled by newer versions of VCV Rack 2. Backwards compatibility is something we aim for, but, unfortunately, future compatibility would stifle development of new features.”
Not all clear now…for me. Can someone send me a small patch with stack inputs. I am still on 2.41. Thanks so much.
Here is a 2.5.1 patch with stacked inputs:
stacked_cable_example.vcv (953 Bytes)
It looks like this:
As expected, it crashed. Now I have to live with this problem. Or do an update. Thanks, Don, for your help.
1 Like
Do you understand the nature of the crash yet? Is it because of your code or VCV Rack code? I, and I’m sure other developers, will be interested to know what you discover about this topic.
[EDIT] The stack trace above looks like it’s totally VCV Rack code, so there is no way we plugin developers can work around this.
It would be technically feasible for Rack to include the rack version when saving a patch and warn when opening a patch saved from a “future” version. It could give options to go ahead (possibly crashing) or to cancel.
At the very least Rack should validate it’s input and refuse to load one that uses features not implemented in that version. Crashing is a bug and poor user experience.
2 Likes
Compatibility of plugins. I’m pretty sure that from time to time VCV and the build system are updated to make sure that the c-runtime expected by the plugin module is the same as the c-runtime provided by VCV. I think this issue comes up most in Linux? Or maybe I have this wrong. In any case, I think sometimes when a new version of VCV comes out then all (or some?) of the plugins need to be re-built.
Hence my question: will a plugin built for VCV 2.4.1 or 2.5.1 work fine with 2.5.1 or 2.4.1?
@baconpaul - didn’t you have an issue with versions of plugins and versions of rack? Or was that just versioning between plugins and the API exposed by rack?
Yes, there should. But also it shouldn’t crash. Surely you don’t disagree with that?
Yesterday @fractalgee tested the issue in question, and provided a crash log that looked to me like an assertion was firing and causing the crash.
Assertions are statements intentionally put into code to find programming errors. A silly example might be assert( 2+ 2 == 4); More often they are “assert that copying this memory will not corrupt other memory” or even more common “Something seems weird or unexpected here. I have a bad feeling”. In any case, when as assert fires and a developer is running in a debugger, then the developer can see exactly what the problem is. If the assert fires “in the field” then the application will crash immediately, and hopefully the customer will provide a crash log and the developer can fix the issue.
As I said earlier, there is wide disagreement over whether assertions “should” be enabled in releases of software. The competing considerations are: if you leave them in, then you can catch what might be a very difficult to find bug, and fix it. The counter argument is that it may be a bad idea to intentionally crash the user’s program.
Myself, I always remove assertions from releases. Both at work and in my VCV modules. It’s difficult at work, as we often have to integrate third and second party software into our apps, and it can be a pain to get someone else to remove the assertions from their library. If the assertion is in the app itself it’s a lot easier: ask that assertions be disable in the release build. If someone refuses, just tell them they have to talk to customers on the phone when this happens.
I was about to say the same thing. So I will anyway!
Document reverse compatibility – many software devs are already painfully aware of these issues. so the post is mainly for others who might not be as knowledgeable.
When an application is asked to load a document a document from a more recent version of an application, there are several things is can do.
- Predict the future and load all things in the document and then function exactly like the more recent version would. Unfortunately it is notoriously difficult to predict the future.
- The software may be pessimistic and tell the user “This patch is from VCV 2.51, and you are running VCV 2.41, so it can not be loaded”.
- The software may be optimistic, and try to load it without alerting the user. Within these are various variations. Option 2b might be “This patch is from VCV 2.51, and you are running VCV 2.41, so it may be impossible to load with full fidelity. Press “ok” to attempt to load”.
Option 3b might me to be optimistic but be very careful to avoid bad things happening. This is probably the approach taken by applications like Microsoft Word, Google docs, or Adobe PDF reader. Option 3c might be to try to load the document, but then intentionally crash if the app sees any new data that it does not understand.
Option 3b-II might be to try really hard to avoid bad things happening, but when they do, put out a version of the old app that fixes the bad thing (for example VCV 2.4.2).
Having worked on many applications that load data like this, I have probably tried almost all of these approaches. It’s of course up to an individual developer what approach they want to take to this very common dilemma.
I actually suggested that when sending that crash log to support yesterday just after posting it here.
2 Likes
For now, I guess we all need to know not to share/publish patches containing stacked inputs. It’s basically a denial-of-service attack for at least half of our audience.
3 Likes
do you really think half the users are sticking on 2.4.1? I have no idea, I would have guessed less…
I am until there is a compelling (ie showstopping) reason to upgrade.
1 Like