I think custom categories would be way too complicated. First they must somehow managed, second modules would need to be categorized into them. Personally, I won’t spend any time manually categorizing modules, far to tedious…
About the search in descriptions: This would need some smart logic for ignoring fill-words like „and“ „or“, a kind of tokenizer. I could easily extend the search for descriptions but this would lead to many bad results.
Featuring some knobs and buttons to be able to act as a control plate for a bunch of other modules:
Nice to have features:
Selectable module graphic for the purposes of labelling a control and creating a visual theme
Bypass and mix settings by default
Possibly a impromptu clocked bpm input and or a tap tempo to a clock out for time sensitive stuff
Then work similarly to your strip module (or be an upgrade to it etc) to have a bunch of modules be saved as a preset.
Idea 2:
Pedal switcher
A control surface for controlling the following:
Module(s) enabled or disabled
Module(s) being used or bypassed
Selecting the order in which module sets are run such that you can setup something like the following: input -> fuzz -> wah -> drive -> output
Or input -> wah -> fuzz -> drive -> output
Both these modules are close to things you have already coded, but would be amazing time and resource savers for how I’m using Rack. Currently use a lot of buttons and knobs and workarounds to get there.
in case of pedal switcher you may have any luck with SWITCH44 from bogaudio + 8face. Here you can watch what I mean - https://youtu.be/V469a6QxiKo?t=739
Hi Ben, i posted this in the other thread. Thought i post it here as well:
In this list of view order: alphabetic / random / most used / last used / recently updated
Can we get one more: empty
As in ‘no module graphics loaded’, only when we actually touch anything on the left side panel.
IE: would be nice if the browser could be set to a default behavior that it opens empty and only shows the category or filter that is chosen on the left, after the user clicks on it.
8Face - can you add an option click to write to a slot? or some other keyboard modifier… would be much nicer to use the module without having to toggle the switch to program.
If you could also add the bind / unbind option from transit - that would be amazing!
I believe you can do now vice versa thing - shift click in write mode will play a selected slot instead of writing it. At least I saw it in Transfer module)
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.
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.
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…
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)
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.