I’ve been using the rack binaries for v1 for sdk and runtime since the weekend. I have a little bash script that downloads them and sets the path and runs and everything including making user dir and running rack with the right args and stuff. If you want that’s in GitHub.com/surge-synthesizer/surge-rack in the scripts directory. Should be straight forward if you know bash
Are you on Mac? I could also try windows 10 or linux if you want but not now - I’m headed to dinner.
I used your script @baconpaul to get the SDK and I still get a crash on restart, sometimes a crash on add, and sometimes a gray bpm knob and crash on click. So I am having all kinds of fun. If I add modules with no knobs they seem to work fine. And, why does it work for you? I have no idea what is going on.
I suspect it is something related to first initialization of paramQuantity when using old style code (using the rack0.hpp).
In some way the paramQuantity is not correctly inited and contains an invalid pointer.
I’ve successfully migrated about half of the modules in my plugin to v1 without ever using the compatibility header. Maybe you could try skipping straight to the rack.hpp include for the module that is giving you trouble. It looks like your plugin uses a lot of shared components from your JWModules.hpp. I use a lot of shared components as well and I ended up commenting out everything I could to fix the errors one by one. Best of luck!
Yeah sorry wish I could help more. I just started and stopped rack 10 times with a network using your simple clock and min max and had no crashes or problems.
I think the code in rack0.hpp is not thread safe. The deprecated version of createParam calls module->configParam from the ModuleWidget ctor. I’ve been struggling for a few weeks to port my code to v1, because I misread Andrew’s migration guide and I was doing exactly the same thing. But it should be called from the Module ctor, and I suspect that its not safe to do it from the ModuleWidget. I was getting corruption of ParamQuantity such that it’s module pointer was garbage.
Go straight ahead and do the phase 2 migration, but read it thoroughly and do what it says.
I don’t think its a thread safety problem but an order-of-operation problem.
Module::configParam must be called before createParam; calling it afterwards allows ParamQuantity to point at deleted memory which may work by chance until the memory is reused.
I’ve realised why I was doing it that way. I didn’t follow the phase 2 instructions for that part, because I’d already dealt with the deprecation warnings. And to do that, I’d simply replaced the deprecated call with exactly what rack0 does.
My fault: but if you are right, then rack0 can be fixed.
Is there something I can check for in the step function to prevent this crash? I have too many modules to migrate everything to pure v1 without more effort that I can give, and I’d like to develop new modules on v1 instead.