Please check out all the other long threads on vcv on the new apples. And, yes.
Plugin developers with a plugin in the VCV Library will receive a free VCV Rack Studio Edition license a few weeks before its release, in order to test their plugins in their favorite DAW. We will use the email address or website in their plugin manifest to contact them with further details.
Ok great thank you
We will not be testing Rack 2.0 on Apple M1 hardware. However, you may be able to run Rack 2.0 using Apple’s Rosetta 2 software.
wonderful thank you so much
I’ve been using VCV 1.1.6 on my M1 since January and I haven’t had a single issue with it. The Rosetta 2 wrapper is working very well.
Has “engine threads - real time priority” for Mac OS been enabled/fixed in 2.0?
As i am using the DImdeep fork now, instead of the official 1.x because of this.
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.
Hell yes, VST integration with Ableton and my modular setup. Superb!.
Rack 2 processes modules in the audio thread instead of a separate “engine thread”.
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.
[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.
is the beta phase of VCV-Rack 2 starting in November or is this the release date?