It’s perhaps important to note that I was previously using an intel based Mac and have just upgraded to and M1 based Mac. Operating systems are both Monterey.
1 Like
Can report that downgrading to MAX 8.1.11 fixed the issue
5 Likes
Not really. As far as I know, there was something broken (in general) but it was fixed recently. I would say that already after the newest Max release.
That was because you are a new forum user or used it too little. I manually raised your trust levels and not you should be able to share the screenshot.
Can you test it again on the Intel one? With the latest Max version, etc. That could indeed be the source of the issue.
Have you updated it after? With the latest version it doesn’t work?
2 Likes
Hi Jon,
Thanks for getting back to me. I’m fine using the workaround for now. But to demonstrate, I’ll attach a screenshot of the MOD Watcher running side by side in both MAX 8.1.11 and the newer build 8.3.1, left and right respectively.
File preferences are exactly the same in both versions of MAX, yet 8.3.1 throws up an error when attempting to load the modduo.support object
There are versions of modduo.support.mxo in two separate locations. To be certain this wasn’t causing a conflict, I removed one of them, restarted max and tried the MOD Watcher again. I tried the same again, but this time removing the other one instead. The issue has persisted both times.
I’m not a programmer BUT… I did notice while using Max8.1.11, where modduo.support still works, the object takes an unusually long time to initialise compared to most objects. And that the error in Max8.3.1 refers to ZStd, so perhaps there is a decompression issue? Fairly uneducated guess on my part.
I don’t currently have access to my intel based Mac to test with the update of Max. But I hope the screenshot helps diagnose the issue at least in the case of my M1 Mac.
4 Likes
Just tried it two days ago. Seems to work fine now.
Lloyd
3 Likes
Thanks for the report.
I was trying to get some feedback on what could be happening, but most likely it was some server down or so.
I’m glad to know that it’s all fine now.
2 Likes
I know it’s been suggested in the past but is there any chance of the development of a local compilation app; a way of compiling the patch on our own computer as opposed to using Cycling’s servers?
2 Likes
I’m not sure if we are using any Cycling server for this. I think that no.
1 Like
@jon I thought the mod watcher uploaded the gen code to a cycling 74 server that compiles the code for the mod device, have I got this wrong?
1 Like
the MOD cloud is the one that does the build, in a similar fashion to how we do builds ourselves but in a different endpoint.
we initially tried building it locally, but was quite difficult to setup and updates to macOS would keep breaking it, so the required maintenance time did not make it worth while.
maybe could work inside a virtual machine, something to try later on perhaps.
there have been a few instances already where using OS-level virtual machine APIs would have been useful, I will have to check it at some point to see how feasible and easy it is to integrate…
5 Likes
Hi there!
I’ve just bought a Mod Dwarf and getting this error when trying to use the MODwatcher patch. Specifically:
modduo.support: unable to load object bundle executable
Does anyone have any ideas on a fix? Appreciate any help!
I’m on a Mac M1 Ventura 13.3.1, Max 8.6.0
Thanks!
Shamus
Thank you!