Amazing how something as simple as scaling the modules in the browser, a functionality which certainly should be in the software by default, becomes such a source of excitement for so many people…The developer certainly has his own ‘vision’ of such a things though…this and some more, like that crazy load of GPU the rack does…
1 Like
The developer certainly has his own ‘vision’ of such a things though
I think he’s just got an absolutely insane to-do list of things necessary for V2 and is having to ruthlessly prioritize. I strongly suspect that we’ll get a revised official module browser by (or before) V3. In the meantime, it’s great that the Rack API is wide open to modules so that @stoermelder’s work is possible!
Agree that the MB module is pure gold 
10 Likes
It does not do “a crazy load of gpu”. It uses more than is strictly necessary, but I don’t think the term “crazy” is a all justified.
3 Likes
In STRIP, would it be possible to select a group of parameters for randomization on a module?
I was playing out with Curve Sequencer and wanted to randomize all the Durations and all the Levels, but had to pick them to the list one by one. Just popped into my mind that with larger Curve Sequencers that functionality would be a godsend.
Yes it does, at least in my case(macbook pro 16). It eats through the battery in no time, like literary in 15-30minutes all the juice is gone, and it mostly the gpu…And there’s no way to justify that, all the modules graphics are mostly static…There’s an alternative which we’re not supposed to name 
which uses MUCH less cpu and gpu while sounding the same to my ear, so i suspect things could be done to improve the situation, but from the reactions of the developer to any criticism i doubt this aspect of VCV will change…its a pity, i’d love to use my laptop to work on patched while unplugged, but i just can’t afford it…
1 Like
I think it will change
2 Likes
Hi i have an quality of life feature request for MB. is it possible to sample and hold the mouse position on initial browser open and create the module at the sampled position instead of the position the mouse is at when clicked in the browser? (not any kind of coder 
)
You know that when you click and hold a module in the MB you can just drag it to where you want it.
3 Likes
I have an idea for a module which might or might not be useful for someone else, but i think it would def. make things more interesting:
Faderfox has the controller which can display names and values of the controls. It would be amazing have something similar in rack in the form of a module which shows the names of the parameters of any module mapped to the particular physical controls. I guess it could be an expander to midi-cat, or a standalone thing or something. The purpose would be to create a sets of control mappings which are easy readable in live situation, would be nice to have pages or banks or something similar. So when you switch from patch to patch you always have a reference of what exactly you can play with, and when you start a new patch, to have a quick way to start adding hands-on controls without getting lost…
You know what dude i did not 
definitely glad i asked tnx 
hehe
1 Like
This is definitely a valid request and there are a couple of controllers which would benefit from such a thing. Two problems here:
First, this needs MIDI SysEx which is not available in Rack v1 but will be in Rack v2.
Second, as it needs MIDI SysEx it also needs a specific implementation for every controller‘s protocol.
I guess someday a module for that purpose will be available, I‘m actually thinking about an expander for MIDI-CAT for quite some time. We’ll see.
3 Likes
So you mean the names would be ‘broadcasted’ by SysEx? That actually would be amazing, i’m thinking of building a little device using some development board so i could plug my newly obtained x-touch mini and first, send midi by bluetooth LE(cables are so 20th century…), and second, to have a little OLED display showing the labels and the values…If i could get those from VCV it would be freaking fantastic!!
And since i’ve mentioned x-touch mini…:
I’m setting it up in my template right now, and realized there’s a gap in communication:
If i want to use midi-cat in this situation i have to go through IAC bus(virtual midi), would be great if it wasn’t necessary…
Maybe. But you might get a long with a relatively simple “meta protocol”. I used to have a program called “Patch Master” that could extract / rename / copy patches from about 200 different MIDI devices. It has to “know” their patch storage protocols, but there were enough in common that a “universals” program didn’t even need to be as flexible as grep. like patch = [6 byte premable] (patch #number) [ 125 bytes of data][4 byte suffix]. not a great example, but you get the idea.
Voyetra Technologies Sequencer Plus Catalog 87A 1987 Voyetra Eight MIDI PC Compatible Products
1 Like
are you sure you’re in the right place?
5 Likes
i have just tested an x touch mini controller together with midi-cat and it works really nicely: if you set the input channel to all channels and the output channel to 11 you even get visual feedback on the led rings around the knobs on the controller when you move a mapped knob in vcvrack - so basically there is a proper two way mapping: turning a knob on the controller turns the knob in vcvrack and the other way around … there is only a small catch: the controller has two switchable layers and midi-cat seems to only send outputs when values changed (which makes sense in most cases) which means for this controller if you change a knob in vcvrack which is currently not in the active layer on the controller, then after switching back to its layer this change is not reflected on the controller as it seems to only update the led ring for the currently active layer … would it be possible to add an option to the mappings to constantly send the values back to the controller? this way it would be quickly updated to the latest values in vcvrack after a layer switch on the controller … please let me know in case the explanations are not clear enough
best wishes - hexdump
While technically possible I won’t flood the MIDI output with messages which are meaningless most of the time.
Besides that, I don’t really understand the concept of “layers” of this controller: Are you saying that the controls of the two layers are mapped to different CCs but won’t remember their last value when switching layers? How does this work with any other software? This makes no sense to me and sounds more like a configuration issue.
Edit: You shouldn’t have to set input and ouput to different MIDI channels in MIDI-CAT. Maybe you need two modules for the two layers for different channels but I’m pretty sure there is a working setup.
the controller has two buttons to activate layer a and layer b and with each layer the 8 knobs, one fader and 16 buttons send midi data on a different cc or a different note - example: first knob sends on cc 1 if layer a is enabled and on cc 11 if layer b is enabled and it is sending them on channel 11 always for both layers … the controller remembers its state for both layers properly if switching between them … by experimenting i found out that i can enable the lights of the buttons by just sending the button midi note at velocity 127 simply on channel 11 back to the controller and the same for the state of the knob and the led ring around it - the cool thing is that sending a velocity to the controller to a certain cc it really sets that knob on the controller to that value - so if i first move the knob on the controller, then the midi-cat mapped knob in vcvrack moves … now i can move the knob in vcvrack and due to the sending back the knob now is also on the new position on the controller too … the not so cool thing is that the controller seems to only evaluate the midi sent back to it for the currently active layer (i.e. if i would send a cc back to the controller for a cc knob in the inactive layer it will not have recognized that change when switching back to its layer) and for this it would be good if midi-cat could optionally kind of refresh-send the midi states back to the controller regularly (i think 2-5 times a second should be fine) so that that gets updated after a layer switch to reflect all the changes in the formerly inactive layer too … layer switching is completely inside of the controller and does not create any midi events btw.
I had a vision for a collection of modules that would help with adding structure to patches. They are designed to capture the features a DAW provides, while keeping the spirit of modularity.
Using them together, you have a way to record entire songs in Rack; there is an ability to scrub to particular points of the song, and adjust and/or add automation, audio, or midi data.
The most essential one is the one I called FRAME. There is also AUTOMATION and PLAY, which are similar to FRAME, and TIMELINE.
There are also MACRO and MACRO FRAME, as well as OSC and OSC FRAME.
FRAME
I drafted an svg a while back, but never found the motivation to implement it myself. Here it is.
I realized it is a bit cluttered after making it, but I really wanted it to be compact horizontally because I imagine using a lot of them in a song.
Basically the FRAME module ‘frames’ or captures a signal.
To record with FRAME, twist the SCENE knob to select which scene is written to, plug the signal into the IN port, patch a clock signal into the RATE port, and either press the WRITE_BUTTON or patch a signal into the WRITE port to enable recording.
When WRITE is active and only the RATE port is patched, FRAME will continuously record the signal into a buffer. When WRITE is pressed again, it will snap the length of the buffer to the nearest clock step as indicated by RATE and stop recording.
Alternatively, if you press the ADD button instead of WRITE, it will enter into ‘add’ mode. The behaviour of this mode can be configured to either be ‘Latch Replace’ (where when the input changes on a channel, the buffer is replaced for that channel (useful for adding more cv on other channels)), or ‘Sum’ (where input is continuously summed with the buffer for all channels (useful for audio overdubbing)).
The WRITE and ADD ports normally take toggle values, but also respond to continuous values, in which their effects are scaled by the ports value. For example, with .5 being on the WRITE port, the current audio in the buffer is not replaced entirely, but multiplied by .5. If .5 were on the ADD port, the input signal is multiplied by .5 before being added. I currently use a live looper called wayback and it works a similar way and it’s great for fluidity in live looping.
One could use the SCENE knob to record multiple takes to filter later, or to sequence recordings, or to crossfade between recordings in interesting ways if modulated.
The two buttons by the scene knob are called CLEAR and EDIT. The CLEAR knob erases a scene on press, and erases all scenes on long press. The EDIT knob pulls up a window where you can edit the signal recorded! Something that looks like this:
Each lane contains the buffer for the particular scene and channel. One could click and add points to the lanes, or decrease all points, or possibly copy and paste points… just look at a DAW for some feature ideas.
The red knob in FRAME is an amplifier for the signals read from the buffer. To mute FRAME for a bit, just turn it all the way down. You can set the levels for audio recorded using this knob. I also envisioned a circular LED strip indicating the current value of each channel going around the knob (sort of like VIZ, just in a circle) to be able to quickly see what a FRAME is outputting.
When FRAME has a buffer already recorded, changing the rate of the clock on the RATE port will increase or decrease the speed.
I went over the behavior when just the RATE port is patched with a clock signal. If you patch the POS port as well, the position will still progress at the speed according to RATE, but the position can be modulated with POS. Patch an LFO for example, to get a wiggly effect on playback.
When only POS is patched, FRAME does not progress at all, and records and reads signals at the point of the buffer indicated by POS. You could use FRAME as a granular engine this way, or patch other interesting signals into POS to read audio back in creative ways.
When both POS and RATE are unpatched, FRAME defaults to the RATE and POS of the FRAME it is touching on the left. When there is no FRAME on the left, FRAME defaults to the RATE and POS of the TIMELINE module.
When IN is not patched, FRAME defaults to the OUT of the previous FRAME on the left unless the PASSTHROUGH switch is active on that module - in that case, FRAME receives the IN of that module.
If OUT is not patched, the FRAME’s output is summed with the FRAME OUT on the left.
This unpatch and passthrough behaviour gives way to an easier interface for recording multiple signals. For example, to add a sound element that is 8 beats long in a 4 beat loop, simply duplicate the FRAME, activate PASSTHROUGH on the previous FRAME, and enter write mode on the FRAME and record your sound for 8 beats. Nothing else.
PLAY
PLAY is similar to FRAME, it is just for MIDI data.
The differences between FRAME are:
- Instead of a red AMP knob, it has a VEL knob that controls the velocity of notes.
- Instead of a circular LED strip to visualize the output, it has a piano roll that displays the notes being played (currently it’s a snip of rewin’s quantizer). The velocity is represented by the opacity of the led, or possibly the color.
- Write mode becomes a ‘Midi Replace’ mode, and add mode becomes a ‘Midi Overdub’ mode.
- Instead of an automation lanes edit interface when you press the EDIT button, it opens up a midi editing interface, similar to DAWs.
AUTOMATION
The AUTOMATION module is similar to FRAME, except it does not have an IN and OUT port, and is meant for recording parameter automation. When AUTOMATION is in write mode, twisting knobs of other modules records automation into the next available channel in the AUTOMATION module. When AUTOMATION is in add mode, you can add more parameters or latch replace existing ones.
Using AUTOMATION in conjunction with TIMELINE (by leaving POS and RATE unpatched) as well as FRAME, you can create songs in VCV Rack just like in the DAW! Simply record audio loops and possibly CV with multiple FRAME’s, and automate their AMP and SCENE params onto a TIMELINE position. Using this, you could play a verse for this many bars, then a chorus, etc…
AUTOMATION modules are also aware of one another. Multiple AUTOMATION modules can affect one parameter, their output is simply summed. This is similar to the feature of automation items in DAWs.
TIMELINE
This module serves as the global rate and pos for modules that have no RATE or POS connected and no neighboring FRAME (or PLAY & AUTOMATION) modules.
It has params and inputs for controlling the RATE and POS similar to the FRAME module.
When the TIMELINE position moves, the modules connected to it move as well. FRAME’s and AUTOMATION’s and PLAY’s that are looping also move in their position so to preserve deterministic playback.
I’m still thinking about the details of this module.
MACRO
MACRO is somewhat similar in functionality to this request https://github.com/VCVRack/Rack/issues/655 , except it integrates with an expansion module ‘MACRO FRAME’ to enable ‘freezing’ of macros.
MACRO is a column of inputs and outputs which define the I/O for a strip of modules. They introduce a higher level of abstraction - a collection of modules, a ‘macro’.
Ideally, this module could collapse the modules in the macro into itself so all you see is the relevant I/O, as well as possibly textual labels about what they are. However, even if this would not be possible with current API, implementing MACRO would not be pointless. You could still quickly save and load macros, and audition different macros of similar type (e.g. ‘modulator’, ‘sound source’, ‘audio fx’) without needing to repatch everything.
I also envisioned the ability to easily route between macros. Instead of patching macros together, one could press a TOGGLE button on a specific output port, and twist an input port of another macro to send more and more signal to it. This would enable easy automation of patching, without involving huge routing matrices with many redundant knobs. It would also enable an ability to control patching via OSC. Unfortunately in the current model, this may require infinitely rotating knobs, which is something I am not sure VCV supports.
MACRO FRAME
FRAME for macros!
Basically, it is like FRAME, except it is placed next to a MACRO module. The core function of this module is to record the output of a MACRO, so that when the MACRO FRAME enters read mode, the modules inside the MACRO are automatically disabled, thus saving resources.
You could think of this as freezing a track with an fx chain in a DAW, except the track has many outputs which may be audio or cv.
This module would theoretically allow one to create huge patches.
OSC
OSC stands for OpenSoundControl. It is an internet protocol that sends values to an IP at some address (like /slider/2). I have started using it to control VCV Rack via my Surface and an interface I made in OpenStageControl. The interface makes the process of creating sounds I hear in my head so much more comfortable. There is no clicking involved, you can adjust multiple parameters at once, and can do so very rapidly.
Here’s a picture:
Currently, I do this by sending OSC data to REAPER, and then sending MIDI CC data to control parameters in Rack.
The vision for the OSC module, is to convert osc messages to parameter automation. It is similar to trowaSoft’s cvOSCcv, except instead of converting received osc values to cv, it uses them to modulate parameters.
Having this restriction has the bonus that
- Mapped parameter names can be sent back to osc for display.
- Values are automatically sent back to osc for display when the parameter changes.
The OSC module would be able to handle much more mappings than trowaSoft’s cvOSCcv. I image an interface similar to CV-MAP, except there is a place to input the address.
The OSC module integrates with the OSC FRAME module, an expander for it.
OSC FRAME
OSC FRAME is similar to MACRO FRAME, it also records and is able to playback, add, edit. and rewrite the output of the module it expands ( in this case, the OSC module).
OSC FRAME integrates with OSC and the device sending the OSC messages. OSC data that was captured by OSC FRAME and is being played back, is sent to the osc device for display.
This would mean that the knobs in the image above would move according to the actual values of the parameter they are mapped to. In theory, one could play back a song and watch as the knobs in the osc interface morph in time, and optionally latch replace or clear certain movements.
In conclusion, I think these modules would do wonders for structure and usability in VCV Rack. I hope someone else thinks this vision is as cool as I think it is. I thought quite a bit about how to go about bringing in some of my favorite features of the DAW, as well as OSC, into VCV Rack and this is the best solution I could think of. I think this collection of modules would form such an amazing music interface, it could even make the most artistically inept into sound wizards.
1 Like
At the risk of diverging too much from the stoermelder thread, have you checked out the Entrian Sequencers? Different interface but you’ll find a lot of the DAW-like features from your first three modules there.
1 Like