Prefabs by ldlework pre-release

Assertion on exit, probably the same as

Rack log, no GDB trace.

[976.192 fatal adapters/standalone.cpp:49 fatalSignalHandler] Fatal signal 22. Stack trace:
15:  0x0
14: raise 0x7ffdc131abe0
13: abort 0x7ffdc131f1e0
12: wassert 0x7ffdc131d210
11: ZN4rack6widget6Widget11removeChildEPS1_ 0x7ffd9c803500
10: ZN11FakeBrowserD0Ev 0x7ffd7d5092d0
9: ZN4rack6widget6Widget13clearChildrenEv 0x7ffd9c803610
8: ZN4rack6widget6WidgetD1Ev 0x7ffd9c803770
7: ZN4rack3app5SceneD0Ev 0x7ffd9c7e4a50
6: ZN4rack7ContextD2Ev 0x7ffd9c7864a0
5: ZN4rack7ContextD2Ev 0x7ffd9c7864a0
4: ZN4rack7ContextD2Ev 0x7ffd9c7864a0
3: ZN4rack7ContextD2Ev 0x7ffd9c7864a0
2: ZN4rack7ContextD2Ev 0x7ffd9c7864a0
1: BaseThreadInitThunk 0x7ffdc2597600
0: RtlUserThreadStart 0x7ffdc2cc2680

Hmm, this seems to be related somehow to the browser being double-freed, or something.

Heh, I haven’t been able to reproduce even a single issue mentioned in this thread so far. Makes it a real challenge to try to address them :smiley:

Do you know whether you had browser mode enabled when this happened? Did you have the prefab module opened, or deleted, etc?

…I write such buggy C++ the idea of introducing a worker thread seems like it would be such an act of reckless hubris on my part :joy:

Hey there joe, thanks.

I’m aware of the mapping problem selections have, but I haven’t had a chance to look into it seriously. I’m kind of waiting to see if Andrew will address the problem on Rack’s end. If not, I hope to eventually support mappings.

I wonder if some other programmers around here can help me to understand what approach stoermelder is taking to address the problem.

2 Likes

So I just updated to latest VCV Rack, and the installer completely blew away the install directory that had my development checkout of Prefabs so I just lost all the work I was doing.

But the upshot is that I’m now able to reproduce the on-close crash. I’ll start looking into it once I get everything set up again.

smh…

1 Like

Hey all, pretty sure I’ve fixed the browser related exit-crash.

Try out the latest build and let me know how it goes.

Hey all, just pushed up 2.0.4 with threaded refresh:

2.0.4

  • Refreshing is now in a background thread which should keep the UI responsive
  • Added a browser replacement mode
  • Added extraPrefabSources and extraPatchSources to prefab.json settings.
  • Patches are now searched
  • Search results cleaned up
6 Likes

No exit crashes here, confirming Fix browser cleanup crash · dustinlacewell/vcv-prefabs@2253d93 · GitHub is good!

1 Like

i have tried several times, not working here, whenever i try to add the strings with my patches dir, nothing happens inside vcv, patches dir is not searched nor visualized, and when i come back to prefabs.json it seems to be reverted to the default… win 7, vcv 2.2.2, prefabs build 2.0.4

Close Rack. Make the edit, and then reopen Rack.

Wow, thanks! That fixed it. What a wonderful idea you’ve had- I find it much easier to drill down into the mass of modules to find one that does what I’m thinking of at the moment.

Thanks again, and well done!

of course I have edited the file with rack closed, tried to reload module, tried everything i could think of, doesn’t work on my system

Hey all, just pushed up 2.0.5

2.0.5

  • New module look!
  • Shows total prefabs/patches/modules
  • Indicator light shows when data is being loaded
  • Unified prefab/patch handling should be much more performant

Grab the latest build and let me know how it goes.

edit lol, the forum squished the gif

2 Likes

FYI: there is no ‘nightly’ build for v2.0.5 in your Releases.

Did you forget to push it?

Nah I had some bugs that needed fixing. Should be good now.

A previous version loaded on my machine, but the 2.0.5-nightly does not. On macOS 10.12.5:

[1.040 warn src/plugin.cpp:237 loadPlugin] Could not load plugin /Users/lab/Documents/Rack2/plugins/Prefabs: Failed to load library /Users/lab/Documents/Rack2/plugins/Prefabs/plugin.dylib: dlopen(/Users/lab/Documents/Rack2/plugins/Prefabs/plugin.dylib, 6): Symbol not found: __ZNKSt3__14__fs10filesystem4path6__stemEv Referenced from: /Users/lab/Documents/Rack2/plugins/Prefabs/plugin.dylib Expected in: /usr/lib/libc++.1.dylib in /Users/lab/Documents/Rack2/plugins/Prefabs/plugin.dylib

The code I’m using to process files now requires macOS 10.15. I guess it’s a lot to ask people to upgrade. I’ll have to figure out which bits are unsupported and I guess figure out other ways to write those parts. I’ll try to do it soon but I’ll be busy tomorrow. macOS 10.15 is four years old now I think. :slight_smile:

1 Like

Ok, but just remember that Rack supports macOS 10.9+ and you’d be suprised how many peopl use older Macs. Maybe look inside the Rack code and/or its osdialog code for suitable and compatible file-processing code?

Hm. I did that and the next time I opened Rack it said couldn’t find module prefab.

Is it now required that opening the widget / refresh needs to be done when opening a patch? By default, I’m using the right click menu with widget off.

When I open a patch, seems like I have refresh / open the widget first each time, before the right click menu populates for the first time? Otherwise it’s blank.