Prefabs by ldlework pre-release

Remapped dll reclamation of control on GUI thread? So if the GUI halts, and modules are reclaimed, the request to clean the new with delete is perhaps a null pointer “optimized out self” as the delete context was reachable only on the GUI thread, as memory allocated by the dll is reclaimed before GUI clean up? But why did it only happen on the first test with CMake modules?

I don’t know enough to comment on this.

I’m getting this myself either using latest nightly (4f057ff) or debug build from source. Rack log, no GDB trace.

[828.314 fatal adapters/standalone.cpp:49 fatalSignalHandler] Fatal signal 22. Stack trace:
43:  0x0
42: raise 0x7ffb7d9dabe0
41: abort 0x7ffb7d9df1e0
40: ZN9__gnu_cxx27__verbose_terminate_handlerEv 0x7ffb442b3740
39: ZN10__cxxabiv111__terminateEPFvvE 0x7ffb442a63f0
38: ZSt9terminatev 0x7ffb443a2d30
37: _cxa_throw 0x7ffb443abf10
36: ZN4rack6system7getStemERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE 0x7ffb43285bf0
35: ZN11PatchSource8loadFileENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE 0x7ffb271b27d0
34: ZN12PrefabSource10loadPrefabENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES5_ 0x7ffb271be870
33: ZN12PrefabSource10loadPrefabENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES5_ 0x7ffb271be870
32: ZN13VerticalGroup4stepEv 0x7ffb271c3ad0
31: Z7eachDirRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt8functionIFvP6direntEE 0x7ffb271c3dc0
30: ZN12PrefabSource8crawlTagENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE 0x7ffb271bc5c0
29: ZN12PrefabSource7refreshEv 0x7ffb271bcb00
28: ZN10PatchStore7refreshEv 0x7ffb271b5be0
27: ZN7PrefabsC1Ev 0x7ffb27192970
26: ZZN4rack11createModelI7Prefabs13PrefabsWidgetEEPNS_6plugin5ModelENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEN6TModel12createModuleEv 0x7ffb271d7e30
25: ZN2Mb2v115ModelZoomSliderD0Ev 0x7ffb24368160
24: ZN2Mb2v18ModelBox8onButtonERKN4rack6widget6Widget11ButtonEventE 0x7ffb24383aa0
23: ZN4rack6widget6Widget8onButtonERKNS1_11ButtonEventE 0x7ffb43753cb0
22: ZN4rack6widget6Widget8onButtonERKNS1_11ButtonEventE 0x7ffb43753cb0
21: ZN4rack6widget6Widget8onButtonERKNS1_11ButtonEventE 0x7ffb43753cb0
20: ZN4rack2ui12ScrollWidget8onButtonERKNS_6widget6Widget11ButtonEventE 0x7ffb432cc970
19: ZN4rack6widget12OpaqueWidget8onButtonERKNS0_6Widget11ButtonEventE 0x7ffb2438ddf0
18: ZN2Mb14BrowserOverlay8onButtonERKN4rack6widget6Widget11ButtonEventE 0x7ffb24364360
17: ZN4rack6widget12OpaqueWidget8onButtonERKNS0_6Widget11ButtonEventE 0x7ffb43752ed0
16: ZN4rack6widget10EventState12handleButtonENS_4math3VecEiii 0x7ffb432d44e0

Hey Steve,

It looks like it’s crashing when I try to load your patches. Can you tell me if you do anything special, like keep your patches on a network drive, or have special permissions on the files, etc?

Any chance you’d be willing to send me a zip-file of your patches folder?

Definitely keep going with this one though. I like the “local” patch store idea, and the internet “my public patches” logical extension.

EDIT: I’m on gcc (Debian 10.2.1-6) 10.2.1 20210110lin-arm64armv8-a+fp+simd. The library manager might optimize out ALL allocation on unload not copied just to uptime max systems. Maybe not today, but someday … https://www.reddit.com/r/gcc/comments/10r3c5k/library_dangling_mem_leaks_on_on_unload/

