Monome modules in 1.0

Hi everyone! Rack 1.0-compatible builds of the monome plugin package for macOS, Windows, and Linux are available here:
https://github.com/Dewb/monome-rack/releases/tag/latest

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.)
14 Likes

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:

  1. Do nothing – require that Rack be set to 1 thread to use the virtual grids.
  2. 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.
  3. 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.
  4. 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?

Congrats on the release!

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)
1 Like

Wow, it will be so cool to have Monome modules inside of VCV Rack. Each day I am amazed by new things in the Rack.

1 Like

Thanks for the detailed response @gc3! I’m going to hold off on sharing my thoughts until I get a bit more feedback.

The builds on GitHub have been updated to the latest version of the Rack SDK.

1 Like

Got to use the module from github, got to say i absolutely loved what i created with it.Good work!

1 Like

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.

Folks who are having problems with grid display: What operating system / video card / driver version are you using?

Windows 10, RX 470, and probably one of the latest official drivers.