After finding that the patch crashes on my Intel Mac in the exact same way, I couldn’t resist messing around with it and trying to figure out what is going on.
It turns out that one of the cables – from an RCM CV Knob 0 to 10 to an 8FaceMk2 – has a value of 10.0. (It’s on line 48749 if you’re interested.) If I change the value to 9.9 in the patch file, it loads successfully.
I have no clue why this matters, but with this change it at least loads without crashing.
Here’s the resulting patch file:
patch.vcv (1.4 MB)
I’m honestly not sure if the problem is the 10.0 coming out of the knob module or the 10.0 going into the 8Face (assuming that I’ve got the direction of the cable correct). My guess is actually the 8Face at this point, but I haven’t looked into the (open source) code of either module at all. In any case, it remains perplexing.
I was mostly only trying to get the patch working simply because it annoyed me that it was crashing and looked likely to be diagnosable.
Thanks. I just downloaded it again and it saves and opens and closes without crashing unless I change the module to cv 10 and then save it. Then it doesn’t open and I have to re download the patch you uploaded again…
I guess putting the cv thru an attenuator to prevent it from reaching 10v is not a good solution…
Do you see how the 8face modules if you look in the context menu for bound modules, there’s a lot of errors, should I manually unbind all those modules that are not in the patch anymore? Could that be causing the issues? The patch used to be different and had other modules bound to 8face but it evolved and I removed a lot, but the 8face modules still have them in that menu…
I’ve had a quick look through the source code for 8Face mk2, and it does look possible that it doesn’t work for a CV of exactly 10.0. But it could also be that I am tired and my maths are wrong.
In any case, it certainly wouldn’t hurt to try the attenuator idea to ensure that the CV remains below 10.0.
Agreed if I were more certain that it is an actual bug, in which case I’d probably fix it myself and then submit a pull request.
But I am not at all sure it is an actual bug. It is more likely that it only looks like one because I am tired and need some sleep soon. If I have the brain cells tomorrow I might look into it again.
really appreciate the help! i made a bug report on github, it includes my new patch that still crashes, but it has now had all the error modules unbound from the 8face modules, so if you intend to look further into this crashing patch, i suggest you download the one from my github thread. thanks!
Sorry I’m pretty new to arm/non-arm stuff… can I still run the arm64 version of rack and use the nightly pack one modules inside it? Or is it best not to mix them up and just use the regular version of rack
Your plugin OS and ARCH must match the OS and ARCH of the Rack you’re running.
This snip (from my p[rerelease plugin) shows a release that includes Mac ARM:
