Continuing the discussion from Rack v1 development blog:
@Vortico Will there be a dev v1 bridge plugin made available before the public launch of v1?
I’ve tested the current bridge plugin, and whilst audio functions perfectly with audio, MIDI isn’t functioning on my system (Win 10, Ableton Live 10.06).
Bridge is offered as-is in v1. No changes have been made since v0.5 or so, but its support hasn’t been outright broken or removed. It will be in v2.
Great to know that it will be still usable up to V2.
Initially i wasn’t all too positive about bridge, since it didn’t work for me in Reason.
But since lately that Propellerheads fixed some issues with Reason, bridge is working perfectly for me.
So i am suddenly using it much more instead of external virtual routing.
oh hold on, i read wrong heheh,
It will be removed in V2…
hmmm okay 
Luckily Rack will be available as a VST plugin for around $100 shortly after Rack v2 is released, and it will solve the problem in a “correct” “industry standard” way, so Bridge will no longer be needed.
So what you’re suggesting here is that maybe the problem that I’m encountering with MIDI is specific to Ableton? I’ll test again to see if my initial problem was user error on my part.
I was aware that v2 would introduce a VST version of Rack but not that it would mean that Bridge will no longer be available, nor that Bridge would be frozen through the v1 lifecycle to it’s 0.5 build capabilities. Not that I feel this way, but some may view this tactic as a tax on DAW integration. When you build a community on the back of open source values, not continuing to offer Bridge may be viewed negatively.
For me the value of paying $100 for the VST version of Rack isn’t DAW integration per se, it’s multiple DAW channel instances of Rack (to take advantage of multiple processor cores) and floating point DAW automation capabilities.
I could be wrong but I think it might be wise to rethink this strategy. Not necessarily by gauging the feedback on this forum as it’s something of an echo chamber for Rack loyalists, but by measuring the chatter on wider social channels.
Bingo, that’s exactly what it is. The mission of VCV Rack is to be a standalone platform itself. Most users are fine with this. If I used the funds made from their VCV plugin purchases to finance a port to the proprietary VST2/AU/AAX/etc formats, I’d be misusing their funds. Those funds are reserved for improvement of Rack.
The fact that VCV Bridge is discontinued is because it was a horrible idea from the start and needs to be killed. Cross-application audio has never been a good idea for maximizing stability and compatibility with DAWs. VCV Bridge works well for less than 50% of people. That’s absolutely absurd for a project with VCV’s name on it. Currently the software is “hanging onto the thread” of people needing it for DAW recording, but as soon as there is another alternative, I can finally kill it.
It is well-measured. It is clear that the thought of the average Rack user is “if it works in my DAW I’d totally pay for what it’s worth to me.” I’ve estimated that value at around $100.
All very reasonable answers Andrew and ones that I mainly agree with. What I don’t agree with is not supporting Bridge up until the point that v2 is available (btw I’ll be near the front of the queue for the VST version as it’s critical to the way I work).
The points I rose were in part informed by the feedback on the GPLv3 thread and in part by thirty or so years observing similar projects move from free and open source to either part or full commercial projects.
VCV Rack is your IP and you’re free to change licencing terms and monetize your efforts as you see fit. My comments were simply food for thought.
I’ve promised the community that I’d continue to include bridge.cpp in v1, so I can’t remove it for v1. Otherwise it would make technical sense to do so.
In no way is the trajectory of Rack moving in the “part of full commercial project” direction. VCV is an organization that has done part commercial / part open-source software since Nov 2017, but Rack will always be fully free, just like Linux, Blender, GIMP, etc.
It works swimmingly for a certain audio server 
It really is a shame that the industry is stuck in its ways.
If you’re comparing the stability and ease of workflow to hosting a DSP kernel inside an application in the same process space, it’s pretty unreliable. Propellerhead ReWire is about the best solution that exists, and most people still have difficulty with it and just give up.
ReWire and JACK are good solutions of the problem of cross-process audio. It’s just a problem best avoided if possible.
@Vortico
I’ve now tested Bridge with the latest dev build of Rack in Ableton, FL Studio and Reaper. The results were as followed:
Ableton: Audio - pass; MIDI - fail.
FL Studio: Audio - fail; MIDI - fail.
Reaper: Audio - pass; MIDI - fail.
Both Ableton and Reaper function as they should with the current 0.6 builds of Rack but FL Studio fails both audio and MIDI (I suspect the FL Studio situation is a known problem).
Considering both Ableton and Reaper fail with regards to MIDI, it’s possible that the problem is a bug with the v1 dev build rather than the 0.5 Bridge plugin. It seems certain that the problem isn’t isolated to a particular host. Maybe the problem is associated with Rack’s new polyphonic capabilities.
From a personal perspective if this situation isn’t resolvable it will mean that I won’t be able to transition to v1 builds of Rack as it breaks too many existing projects. I think it’s likely that I won’t be the only Rack user that will suffer broken projects if MIDI communication is broken between DAW and Rack up until the point that v2 is launched.
Stability-wise I’ve not had the JACK server crash. Or software crash because of interfacing with it. And tools like Patchage make it really easy to figure out the signal flow.
Saving/loading entire sessions does take a bit of orchestration though 
Will v2 literally be VST only or will an AU version be available? I’m using Logic (currently with Bridge) which is why I’m asking.
I would really value an AU version for Logic as well. I’d like to mix VCV Rack with my other physical acoustic and electric instruments within the Logic environment.
If it becomes available, it would be what gets me to start investing in the paid VCV modules, knowing I can use it in my regular recording projects. I have to admit, the thought of that is very exciting and would be very useful to me.
I haven’t “battle tested” it (not a serious musician here, just messing around for my own satisfaction) but I’ve successfully used VCV rack in Logic by setting it up as an external MIDI instrument, much as you would a physical synth.
The only extra you need is a loopback audio utility to route the sound from VCV back into Logic - either Soundflower (free) or Rogue Amoeba Loopback (commercial, and rather expensive IMHO if you just want the basic loopback functionality - they’ve added an elaborate UI, though, which may be useful if you want to combine VCV with other ‘external’ sound sources).
The ‘IAC Midi Bus’ which does the same thing for MIDI is built into MacOS.
Then, set the audio module in VCV to outpu to Soundflower/Loopback, and the MIDI module to use the IAC bus device. In logic, create a MIDI track that outputs to IAC
Meanwhile, if you’re trying to use VCV Bridge with logic, when I last tried it, I needed to go into Logic preferences and change Audio -> General -> Sample Accurate Automation to ‘off’. Otherwise, Bridge died screaming when it tried to translate parameter changes into MIDI CC messages at 96kHz…
what i do in win10 is maybe a bit much for any operating system, especially windows due to the driver inception i’m about to explain.
i use JACK in conjunction with Synchronous Audio Router and ASIO4ALL. SAR is acting as a wrapper for ASIO4ALL and i use it to make extra inputs and outputs. JACK is starting up the SAR asio driver and from there i use Catia to make the connections. At this point i can just route everything into everything.
pretty neat, eh
For ableton i use JackRouter asio driver (i configured JACK so that it creates 16 i/o), and skrylar’s jack plugin is doing the work for VCV (also creating 16 i/0)
For synchronization between Ableton and VCV i use loopMIDI or loopBE1 so i can use infinite amount of midi i/o tho i only need maybe 8
This setup with window’s built in sound mixer is just plain crazy because there’s no limit now, i can send all sorts of audio signals into rack into ableton into rack into ableton. Useful for OBS, too.
Though, having said all that, i experience frequent crashes and either VCV or the JACK plugin is to blame, i can’t seem to pinpoint what the exact cause is but VCV would just straight glitch out and cause some really nasty feedbacking sound system-wise, and as soon as i force close VCV everything just goes back into place and win and ableton continue to produce sound just fine.
Dan,
Compared to using Bridge (which is available as an AU) having to fuss with IAC and Soundflower is a huge step backwards. I’ll gladly pay $99 for a plugin but VST is useless in Logic. It’s a simple question, will AU be supported.
IKR. This seems like they devolved VCV Rack. I know for one that i would pay for the VST if it meant that I don’t have to jump through all these technical hoops just to record my patches. I got $99 let’s go, or just offer us a updated Bridge solution. I mean I understand the rendering issues and latency and all that, but let us put up with it, it wasn’t that much of a deal breaker it at all. Very confused as to why VCV made this move. One word of advice to the devs of this great product don’t screw it up for the sake of greed.
Sorry, I missed this. AU is not confirmed but will be evaluated before Rack v2 is released. If approved, it will likely released several weeks after the initial Rack for DAWs release. If you purchase Rack for DAWs, you’ll get the AU version in an update. All updates will be free after purchase. (Paid updates of the same product isn’t how we do things at VCV.)
See Frequently Asked Questions - VCV Rack Manual. If you talk to any audio software expert (including me), they’ll tell you IPC audio is a joke. Mutexes in audio are well-known as a Bad Idea™. Now imagine that but a tenth the reliability. If you want to adopt VCV Bridge, you’re free to do so. It’s open-source. But there’s a reason no programmer of sane mind has touched that code.
Take a guess at how many tech support queries I’ve gotten about VCV Bridge. Probably 1000-1500. Now guess how much money I’ve made on it. Probably negative $ because everyone says “Wow, this shit never works, VCV sucks.” You’ll then see why I decided to kill the project, really easy decision.