Someone said Christmas comes early this year. For me, every day is like xmas in VCV Rack. I can find unexplored territory every time I open it with hundreds of modules I’ve never patched with, a bottomless well of amazing video tutorials, and thousands of great examples on patchstorage. And thanks to this gift-giving software, the inevitable growing interest in hardware synth. So excited for the release of VCV 2. Thanks @vortico et al. VCV Rack will always be a foundational cornerstone in my musical adventures.
4 Likes
Hell yes, VST integration with Ableton and my modular setup. Superb!.
3 Likes
Rack 2 processes modules in the audio thread instead of a separate “engine thread”.
1 Like
does this mean, in theory, a bypassed module could still provide some of its function- like a mixer, when bypassed, just doing a unity sum?
I think it means that a bypassed module can do anything it wants (including calling its own process() and thereby refusing to bypass). I assume that bypass conventions will be specified in the V2 API docs and may evolve from there. IDK if there are a ton of obvious use cases but I could imagine modules wanting to keep sync, consume control inputs, participate in expander relationships, etc. even in bypass. I’m guessing that processBypass() might not get overridden very often, but it’s very good (and very Rack-like) that it’s there.
Your example is interesting. A “powered” mixer becoming a unity mixer might be a little surprising, but on the other hand I’m not sure there’s a better bypass behavior for a mixer (since muting or picking a single input to pass on would be surprising as well).
Maybe someone will write an “active” unity mixer that, when bypassed, realistically simulates passive nonlinear mixing behavior, or an “active” mult that, when bypassed, realistically simulates passive mult voltage drop. Anyone? 
processBypass() could do that, but for that example, I’d just leave it unimplemented since users would most expect silence. Think of bypassing as disabling. When you stomp on a guitar pedal to turn it off, it routes inputs to outputs. When you turn off a mixer, it outputs silence.
An example of when you’d override processBypass() is if your module has alternate modes/firmwares with different routing.
All of the yes.
1 Like
[edit: since Announcements isn’t the place to further explore a specific topic I moved my response over here along with a summary of the existing discussion in this thread]
That approach is clear and intuitive, but in addition to expectations (which are set by convention as well as first principles) there’s also the question of what behavior the user wants or finds most musically or diagnostically useful when bypassing.
Consider VCV VCA; it seems immediately obvious that the bypass effect would be passing the input to the output at unity. Cool and useful.
So then what about VCV Mixer in bypass? I’d assume that In 1…4 would go to Ch Out 1…4 (since they’re effectively four separate VCAs) and, per your point above, the Mix Out would go silent (rather than becoming a unity mixer). OK.
But what about Audible Quad VCA, then, with (say) inputs in 1 and 2 and output 2 (but not 1) connected? Does bypassing turn off the normalization and mixing, so that In 1…4 go to Out 1…4 but there’s no longer any mixing down? I could definitely imagine wanting to bypass the VCAs in Quad VCA while preserving the routing and mixing (say I was modulating a LFO’s amplitude with another LFO on VCA1 and then applying a DC offset in Channel 2, then taking the mix out of Channel 2, which I think is a pretty typical use of Quad VCA; I’d be annoyed and a bit surprised to just get the DC offset out of Channel 2 on bypass, instead of an unmodulated but offset LFO).
I suppose if a design really had more than one reasonable bypass mode (which I suspect is uncommon, although Quad VCA might be an example), there could be a right-click configuration setting that processBypass() could consult–another advantage of having it be an overridable call and not a static configuration.
In terms of expections (and which mode to pick as the default in the multi-mode case) we’ll of course have canonical examples in terms of what the VCV modules do in V2 when bypassed, and I’m guessing there will be some suggested conventions in the V2 docs…
Pity. I hoped in some gain. So still “nocona” (i.e. Pentium 4) is the target, right? Neither SSE4?
Will Rack 2 have support for multiple separate audio inports (from the VST host) when used as an effects unit, or will it only take a single audio stream?
Apologies if already answered…When can we pre-order?
Starts at 19m46s, a long haired Andrew shows off Rack v2 at Knobcon.
1 Like
Hi Andrew,
is the beta phase of VCV-Rack 2 starting in November or is this the release date?
Erik
I feared the V2 saga may have taken its toll on Andrew - but instead he looks about 10 years younger!
3 Likes
I wouldn’t add any bypass routes for this. If the module isn’t an “effect” in a signal chain, the user likely wants to mute/unmute the output with the bypass menu item or key command.
I’m not sure I understand the question. You can use up to 8/8 inputs/outputs with VCV Host-XL today in Rack 1.
We won’t be offering pre-orders for Rack 2 Studio Edition. It will be for sale when the product is available.
5 Likes
I think the question is, when you use Rack as a VST will it have more than one stereo audio input? What most plugins would present as side-chain inputs. Or is the plugin version a VST Instrument rather than an Effect?
Are there any differences in buying modules between community and studio version?