That’s not in VCV - Community Rules from what I can tell. You might want to update that before swinging the ban hammer around in full view. Yes, its your community, you can enforce rules as you please, but it’s also just a bad look to enforce rules that don’t exist.
I also wasn’t condoning piracy in the traditional sense, as I directly said “I will legitimately pay for it”. I 100% agree that VCV, and every software developer or creative, deserves to be paid for their work! Paying for a product but then waiting for the DRM-Stripped version is actually fairly common practice among gamers where the Denuvo software is know to cause significant performance impacts making the experience worse for customers that don’t do this, this is why many big game publishers will actually remove the DRM from the official release once it’s been cracked. I am very glad to see you’re using the same DRM that has been used up to this point as I’ve had no issues with it despite having VCV installed on all of my computers and in both Linux and Windows. Thank you.
I will not talk about copyright infringement or related topics further as that rule is now clear; however as you and I have directly talked about community relations before I think you can understand how just coming right out with this threat is extremely concerning to me.
My happiest congratulations for this huge milestone! I am loving the new design from what I can see in the video, the idea for the patch cable pointer is awesome.
Thanks, looking forward to the release!
At least I don’t think replicating / putting a new take on XFX Wave is out of the question, though it does have some amazing tables and effets I would miss - I think half of my patches use the Viking table with the Juno effect Loosing XFX Overdrive would be a hit too. I’ve been using Vult’s Flame as my go-to since I bought it, but prior to that the XFX one was my go-to. I also haven’t given the AS SuperDrive that much of a shot, and I guess any mono-drive works well with Stoermelder’s Mirror so ¯\_(ツ)_/¯ I suspect the release of VCV2 and especially the VST will drive enough development to make up for whatever doesn’t get ported reasonably quickly.
Also, I got permission from Aria to update her modules to 2.0 with her name still on them so long as it’s only update & fixes, not like redesigns and new features, so assuming porting to 2.0 isn’t a massive pain with that codebase that’s one less loss too.
I know quite a few devs have actually fallen away between the release of 1.0 and now, but in a way I’m looking forward to that? Like, having some modules need replacements may inspire better alternatives to get made.
@Vega took the warning, clarified, and (reasonably IMO) suggested that the rules be explicit on this point. Communities figure out norms together and it’s a bumpy process. Let’s none of us (myself included) derail the glorious Rack 2 announcement thread!
This is great news. Really happy to hear that. They’re such fantastic modules.
Assuming this is a good place to off shoot some questions from the development-blog now that it’s announced:
Added fix suggested by @stoermelder to allow plugins to register their own audio/MIDI drivers. For example, it will be possible to create a plugin that installs an audio driver that communicates with an Arduino over a serial connection and exposes CV as a 1000 Hz audio interface.
Will these work in the VST still? I suppose that’s part of the larger “Will extra audio interfaces work in the VST” question too
// Short circuit outputs to inputs when bypassed
Will bypassing a module still incur a 1-sample delay from the “ghost” module?
Yes, the audio/MIDI driver API will still be available when running as a DAW plugin. If you interface with exclusive audio/MIDI APIs, it will obviously conflict with the DAW, but if you’re writing a driver for your custom hardware (serial USB for example) it’ll work fine, just like in the standalone version.
Technically modules don’t create sample delay, cables do. So bypassing a module will result in the same 1-sample latency relative to using 1 cable.
This is great to have confirmed, and I’m taking it directly to Lippold Haken regarding some very interesting I2C ports that happen to exist on some very interesting controllers
This is too platform/setup/config-specific for me to ask it as a question, but I hope that, whether by FlexASIO or other trickery, the Main I/O <=> DAW <=> VCV Rack VST <=> DC-coupled I/O can be made to work, as the possibilities for that are absolutely bonkers.
So, effectively, cables don’t merge when associated modules are bypassed and split when they’re re-enabled. I’m glad to hear this–in addition to keeping the volt-propagation code considerably simpler, if bypass could change relative timing/phase it would be much less useful in certain situations.
(I know that the theme for VCV 3 is ultra-high performance; maybe the theme for VCV 4 (or 5 or 6) will be graph-theoretic approaches to 1-sample delay management? Joking (mostly), just extremely excited for the future of this platform.)
Also, a bypassed module just calls processBypass() instead of process(). The default implementation is to apply bypass routes configured by configBypass(AUDIO_INPUT, AUDIO_OUTPUT), but you can override it if your module bypassing is more complex.
Fantastic news @Vortico !! Congrats on hitting this milestone, it’s been a slog.
How rapidly do you expect the AU plugin to follow 2.0’s release? I’ll likely purchase VCV2 when it’s released anyway to support the project, but I won’t make the switch until Logic and VCV can integrate.