The Rack plugin API is very general and gives full access to everything Rack can do.
8 Likes
It’s totally true. Anything Rack can do a plugin can do to. One super simple example, inspired by @stoermelder’s amazing modules, is the “Hookup Clock” command that goes out and finds clock modules and puts in the patch cords for you.
From our manual: If you are using Clocked, or its smaller sibling CLKD, the “Hookup Clock” command found in the main context menu will do all the patching for you. Just insert a supported clock module, set up the Seq++ clock divider to what you want, then select Hookup Clock. Seq++ will automatically find a clock, patch it in, and configure it.
5 Likes
MB is great, thank you!
Shouldn’t it hide itself from the browser to prevent space-time breaking up? 
It would be nice if it could scan the patches folder to get instant “Most Used” ratings.
How should PM work?
2 Likes
Personally I wouldn’t like that as I download a lot of other people’s patches and have them in my patches folder - I would not want modules used in other people’s patches to count towards my most used… better just to track the modules I add to patches from the browser imo.
Also, even without other people’s patches, my most used now is different from my most used say a year ago - I’d rather it just tracked what I am using most now.
You could separate those by putting them into another folder but I understand that everyone orders their directories differently, some might not even use the /patches folder at all.
As it works now, your most used are not related to time, only to how many times you’ve picked them out from the browser, so I suppose this problem will come up one year from now with the current tracking mode as well. What would solve this is a fusion of the “Most Used” and “Recently Used” sorting.
With patch files you also have dates (although not super reliable), so assigning the “last used” timestamp could be based on the date. Reading through the patch files in order (by date) could roughly simulate you, picking modules out of the browser in terms of what data you get in your usage history. (if we don’t count the problem with unwanted patch files ofc)
It could also register modules that you’ve created by duplication instead of picking from the browser.
2 Likes
I was too curious to see my history, so here’s a node.js script that does what I described. It modifies the existing history inside “Stoermelder-PT.json” by adding to it, so don’t run it multiple times. Since it also logs the total number of modules and cables, I’ve learned that I have about two cables for each module on average, which makes me think I should modulate more…
3 Likes
I’ve never used node before, so maybe I’m doing this wrong, but I get the following error:
(nodejs) ~/Rack> node extract_usage.js
undefined:7
<!DOCTYPE html>
^
SyntaxError: Unexpected token < in JSON at position 6
at JSON.parse (<anonymous>)
at files.map.filter.sort.map (~/Rack/extract_usage.js:48:24)
at Array.map (<anonymous>)
at fs.readdir (~/Rack/extract_usage.js:46:6)
at FSReqWrap.oncomplete (fs.js:141:20)
I’m running on Win10 via anaconda prompt.
Is there some real interest in something like that? I could implement some sort of patch scanner into the module but only if people are going to use it… I won’t ever use it myself, I guess…
At least for me, I think it would provide a useful starting place for a list of most used modules. You could even get fancy with it and take the top 10% most used (or some other percentage) and automatically add them to the favorites list.
Separately, I think it would just be neat to point at a folder of patches and get some pretty statistics as output, including “average cables per module” like @unlessgames mentioned and maybe other things. I can’t say how useful that would be, but it would be fun to look at. At least at once a year maybe? You could do end-of-year retrospective data analyses like last.fm does for music listening history.
If it got really fancy, you could have a module (or panel in the module browser) which offers suggestions for modules to add to the current patch, based both on what modules are currently in the patch and what modules tend to coexist with those currently used ones together in any given patch from the imported “patch history folder”.
To build this sort of patch-aware history on-the-go, I guess you could hook into Rack’s file saving function?
On Linux, probably Mac too: cd to your patches folder in a terminal, then: grep ‘“model”:’ * | cut -d ‘:’ -f3 | tr -d " " | tr -d ‘"’ | tr -d ‘,’ | sort | uniq -c | sort -n for a quick report on your most used.
3 Likes
grep '"model":' * | cut -d ':' -f3 | tr -d " " | tr -d '"' | tr -d ',' | sort | uniq -c | sort -n
worked for me on MacOS after replacing all the fancy quotes that the forum software “helpfully” interjected into this clever command. (formatting it as a code snippet fortunately seems to avoid this problem)
3 Likes
Glad it worked. I was gonna fix that, but I figured people could figure it out. Thanks.
I was amused to learn (thanks to your script) that my #1 module, by a sizable margin, is the Submarine TD-202 Vertical Text Display. This might say something about my patching personality (in addition to the fact that it was formed before Stoermelder’s Glue was available).
2 Likes
sry, my script doesn’t handle having different files (like .html) in your patches folder.
1 Like
Oddly enough, there are no html files in the folder. I went ahead and removed a few audio files and a video from there, leaving only .vcv files, .vcvm files, and .vcvss files. Still the same error. Removed vcvm files and vcvss files too, but no dice.
I guess one of my patch files has html inside…?
I updated it to skip those files and to provide a bit more silly stats, like how many meters of cables you’ve used in your patches (just an approximation ofc).
2 Likes
I get you are asking anyone other than me 
but I think seeing you own data summarized is generally an interesting thing to people.
Of course if you use MB long enough, you’ll gonna get a meaningful “most used” list, but this would make it so from the beginning. And once you scan the patches, you could extract some more statistic.
I’d propose this as a separate module idea, but at the same time I feel like a Stats page would be a good fit to put inside the module browser as well.
1 Like
my 2 cents: stats can be really interesting (at least for some of us) but need to be flexible in their implementation, which may require some research among users. In other words “the usage of a module” means different things to different users:
- time spent in VCV on a patch including the module
- number of patches in /patches/ that include the module
- number of times the module is loaded from the module browser into a patch
- number of times a patch is loaded that includes the module
- the module being included in a given patch but not being connected
- the module being included in a given patch but being disabled
Flexibility about paths may be required too - some users organize their patches out of the default /patches/ directory.
1 more cent: I’d welcome any stats that would help establishing a correlation between the number of available modulation sources and the number of available inputs (or other interesting “ratios”). Example: “oh look, according to stats my average patch has 10 available inputs, but only 3 modulation sources…I should try using more LFOs/envelopes/random generators/etc”).
A different “ratio”: how many times I’m choosing a kind of module vs. how many modules of the same kind are available. Example: given the number of alternatives, including VCV LFO-1 in all your patches is a bolder choice than always including VCV MIDI-CC.
I’d propose this as a separate module idea, but at the same time I feel like a Stats page would be a good fit to put inside the module browser as well.
I also don’t know about this - moderators please feel free to move my reply to a new “Stats” thread if you create one.
(EDIT: this is now a Wiki-style collaboratively-editable list of “smart combinations” of Stoermelder modules with basic written instructions**
Controllers: MIDI-STEP + PILE
- check the comments here: Arturia Minilab MkII - is it ok with VCV Rack?
Handling a list of presets for a given module: STRIP + 8FACE
- use Strip to save a small strip of Percussive Vibration + 8Face
- (for existing patches) go through the patches where you’re using Percussive Vibration, load Strip, right-click Percussive Vibration, copy the current preset, paste it over the Percussive Vibration in your strip, save it as an 8Face preset. Then save the new version of the strip
- any time you want to use Percussive Vibration load its strip. You get all the presets ready to use - with advantages compared to how presets are natively handled by VCV
(in my original post I was saying that I’m relatively new to Stoermelder modules and I was looking for a comprehensive, written list of “smart combinations” of Stoermelder modules. I also included the Strip + 8 Face combination, which was probably already known. Reminder: you can check history/edits of posts and comments).
2 Likes
There might be a more comprehensive list around but @VCVRackIdeas youtube channel has some really good videos about using them in combination.
1 Like