I know there are several modules that let you control knobs and other widgets. Is there any module that can controls “hidden” parameters in other modules? If there is a VCV “param” that is perhaps controllable from a menu item, is there any way to voltage control it using such a module?
Great question. The only thing I know of is Stoermelder Map, but that just allows controlling parameters that already have a visual element. I was trying to modulate the harmonic sliders on the XFX wavetable oscillator recently, and it doesn’t seem possible. That’s not even a menu item! This needs a solution.
It’s certainly technically possible to build, and not too complicated.
The outline would be to borrow the existing methods to locate a targeted module (e.g. click on any param on the module), then enumerate the module’s params/paramQuantities arrays. An interesting question is how to present the UI for selecting which to automate. Perhaps a menu on each CV jack that lets you select the param for the jack, with a dynamic label showing the param name.
So many times I have wished such a module existed. Some sort of ‘universal expander’ type module with a healthy amount of assignable jacks that could be mapped to menu params of an adjacent module.
I love automation, so I would love to see something like this. But, it could open up a can of worms of malfunctions, possibly. For example, if there is a hidden parameter, what all must be done internally by the module when the parameter is internally changed? Then what if we change the parameter value via an automation module, how could we guarantee that the side effects were properly handled?
I still would be interested to see someone(s) explore this.
That’s the fundamental issue with this kind of fiddling with another bit of code’s internals – there is no formal contract so no guarantees that anything will work. Depending on the module, you can easily create crashing situations. A responsible implementation would honor the paramQuantity’s min/max, etc.
Well… you are not really “fiddling with internals”. The UI for params and the processing of params already goes on in different threads. As you say going outside the declared bounds of a param would be a really bad idea. But rack is already fiddling with your params.
I think it would usually work. Of course for things are are not params you really would have to do something dangerous and crazy…
Slightly OT, but… I would love for someone with knowledge of the Rack engine, to do an overview in the development category, preferbly with a graphic, of the different standard threads in the Rack engine, their job/function, their speed and their intended usage but also how they can be safely utilized outside of that and how they should not be utilized.
Might be drifting even further off-topic, but generalizing your suggestion…
Maybe feed all available info on VCV Rack Development and API to an AI? Current Large Language Models (like GPT-4) offer ever larger numbers of Tokens (for I/O). By now they can gobble up entire sites (e.g. the VCV Rack Development sub site).
They also offer ever more options in various modalities (text, audio, image, video). Both on input side and the output side. And translate form one modality (e.g. image/audio) into another (e.g. text).
Also, they get ever better in interpreting and generating code (e.g. c++).
In general, they tend to do pretty well in interpreting, summarizing and wel…transforming…loads of structured/unstructured information from one form into another. E.g. proze into tables/graphics etc. or vice versa. But also transform a question (prompt) into an answer (response).
I bet that someone, more knowledgeable then I am on things AI/LLM, is able to manipulate some AI/LLM into digesting all things VCV Rack Development and API and coughing up an overview from some specific perspective (e.g. threads vs functions) in some specific form (prose, table, graphic). Maybe (also) create a VCV RAck optimized/specialized chatbot.
GPT-4 (Turbo) now offers the creation of custom GPT’s. Maybe someone might feel tempted (or inspired) to create a VCV Rack guru custom-GPT? Tuned toward answering any VCV Rack related question?
Its certainly possible. maybe a UI could look similar to Stoermelders CV Map. Just that all parameters are automatically listed and mapped (like with 8Face or Transit)…
- Param type, Param name, Param value, Param min/max (if available, else module restricts via logic), Param text (if any).
Clicking a Parameter in the list binds it to the next free channel, if min/max is true apply rescale accordingly, if not use global setting (default 0-5 maybe?)
then just 4 poly inputs for 64 channels or smt. It would have to be a bit wider than CV Map. anyone whos a bit advanced in c++ could probably derive the necessary code from CV Map and 8Face… it is basically just a combination of the two. CV Maps UI and Modulation capabilities and 8Faces ability to grab (almost) every Param of a module and apply values to them.
I wish I was good enough for that. But I don’t understand a thing about worker and GUI threads. Stoermelders code looked less confusing than expected, but still a bit too advanced for me. It looks very much doable though. Especially since most of the complicated parts of the code aren’t needed for this project… its mostly pruning and rearranging.
That could actually work to some extend. It’d be a challenge to decide what to feed it besides the Rack API and Fundamentals (VCV, Mutable Instruments and bogaudio) - because it’d be a rocky road getting all the misunderstandings left from bad code out of its system. Its either a very limited and thus very unimaginative or a “it worked there, it must work here” (but it wont) AI. My hope is that we can soon ask it to code and design modules for us. For that to happen we’d need to feed it the whole library, a shitton of github repositories, patch files and youtube videos so it may become versed in the whole process and culture.
Most definitely. It’s along the lines of circuit bending in the electronics world, allowing one to manipulate a module in “oh I screwed that up” ways. Circuit Bender might even be a good name for such a module.
For sure. We just would not want the bending to crash rack. “Crashing” the patch is okay