Bumping for 20 characters of update.
Chugging along. News soon. I got distracted for a while working on Ableton Link for norns, but that’s on hold until after 2.0, so I’ve been poking at Rack again.
There is a brand new, very experimental CI build for Linux posted on the releases page, produced by a GitHub Actions workflow that I put together last week, if any Linux users feel like doing some QA. The zip is labeled 0.6.0 but it’s built against the Rack 0.6.2 SDK. Still working on the cross-compiler containers for the Windows and Mac builds.
Absolutely mindboggling! Thanks to all involved
I teach a class on Music Technology in the Marketplace at Berklee and the “textbooks” are Ableton Live Intro version and VCV Rack…
Rack is an amazing way to introduce modular synth concepts.
For folks trying out the VCV Rack 1.0 prerelease builds, here’s an update built against the 1.0 SDK.
For the first time, binary packages are available for all three operating systems!
Patient early testing would be appreciated, especially on Linux.
1.0.0-pre release notes:
- Most known, reproducible issues with 0.6 have been fixed (crashes on grid disconnect, etc.)
- Support for older grid hardware (40h/series protocols) has been temporarily removed.
- The virtual grid modules can only be used if your thread count is set to 1. Communication between modules and virtual grids is not yet thread-safe.
- All of the modules are currently monophonic. Future modules might have polyphonic outputs.
- Future feature roadmap is online here. (No promises, just documentation of the current thinking.)
One of the new features in Rack 1.0 is the ability to use multiple threads to execute the module graph if you’re on a multi-core CPU. The default is still single-threaded.
If you’re using the virtual grid modules, leave Rack’s thread count set at 1 or you’ll eventually run into a crash. The module-module communication was written for single-threaded Rack 0.6 and isn’t yet thread-safe.
Here are four potential solutions to this:
- Do nothing – require that Rack be set to 1 thread to use the virtual grids.
- Leave the existing right-click connect system but add appropriate protections to make it thread-safe. Same experience, no new features, moderate amount of work, unknown amount of future maintenance/risk, since this isn’t an officially supported technique.
- Use Rack 1.0’s new polyphonic cables to carry module-grid communication. This would mean adding a serialosc module to the library, you’d pick a monome device from a drop-down like in Max (or like Rack’s MIDI interface UI.) Each of the modules would get two new in/out ports in place of the vestigal USB connector. You’d have to wire up two cables, one for each direction, between the function module and either the serialosc module or the virtual grid module. It would be more work to set up connections, but you could do interesting things like use standard switch modules to cycle one grid device through several controlled modules, or have a virtual grid mirror the display of a real grid, etc. This would be a moderate amount of development work but it would be using an officially supported method.
- Use Rack 1.0’s new “expansion connector” system that allows modules to pass messages to its immediate neighbors on the left and right if they’re from the same plugin package. This would be an elegant way to set up connections, but it wouldn’t be very discoverable, and each module would have to be next to a serialosc module or a virtual grid module – you couldn’t separate them in your layout. I could add a switch on each module (where the vestigal USB jack is now) so you could swap one between its left and right connections, either swapping a grid between its two adjacent modules, or a module between two adjacent grids. But only two at a time. This also would be a moderate amount of development work but it would be using an officially supported method.
Do those scenarios make sense to people who haven’t been following the Rack 1.0 development? Thoughts on what would be the best experience long-term?
i really like the idea of #3!
(p.s. just getting started with the repo… im trying to prototype alternative firmware for ansible and your work here is really amazing )
Does anybody have any luck with any of the install methods? I have tried the terminal based methods on the github to no luck and have downloaded the 1.0 pre-release Mac version but can’t seem to get the right version of VCV Rack, nor install it or this current version…
Sorry if that is all newb questions, just a bit confused…
Nevermind. Just dropped them in the /Documents/Rack folder… Guess I’ll do some testing and hopefully it all works! Thanks!
Okay, last posting on this, but these are absolutely unbelievable… Thank you so much for your hard work. This is endlessly inspiring.
Anyone else have an issue with Earthsea randomly losing control of the edge output? Works fine at start and for a time afterwards, then always eventually goes constant on and doesn’t respond to key presses on the grid.
Am still learning these modules, so forgive me if I’m missing something obvious!
Windows 10, modern 128 grid, VCV 1.1.4
I will be giving Eathsea a shot this weeked. I am running on MacOS but the issues might still be the same. If I see an issue, I’ll let you know.
Consequentially, is this running the v1 or v2 version of Meadow physics?
Okay, having played with EarthSea a bit more, I have experience some minor issues with the Edge param as well. It gets stuck being open. I can still change position, but it doesn’t close the gate.
Well done ! Having fun with a monobright
As a modular/vcv newb – how would people go about patching something up Meadowphysics so it triggers notes like the max version? Tried a few things but there’s no way to search all available modules afaik.
Would be a nice add integral to the module. @dewb – am I correct in assuming that the preset page doesn’t work? I can open it and set, but rack never remembers or recalls. Would be excellent to repurpose this page as a cv/tone map per row.
You can do it with the default patch and the built-in modules only like so, with the knob in the red circle controlling pitch:
Yeah, the meadowphysics Rack only sends out triggers. No note value. As a result I’ve found it a bit tough as a newcomer to a rack. Basically you would only be sequencing triggers and need to use something else to alter not value and Velocity on the side.
Ah, yes. I was thinking/hoping for something that wasn’t 8 separate VCOs
don’t remember if there is a way to change it to gates? but if there is, one thing you could do is plug several gate outputs into a mixer and use that to drive pitch (you might need to put it through a quantizer first though).
Squonk from Nysthi can be useful for this:
Here the first 5 triggers from MP are each assigned to a row in Squonk. The A column from those rows is then sending CV out to the evenVCO. I have a quantizer in there too because I’m no fun.
It’s a bit goofy but it works. And Squonk kind of makes up for the goofyness in that each trigger from MP could theoretically be sending out 5 different CVs simultaneously.
This is an interesting option. If one has a norns available, one could use the MP script and patch to both V/Oct and gate from each incoming midi channel. That requires the extra hardware, of course. I have been wanting to try and port Kria and Meadowphysics from the Norns in to VCV. I’ll see if these are options that work well. My one issue with VCV Rack has been an inability to properly get an External Midi clock from VCV to drive the Norns. But I’ve had an issue with external clock in to the Norns all along.
Ah, yeah I see what you’re asking. Might be worth waiting until Ansible is ported to VCV Rack, a project which is underway currently (iirc).