Alright, I figured it out.
Prefabs will now show your patches as well. They need to be organized just like prefabs.
You can also fully load a patch by right-clicking it and selecting “Load patch”
Nightly updated.
For now, patches are not included in search (I’m too tired to go on tonight lol).
Things I’m thinking about:
Is it possible to use directories other than the default one for saving and restoring?
I usually work on the same patches on different machines, and have a shared directory for them.
Hmm, can you elaborate what you mean or what you’d like to see? Right now it loads patches from the user Rack directory. Are you saying you want it to look in additional directories?
For me it would be great to be able to set a default directory.
Hi last version Prefabs-2.0.2-nightly-4f057ff-win-x64.vcvplugin for WIN shutdown VCV RACK to OS. Every time when I trying to use this from Library and put in to the rack.
& that sounds great. The delete by system must be the last thing done at -O3. Huarrah for DDR7.
APP->scene->addChildBelow(&iconWidgetNotPtr, APP->scene->browser) and APP->scene->removeChild(&iconWidgetNotPtr) might remove the memory leak.
So you shouldn’t delete a widget which is in a container. Only delete widgets which you remove
That means the destructor will crash (double delete) if the widget is also housed in the scene
The solution indeed could be to remove it but far better is do nothing. Initialize your widgets to null and always add them to something and you won’t leak
The inky condition in which you leak is if you remove a widget from a parent, don’t add it elsewhere, and don’t delete it
The bug I thought was uninitialized memory (which was indeed a bug) may not be causing the crash. My guess is that destructor is running with the widget still added so double deleted
My advice. Delete the destructor body or explicitly remove the widget and hand delete it if you need to for some reason
If a deleted widget is in a container the draw may seg fault. They must be removed before deletion. The scene uses a pointer to the widget due to perhaps multiple references. Why would it delete widgets? The module removes all its child widgets on destruct. If an instance makes a placement elsewhere it should remove before destruction. It’s a button with major functionality, malloc for a dynamic allocation is pointless for it for that and other real time reasons.
you must remove before you delete but you can also choose to do neither and the parent delete will reap its children
Your other comments are not quite right for the way rack works. Every widget is a pointer where you pass ownership to the parent
Ok, so removeChild(&) and no deletion of the parent before so for me then.
EDIT: Got to keep quiet about setting visibility when not the owner. 
great module 
I am a bit worried about importing entire patches - Each patch should have one master audio module, correct? But most patches have an audio module, so if you import multiple patches, don’t you get a conflict?
Hmm, I had considered this – but what about in the case where you delete my module? The widget will be owned by the Scene and so wont get automatically cleaned up when the Prefabs module is deleted.
So the reason why I’m explicitly deleting the widget is so that you don’t get an increasing number of widgets on screen as you add/remove the Prefabs module.
So given that, I think I should interpret your advice to not just “request delete” but to first remove the widget from Scene.
Then, since the widget has no parent, I need to perform the deletion myself.
I’ll look into this.
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 20210110 … lin-arm64 … armv8-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.