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.
definitely glad i asked 
tnx 
hehe
