[Feature] Idea to make WhatTheJack more useable

[Cade922]

My idea to make WhatTheJack more usable would be to add two things.

1. A grammar of the jack/submod types (It may already have this) and assigning types to all of the jacks in any mod. The more properties you can have in the grammar about the submods' functions, the more useful.

2. A script or whatever to compile the wiring patterns from uploaded patches* into an xml or whatever. (* To the extent you can get that data. Using the grammar, they could be from any system, not only VCV.)

3. A script that uses any number of ML algorithms on the data to create a predictive model of wiring patterns. (I looked up ones for autocomplete and they looked in the neighborhood. It takes all the Ins and Outs in any given rack and generates a weight table of probability.)

Then for whatever modules are on the rack, the jack placement would be weighted according to the likelihood a connection of A type jacks into a connection of B type as used in actual patches. Then you could have a knob where 0 is precisely the most likely, and 1 is what you have now (completely randomized), so you could get the level of randomness you want. If there's not enough data, then I think you'll want to generalize the grammar more; so it could make a model where roughly submods of type-A generally more often jack into submods of type-B, and add that to the weighting.

[korfuri]

I'm not quite sure what you mean by a grammar to describe jack/submod types. If you mean having WTR understand third party modules' different types of jacks (is it audio, is it CV, etc.) then I don't think I want it: WTR's role is to patch stuff that you wouldn't patch yourself, and see what happens. Most of the time it's going to be garbage, and once in a while it'll give you a good idea.

Also, one problem: it's not going to work with the info present in Rack modules today: all we can know about an jack is whether it's an input or an output.

Re: applied ML, sure, that would be cool, but I don't have an interest in doing that at the moment. It could also be done outside of Rack, actually: parse the saved patches and feed that into your favorite ML algorithm family (you could use patchstorage as your training data) and you should be getting patches out.

[dromer]

I like all of these ideas, but they should be optional!
Default operation should be total randomness ;)

[alefnull]

the plugin author just made me a maintainer on the plugin because they don't have a machine to run Rack and/or don't have the time to maintain it these days, but i have to admit, i'm personally not particularly interested in changing the plugin's original behavior, and just wanted to get it updated to version 2 and see it back in the library for others to use.

even that aside, i am also quite new to Rack development, and am somewhat of an amateur in general development as well, so i wouldn't even know where to begin in making the suggested changes.

[dromer]

These thoughts can also serve for anyone that wants to do a project that is "similar but different".

Can keep WhatTheRack as simple/dumb as we want. Pure randomness and then figure it out from there (which is the intended goal as I interpret it) is already really fun!

A project that does a fully self-patching randomizer would be really neat though!