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)