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 time 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.
When FRAME like modules are connected to the TIMELINE, they do not enter a loop mode when exiting writing. The loop bounds are controlled by the TIMELINE module via some interface.
I’m still thinking about the details of this module.
Though the main requirement is just for deterministic playback of multiple FRAME like modules.
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 via OSC. Instead of patching macros together, OSC could send a message to toggle ‘send mode’ for a certain output port. In send mode, you can 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, as well as a touchscreen interface for patching and ultimately rapid sound design. More on this point in the example workflow section
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 and playback the output of a MACO.
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 order for an even better integration with OSC, some ‘mux’ like modules for selecting which FRAMES or MACROS are active for control may be necessary. There may be too many of these to fit on an OSC screen, so a selection mechanism may be necessary.
So what would the workflow with these modules look like in practice?
You first make your macros, or you download other peoples macros, then you set up OSC to control the parameters of the MACRO module, or multiple MACRO modules. Let’s say your OSC looks something like this,
Except it has parameter names for the knobs, as well as a a macro selection switch to audition different macros (and when you do that, the parameter names change).
Let’s say the red macro is an oscillator and the blue one is a lfo. You want to modulate the oscillator with the lfo. Routing between macros in OSC is as easy as holding down one of the knobs, and twisting another knob. Since all these modules are well integrated, when a knob is held and put into output mode, it’s parameter name is replaced with the output name, and all other knobs display attenuation values for that signal.
So you set up some routing between these two macros by holding down the LFO output knob and twisting a parameter in the oscillator, Now you have a cool sound and want to record it.
First you set a fitting clock speed for your TIMELINE module and set up a loop for the beginning 4 measures. Then you record MIDI data you play with your keyboard via PLAY. Alternatively, you could use a MACRO that outputs PLAY like data, such as an arrpegiator, sequencer, etc, and route it to control the gate, velocity, and pitch of the oscillator. In both cases, either with PLAY or MACRO FRAME, you write the signals and set up a loop sending the signals to the oscillator.
Then, you put the OSC FRAME into add mode and automate some parameter changes of the oscillator in the loop. These changes repeat in a loop and are reflected in the OSC interface as the knobs wiggle.
Now you got a nice, dynamic sound that’s looping and you want to record it to be part of a song. You set the oscillators MACRO FRAME into write mode, exit at the end of the loop, and there, it’s recorded. The oscillator is disabled and you can use your cpu for new modules and macros.
Ideally, the process above can all be done via OSC via mappings that control these various FRAME like modules.
You then repeat the process for other macros at different timeline positions, you automate MACRO parameters and routing via OSC at certain timeline positions as well.
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 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 probably make even the most artistically inept into sound wizards.
