VCV Rack 2 teaser

Another article just appeared in my inbox today from the Bedroom Producers Blog. Aside from the ads, it’s a pretty good website/blog. Although they mention that the entire Instruō line is available in VCV. Is that true for VCV 2?

2 Likes

I guess we can hope but the last time we were told anything about it there was some doubt as to whether the more digital modules were possible.

1 Like

Great news! Can’t wait! Particularly excitied to use the VST in Logic Pro! :grinning:

Got a question, if I purchase Rack 2, will I have to eventually purchase Rack 3? So on so forth…

Yes. In as you will have no choice in the matter. If you buy vcv 2, you are obligated to buy vcv 3 (which currently doesn’t exist)

Don’t be afraid of commitment :slight_smile:

5 Likes

Hey, All! Nice to know that soon we will have VST! What will be included in paid Studio Version except VST support?

The VST-Plugin and customer support by VCV.

2 Likes

:blue_heart:

I was wondering before installing the v2 if the library is shared between v1 and v2…

I know somebody had already installed it…if I install it, will it automatically update for all the available v2 plugins? (on linux and win here)

Tried v2 last night, signing into the library didn’t produce any updates available. Might be a while before that starts working.

1 Like

This is a beta build of VCV, which installs in its own directory. Every Module-Library you would like to add to this build has to be a V2-compatible build and I think you will have to add it manually to the subdirectory. There are already a lot of developers building their modules against V2, so there should be beta-versions of those available from them in the near future I hope. The installation of V2 does not override anythink from V1. At least that’s my observation so far.

2 Likes

Very late to this party, just come across the news - Fantastic!! Can’t wait to become a Studio Edition owner :crazy_face:

I saw one post that particularly interested me…

It would be amazing to have this functionality, of course… But I find it very unlikely this will be a feature (unless someone in the know wants to happily correct me!)

I’m not aware of any VST ever made that can I/O directly to/from sound devices (at least on Windows, and at least to ASIO drivers - I think there was one that connected directly to MME, a long time ago…) - though, again, feel free to correct me :wink: - I mean, I’d pay the price of Studio Edition just to get that one thing!

There are actually VSTs that can transfer audio to and from a connected synth while running another soundcard as main audio device. The Virus TI and the Elektron Boxes (Digitone, Digitakt, etc.) and I think some Roland-Synths too.

My first experience with using two audio devices in Rack2 today was a crash when selecting the second output device. But after restart it worked with both devices running.

2 Likes

Of course, I forgot about those… Perhaps it is a possibility in that case!

1 Like

The only build issue I had was a newer C++ idiom used for moduleSlugFallbacks. Since this was a simple well contained failover, and I suspect I can code a replacement if really needed, I ifdef’ed it out, and the beast builds and runs on Slackware 14.2 with GCC 5.5.0. Whether my non-opensource plugs will continue to work or will want later libstdc++, libc, libm, or libgcc_s is another matter altogether. May I please suggest authors keep backwards compatibility in mind. Thanks.

GCC is very easy to build these days. Newer versions bring better performance. Just download the source code and run:

./contrib/download_prerequisites
./configure --prefix=$HOME/local --disable-multilib
make -j$(nproc)
make install
# In your .bashrc:
export CC=$HOME/local/bin/gcc
export CXX=$HOME/local/bin/g++

I’m a little concerned that I’d need to replace the whole tool chain and libc/libm/libstd++. That gets a lot more painful. If it were just a compiler replacement, I’d not be kvetching at all. I might have a go at that with FalkTX’s fork of Vital though.

I’ll certainly agree that the build is a lot less painful than it used to be, much like the difference between building SBCL vs CMUCL. ( Why yes I do have a Lisp fetish. :wink: Smalltalk too. )

Compiling GCC from source uses your system’s glibc, and Rack and Rack plugins statically link libstdc++ and libgcc on Linux, so there should be no worries of compatibility like ABI mismatches.

My concern is more about plugins delivered as blobs. (Vult, Blamsoft, Hora, etc, etc, etc) I don’t get to decide what library versions they want. I suspect that barring significant hacking, I will have little difficulty building Rack given today’s experience. I was actually quite surprised the all the dependencies built without issue, and the only thing was the tiny thing in src/plugin.cpp which admits a pretty trivial workaround. I get what you said about the C++ libraries, but there are some version check on libc and libm that some recent things fail. I might be able to do some magic with patchelf, but now we’re getting into the dark corners of Linux where all bets are off.

If Pat V. ever gets Slackware 15 out the door, I shouldn’t have much problem as there’s a far more recent toolchain /library setup bundled.

Since all plugins distributed on the VCV Library are required to be built against glibc 2.23, you should be able to load them into Rack built by any GCC version.

3 Likes