Hi everyone, here’s a thread for updates about the plugin containing recreations of the original line of monome eurorack modules, including the in-production teletype and ansible, the discontinued original trilogy of white whale, meadowphysics, and earthsea, and virtual grid controller modules to allow use of the sequencing features without a hardware grid controller.
As of 6-25-2023, this plugin is in the VCV Library so you can install it using the usual methods.
Full version history and release notes is available on the GitHub Releases page.
These modules are complex and multi-modal, so definitely at least skim the VCV-specific documentation site which links into the deep documentation and tutorials for the hardware modules.
Re: the single-thread limit for virtual grids, I asked this question over at lines, and I’d be interested in hearing thoughts here also:
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 also 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?
Off the cuff (and having used these in V0.6, but not extensively–they are amazing, by the way!), in preference order:
#3: This seems like an excellent solution. It’s well thought out, should be reasonably easy to do, has a nice upside in terms of cool new connection options (of the sort you mention), and Rack users are used to wiring stuff so that’s not a serious downside IMO. Most importantly, it will keep working indefinitely (since it’s official): see #2. I suspect that other developers are going to start using poly cables as ad hoc data cables so you may be in good company. (Someone should write up reusable code for that!)
#4: Better than nothing, but #3 seems like an improvement on almost every point. It’s probably about as much work to implement as #3, and not allowing physical separation between modules would be annoying enough to more than offset the ease of connection. (When the expander module is literally just more of the original module, the metaphor works, but that’s not the case here). The switching could get really confusing with multiple modules.
#2: I suspect this could actually be quite a lot more work than #3 or #4, and it’s just to maintain the status quo (nothing new and fun like #3). I also worry that, depending on the solution, future changes to VCV’s threading model might break it.
#1: I think this will prove to be unworkable. My suspicion is that practically everyone is going to have multithreading turned on (esp. as the ecosystem adjusts to more resources and more CPU-expensive modules start getting written). Also, this would mean that patches involving monome-rack couldn’t be shared without big warnings/caveats, since threading settings live with the settings, not the patch, and monome-containing patches will reliably crash many (even most?) people’s V1.
Here are two additional ideas:
Could #4 be the normal of a #3 connection? Essentially, if a module is placed next to serialosc or grid and neither has any “data” connections, link it up. This might necessitate a L/R switch (could also be a right-click option?) to disambiguate. For dev, I’d suggest doing #3 first and then linking that solution to the Expander API.
Where do the connections go on the virtual grid? I worry about the fiddling necessary to keep the virtual grid free both of other cables AND its own cables. (Either one is doable, but both at once might be hard). My suggestion (which would be weird, but this isn’t the most traditional VCV module anyway) is that they go way in one corner, actually over the rack screws, and that there’s some way (probably right-clicking) to physically relocate them to one of the other corners. I haven’t actually tried the relocation thing but it should be doable with removeChild). If there’s a problem with that, or it’s too confusing, having four connector pairs, a stated order of preference (e.g. the first one clockwise from UL), and a tiny light to indicate which one is active could work. I’d prefer that to the orthodox solution (eight modules: grid 128 UL, grid 128 UR, &c)
Modules all work well except for the grids
with or without thread changes
the grids appear black and are non-responsive to mouse clicks
only tested on VCV rack 1.0
Hello, virtual grid are non-responsive for me, too. If the parameter tooltips are enabled, I can see the number of a pad and it’s state changing from 0 to 1, but only as long as I hold the click.
Linnstrument 128 has exactly the same layout as the bigger virtual grid, so it would be potentially interesting to use them together.
pretty awesome port (vcv rack seems to cover everything), big thank you and im enjoying your hard work, so many thank you. I’d love to able top donate some $$ to this project. Please tell me where i can do this.
Maybe I’m missing something: but can you use the pc computer keyboard to enter notes on grids?
I’d love to see someone come up with some norns ports for vcv rack!
I’ve been testing the latest code from the tt2020 branch, with particular regard for development progress of the Teletype module. Not much to report at this time, I’m going through various tutorials on YT and elsewhere. The scripting language is easy enough to handle at the basic level, now I’m getting into longer scripts, looking at the Tracker and the module’s other (for me) advanced features. Gotta say, it’s very cool, there’s a lot of potential built into that thing.
To save a scene (the collection of ten scripts plus the tracker, etc.), hit alt-escape, give your scene a name and description, then hit alt+enter.
Scenes are stored in the module NVRAM which is saved to the patch as a big buffer. You may run into patch size limits, especially if you have more than one Teletype in a patch. Also, future firmware upgrades during the prerelease period might invalidate your stored scenes as the nvram layout changes. I’d suggest that you jot down elsewhere any scripts you’re particularly attached to.
In the not too distant future i hope to add a right-click menu option to export scenes to a file, and eventually store scenes in the Rack 2.0 extended patch data compressed folders in JSON format so they can be opened in later versions of the firmware.
Alt-esc changes the window focus from Rack to its parent window (I launch VCV Rack from an X terminal). I can use the button next to the virtual USB port or simply press Esc (no alt) to open the scene display but got no joy after that with either save or load. I can’t enter any text, and loading any specific scene number loads an empty scene. My desktop is whatever Ubuntu Studio is using with Ubuntu 18.04 (GNOME ?), which may be a problem. I’m sure I’m missing something, any further troubleshooting suggestions ?
A little more information: The behavior I described is on my laptop. On that machine the NVRAM is always initialized at startup, the previous session’s scenes are blanked. However, on my desktop box the NVRAM is saved between sessions. Both systems are running Ubuntu 18.04, but the laptop needs updated.
Keystrokes only go to Teletype if you focus the screen by clicking it. The screen will have a yellow border when focused. If your operating system is overriding certain keystrokes and preventing them from going to Rack, you’ll probably need to disable those global keystrokes.
And that did the trick ! I disabled the default setting, alt-esc now works as advertised. The Scene Write display opened, I added a title and description, and tested save & load. It’s all working now. Thank you !
Btw, alt-Enter worked without change, it was not previously defined by the desktop.
i enjoyed trying out the teletype module but even after trying to disable the alt+esc shortcut in windows via autohotkey, i was unable to bring up the save scene dialog. would it be possible to provide a right click menu option to rebind the alt key to z or something for ease of use?
