NYSTHI won't open in local build (Mac) SOLVED

VCV Rack 2.1.0 local build for Mac Mini M1 x86_64 NYSTHI 2.1.18 for Mac

When Rack tries to load the plugins it gets this far:

[8.250 info src/app/Browser.cpp:201 createPreview] Creating module widget NYSTHI Logic AND, OR, XOR, NOT
Assertion failed: (threadContext), function contextGet, file context.cpp, line 47.
make: *** [run] Abort trap: 6

Any advice/suggestions ? I never had this problem on Linux, is it not possible to run closed-source plugins in a local build for the Mac ? Or am I missing something obvious ?

I think if you look closer in your log above this error message, you’ll find that the NYSTHI plugin actually gets loaded, and the error you’re seing there is when you open the module browser in Rack (correct?) and the NYSTHI Logic module crashes in the browser, which is a frequent ocurrence if the developer don’t take account of the fact that a module is not instantiated when shown in the browser. So my money would be on a bug in that module and @synthi just forgot a single line in the module to take account of it.

Thanks, Lars. I’m hoping Antonio weighs in here. I’d love to have that set operational here.

Same situation with the Bastl, Vult, and Alright Devices plugins, same error message. So it’s not specific to the NYSTHI plugin.

Ok, that’s strange. And they crash in the module browser, right? And you’re sure it’s v2.1.0 and not the new v2.1.1? Would be interesting if you could replicate it in v2.0.6…

Are you sure you’re in the x86/intel (Rosetta) environment when building both Rack and the plugins? Or are you experimenting with building them all for Arm? Did you ever have those plugins working, having built them yourself?

The plugins in question are all closed-source, so no local build possible. The crash does occur when I try loading them from the browser. And yep, I’m running 2.1.0:

% make run
./Rack -d
[0.000 info adapters/standalone.cpp:127 main] VCV Rack Free v2.1.0
[0.000 info adapters/standalone.cpp:128 main] Mac 12.3
[0.000 info adapters/standalone.cpp:134 main] Args: ./Rack -d
[0.000 info adapters/standalone.cpp:136 main] Development mode
[0.000 info adapters/standalone.cpp:137 main] System directory: /Users/davephillips/src/Rack2
[0.000 info adapters/standalone.cpp:138 main] User directory: /Users/davephillips/src/Rack2

Ah, yes, of course, very strange. Did it work in your 2.0.6 build? Does any plugins at all, that you have fetched from the library and not built yourself, work in your 2.1.0 build? Have you tried moving the trouble ones aside to see if the rest work in the browser? Just trying to isolate the problem to your build of Rack or something else…

I just tried Host, same issue. So far it’s a no-go with plugins from the Library. I don’t recall trying any with 2.0.6.

Do any of the open source plugins work when fetched from the library?

I tried the Valley collection, it failed with the same error.

Ok. I don’t know, it’s strange. So the situation sounds like this, correct me if I’m wrong:

  • You have a Rack 2.1.0 that you have built yourself, on your M1 Mac, for x86/Intel architecture.
  • All the plugins you build yourself shows up fine in the Rack module browser.
  • All the plugins from the library, fetched from Rack itself, causes the Rack module browser to crash.

Correct? So logically I can only think of two explanations:

  1. All plugins from the library are suddenly corrupted. That sounds unlikely.
  2. There’s something fishy going on with that 2.1.0 build of yours, for reasons I can’t tell you. That seems the more likely explanation.

So, since your previous local 2.0.6 build does work you have that to go back to. You can also try building the new v2.1.1. If it’s the same problem I would guess that something happened to your local toolchain, between building the 2.0.6 Rack and then the 2.1.x versions, that somehow causes an incompatibility. But that’s over my head to debug.

Built 2.1.1 this morning for the M1 (x86_64). Still the same problem with closed-source plugins. They’re fine in the downloaded 2.0.6, just not in the local builds. I’ll check for any previously installed versions, maybe there’s something hanging around in the /usr/local hierarchy.

Btw, how do I completely uninstall VCV Rack on the Mac ?

Rack should be the app in Applications folder and whatever is in your user folder as well as your vst plugins if there which would be by default in /Library/Audio/Plug-Ins/VST . Nowhere else should it put things unless you told it to, at least that is how it is here in this Mac.

1 Like

I run nysthi plugins in my home-built VCV in windows all the time.

1 Like

As I did in Linux, hence my confusion on the Mac.

I’ll clean out everything I can find and start over with a new build. Seems to be the best option.

Success ! NYSTHI was throwing an error about not finding libRack.dylib. I created a link from ~/src/Rack2/libRack.dylib to /usr/local/lib/libRack.dylib and voila, I have NYSTHI again. I’ll check if it works with other packages later, right now I’m happy as a clam in mud. :slight_smile:

2 Likes

The way to uninstall applications in macOS is blindingly simple. In Finder you go to Applications, select the app and select “Move to trash”, job done :slight_smile:

Good but… interesting. Maybe something changed in the Rack v2.1.x ABI or… something. Maybe the downloaded plugins were finding libRack in the installed/offiical Rack location and that screwed up your local build, with symbol versioning and all that. Maybe local builds of Rack now only works with plugins in its own plugins/ sub-directory; don’t know how that would work with downloaded plugins though. Don’t know how it ever worked though because I never tried it, so don’t take my puzzlement for anything :slight_smile:

Hi Lars !

The experience was enlightening. I copied libRack.dylib to /usr/local/lib but that generated a warning about it existing it two places. I then tried linking it, at first from ~/src/Rack2 but I noted that Rack still generated a missing lib error when trying to load the NYSTHI plugin. I looked closer and found that the link in /usr/local/lib was incorrect, i.e. it wasn’t actually linked to ~/src/Rack2/libRack.dylib. I then created the link while in /usr/local/lib and that created a valid link. So, either I screwed up the first attempt or the Mac wants linking done in a very specific way. The greater likelihood is that I screwed up the link.

Yep, uninstalling is breezy. :slight_smile: No problem with that task.

Thanks for the interest and assistance !

dp

1 Like

If it’s any consolation I find linking to be… “interesting” on all platforms, all in their subtly different ways of course :slight_smile:

1 Like