Awesome, so much better with that option! No lag at all as far as I can tell.
So, in terms of refreshing, if you save a new patch, it won’t appear in list until you refresh the list? I think that’s fine personally.
1 Like
Yeah exactly.
Hopefully eventually it’s fast enough we wont need the option.
1 Like
Teaser:
1 Like
OK, browser replacement has been implemented in the latest build.
Enable it in the right-click settings with Replace browser.
1 Like
Processing patches when the module starts up is not going to work. Some people have a lot of patches and some might be big. IMHO you shouldn’t process patches at all but if you do, it should be offloaded to a background thread I think.
By “processing” I mean discovering them on disk, unarchiving them, and read their JSON. In C++ it should be extremely fast, it’s just that I’m new to all of this so the implementation is probably very wasteful right now. I think also finding a cross-platform “file watcher” so the whole world doesn’t need to be reprocessed each time would be good. Putting it all in a background thread sounds difficult for me but I wrote the idea down thanks.
Perhaps set
"bypass": true
for all Audio modules when importing - both patches and selections.
VCV Prototype uses EFSW for detecting when a single file changes - maybe it can be used for your purpose too.
Awesome, thank you for implementing this feature!
On my WIN10 machine, after I use Prefab 2.03 in a patch, close it, then begin to load something else into Rack Pro 2.2.3, I get the following:
Clicking 'No" allows me to proceed normally. FYI.
Yes, the GUI unloads all widgets, and then the module unload tries to schedule a deletion of a GUI component which was unloaded(?). It shouldn’t affect using the plugin as it happens after everything is saved, but does need correcting.
EDIT: Let’s hope no one puts memory reclamation code in the module destructor. It might need a process or reboot to free the heap. I assume module termination is done in some linked list order, and that all modules do a json save before the first module is freed (unloaded).
Is this a place where a worker thread could do all that work, so that the main gui thread doesn’t get bogged down? Or do you need that list at module construction time?
Getting this crash as well.
Are you using 2.0.3 as that original bug looks removed.
the latest nightly loads without crash 
1 Like
It’s not really needed at module construction time.
I just don’t know how I would go about it in general. Like, I’m guessing I need some sort of lock so the main thread / UI doesn’t try to access the data while it is being updated etc? I dunno, just seems like it could get complicted heh.
Like what happens if the main thread tries to iterate over std collections while they’re being added and removed from?
A bool shouldn’t need a lock to get/set. An if test on the bool showing loading... for a frame might work. Not sure how the focus would work on swapping menus. A pointer might need a bool lock too, and it simplifies because one side is always the reader, and the otherside always the writer.
EDIT: -O3 might reorder assignment. A different process might need a cache flush of the variable address. Is it volatile as a keyword? Or is that Java?
EDIT2: volatile bool amReading might also be necessary. I did once show that a cache flush before read address was sufficient for all synchronization, if there was a single thread operating a linked list service on the CFR addresses. CAS and CAS2 instructions seem enough for 64-bit too, but they are complicated. And FENCE is also another one, but out of order speculation does complicate things. ROB units in the processor hold things like register renaming and such.
EDIT3: Well yes it may have technically diddled to IO twice or more before the CFR, but if you’re using multi-threading access to IO registers then good luck with you’re sequencing! zzzz fgsdhqhdbwcwc.
What a great idea! I’m running it on W10 and it seems to be working fine. Love it when someone comes up with something new instead of another vco or sequencer etc.
1 Like
Hey @Idlework, really cool plugin! I was able to pull it down on my ArchLinux laptop; compiled and ran great on the first try (although maybe you could have the default make target use dist instead of all? Most plugins I can just run make and have them build). I love the ability to browse my selections by module!
The one issue I have, which is also an issue with Rack’s “Import Selections”, is that it doesn’t always restore the entire state of some modules. I’ve only seen this issue with MindMeld’s PatchMaster, where it doesn’t restore your mappings to other modules. I’ve been using Stoermelder’s Strip for this, which I believe is linked above in this thread, but with all the options your plugin brings, I would be much more likely to use it instead. Do you think this is something you could get working?
Thanks for sharing with all of us, I can’t wait to see how this plugin plays out 
2 Likes
made a new thread for this. For some reason I can’t tag you there - this forum doesn’t seem to recognize your name.