Steve, can you try the latest build with -d. If it crashes, I’m hoping it will spit out some additional logging that might help us understand what’s happening.

My patches are on my PC’s drive in the default patches folder in Rack’s installation folder. I do have 990 patches, although the number shouldn’t make a difference.

I’ll try the devmode option and let you know if I spot something awry.

[edit]

[48.745 info C:/_Projects/VCVRack/Rack-SDK-2/plugins/vcv-prefabs/src/models/PatchSource.cpp:22 loadFile] [Prefabs] Loading patch from ./patches/Data bender maybe.vcv
[48.746 info C:/_Projects/VCVRack/Rack-SDK-2/plugins/vcv-prefabs/src/models/PatchSource.cpp:29 loadFile] [Prefabs] Unpacking patch to ./prefab-tmp
terminate called after throwing an instance of 'rack::Exception'
  what():  Unarchiver could not open archive ./patches/Data bender maybe.vcv: Unrecognized archive format

The exception is being thrown because the module is trying to unarchive a v1.1.6 patch, which of course Rack v2 allows the loading of. FYI, the problem with this particular patch is it’s missing 3 modules that aren’t in the relevant v2 plugins.

So maybe if the exception, instead of terminating, it could ignore this as it would be indicitive of pre v2 patches?

1 Like

with the latest build VCV crashes each time I want to add Prefab
here on Win11

I find this in log.txt:

rsmus7, can you run with -d and see if it produces any more interesting output?

Also stay tuned, I think Steve figured out the problem!

I have updated the Nightly build to support Rack V1 patches.

Please try it out and let me know what happens!

1 Like

the -d option doesn’t work here, as I have a different location for my documents folder and rack with -d doesn’t load this folder and the patches and plugins I normally use.

my rack patch still crashes with the latest nightly

maybe it crashes, because I have the documents folder of Win on another hdd partition
( not on C: ) and Prefab expects it to be in the default location?

I had the same issue. cd to Rack installation folder.

Then use ./Rack.exe -d -u [drive_letter:/path/to/plugins/folder]

Might need the use of single quotes ' if path has a space e.g. 'c:/Program Files/VCV/Rack2 Pro'

I am using the assets::user function to find your user directory so I am unsure why having the user directory on a different drive-letter would cause the problem.

The debug logging for the latest version will be helpful if Steve’s trick works for you.

Steve is it still crashing for you?

No, all good here now.

NB: -d development mode sets the system and user folders to the current working directory, so one needs to specify where the actual folders are.

What I use

./Rack.exe -d -u .

works for me as I have both plugins and patches folders in the installation folder.

1 Like

2.0.3

Hey all, I just pushed up some changes.

  • Multiple Prefab module are no longer a problem, they all share the single global widget.
  • All Prefab modules share a single set of settings. So changing it here changes it everywhere.
  • Once loaded the Prefabs Widget is now permanent and persists across patch loads.
  • Prefabs and patches with missing modules can’t be clicked and show tooltip with missing modules.
  • V1 patches now supported.
  • Some reliability fixes.
3 Likes

I am working on this.

Hey there joop,

I added this feature. Try out the latest build.

Edit $your_rack_directory/prefabs.json

Update the extraPrefabSources or extraPatchSources with array pairs of slug and `path:

  "extraPatchSources": [
    [
      "shared",
      "B:/data/patches"
    ]
  ]

And they’ll show up under the Plugin prefabs or Plugin patches sections.

1 Like

I’m noticing about a 2-3 second lag in opening the menu on the floating dial, maybe it’s because I have a lot of selections and favorites? Running 2.2.2 on Mac Air M1 under Rosetta.

Yeah, I just came here to mention now that we’re processing patches, we’re doing a lot more work on startup. The more patches you have the longer startup will be.

I will attempt to optimize things as my exploration of features settles down and we squash some more bugs. Please let me know if the delay makes the plugin unusable.

That said, patches are also now included in search results on the latest build.