Monome modules beta dev log

Announcements
1

Hi everyone, here’s a thread for updates about the non-library, prerelease package of hardware recreations of the monome eurorack modules, including teletype and ansiblediscontinued original trilogy of white whale, meadowphysics, and earthsea.

2.0.2-beta release notes, 2023-02-05

image

Rack SDK v2.0.3
earthsea v1.9.4 4b88b2e
meadowphysics v2.1 39a2139
teletype v4.0.0 efd6503
white whale v1.5 6dfef61

Installation instructions

First, delete any previous versions (folders or .zip/.vcvplugin files) of the plugin from the plugins folder within your Rack2 user folder. Then download the .vcvplugin file for your platform from the links below. Place the file in your Rack2/plugins folder, and restart Rack.

The exact user folder location depends on your OS version and cloud-documents integrations, here are some suggestions to find it reliably:

  • MacOS: Finder, Go menu, click Documents > Rack2/plugins
  • Windows: Right-click Explorer on taskbar, click Documents > Rack2/plugins
  • Linux: ~/.Rack2/plugins

Additional info is available in the Rack documentation on installing non-library plugins.

NOTE: For maximum safety, you may also want to export Teletype scenes from your favorite patches before upgrading.

Changelog from v2.0.1-beta to v2.0.2-beta:

  • Ansible trigger inputs now use Schmitt triggers like the White Whale and Meadowphysics inputs.
  • Teletype’s preview image in the module library now has some code on it.
  • The Clock knob on Meadowphysics and White Whale is improved:
    • Meadowphysics shows the current clock divisor/multiplier on the Clock knob when an external clock is patched.
    • Entering a value by right-clicking the Clock knob now works correctly in both external and internal clock modes.
  • Virtual grids have new “held keys” behavior. There are now two types of holding:
    • Ctrl-click (Cmd-click on Mac): Hold down multiple keys for as long as the Ctrl (or Cmd) key is held; when it’s released, all held keys will be released.
      • This is useful for interactions like selecting a range by holding down two keys; hold Ctrl, click the start of the range, click the end of the range, release Ctrl.
      • This hold state is shown with a depressed key, just like a regular single click.
    • Ctrl-shift-click (Cmd-click on Mac): “Lock” a key down until you click it again to release it.
      • This is useful for entering “modes” or “pages” like Meadowphysics configuration mode, or Kria mod pages.
      • Hitting the Esc key, or Release Locked Keys from the right-click menu, will release all locked keys.
      • This lock state is shown with a dot on the key.
  • Fix an issue that could in rare cases cause a crash when adding a grid-enabled module to a patch.
  • Some technical debt has been tidied up in the audio process and the build system.

Previous releases:

2.0.1-beta release notes, January 2023

Changelog from v2.0.0-alpha5 to v2.0.1-beta:

  • Add the ansible module
    • Contains the beloved sequencer kria (with a hardware or virtual grid connected)
    • Also includes versions of earthsea and meadowphysics, with slightly different capabilities from the standalone modules (with a hardware or virtual grid connected)
    • …plus CV generators levels and cycles (with a hardware arc controller connected)
    • ansible is a deep module and relies on press-and-hold gestures both with grids and its own panel buttons. Ctrl-click on grid buttons or KEY1/KEY2 to “hold” them.
    • virtual grids may need more love in order to effectively use kria; feedback welcome!
    • Not currently supported: the MIDI and “teletype expander” modes from the hardware
  • Support for hardware monome arc controllers (arc2 and arc4, theoretically, but only arc4 has been tested)
    • Currently only the ansible module utilizes the arc
  • Complete panel graphics for teletype and ansible, revise trilogy graphics
  • Module manuals added to Info submenu / plugin.json
  • Display the serialosc version in the right-click menu, and offer a link to the install docs if serialosc is not detected
  • Fixes
    • Add Schmitt triggers to the teletype trigger inputs and meadowphysics/white whale clock inputs (2.2V on, 0.8V off, matching the hardware)
    • Correct behavior for meadowphysics external clock input
    • Display the correct clock period on meadowphysics and white whale clock knob tooltips
    • Display the correct internal values on the teletype PARAM knob tooltip, and accept text input of 14-bit PARAM values when right-clicking the knob
    • Fix the “Release Held Keys” command on virtual grids, which was broken in alpha5
    • Fix SPDX license string in plugin.json (thanks @falkTX)
  • Build using the official Rack toolchain (thanks @cschol)
  • Add Mac ARM64 as a prototype target for M1/M2 computers, for testing use only with the VCV Rack Mac ARM beta build.
1.0.0-alpha5 release notes, December 2021

Changelog from v1.0.0-alpha4 to v2.0.0-alpha5:

  • VCV Rack 2 Free support
    • Graphics refresh to match Rack 2 aesthetic
    • More informative jack and knob tooltips
    • Streamlined right-click menus
    • Provisional support for VCV Rack 2 Pro VST
      • still testing different DAW/OS combinations; please share your observations
  • New option to decrease I/O sampling rate for reduced CPU use
    • Modules primarily interact with control-rate signals, so processing I/O every step is unnecessary
    • Slight downsampling is enabled by default
    • I/O rate can be decreased even further, or increased back to audio-rate, from right-click menu
    • Timers and events always use wall-clock time and are not affected by downsampling
  • Teletype improvements
    • Screen drawing uses less CPU
    • Screen should not glitch when the Rack engine is stopped (e.g., when no audio output device is selected)
    • Built-in scenes available as factory presets in right-click Presets menu
    • Importing to the active scene changes
      • New behavior for Active Scene > Import from file and Active Scene > Paste and init new scene from clipboard: active scene will be cleared, new script loaded, and I init script will run, just as if the scene had been loaded from flash memory.
      • Additional option Active Scene > Paste and merge clipboard into current scene keeps the alpha2/3/4 behavior; you can paste a scene fragment or pattern block into your current scene without changing the rest of the scene. The init script will not be run automatically, even if the clipboard includes it.
  • Virtual grid improvements
    • Keys are now mappable with VCV MIDI Map
      • Note: VCV MIDI Map is unidirectional, with no LED feedback, so this is more useful for meta/alt keys than whole-grid MIDI mapping
    • Better handling of dragging across grid keys; previous key is released before next key is pressed
    • Keys held with Ctrl/Cmd-click are now drawn “pressed” rather than with a highlight ring
    • Grids have a more interesting preview image in the module library
1.0.0-alpha4 release notes, 2021-11-30

Rack SDK v1.1.6
earthsea v1.9.4 4b88b2e
meadowphysics v2.1 39a2139
teletype v4.0.0 efd6503
white whale v1.5 6dfef61

Changelog from v1.0.0-alpha3 to v1.0.0-alpha4:

  • fix crash in earthsea when using the “double speed” rune too many times
1.0.0-alpha3 release notes, 2021-11-01

Rack SDK v1.1.6
earthsea v1.9.4 6d12465
meadowphysics v2.1 39a2139
teletype v4.0.0 efd6503
white whale v1.5 6dfef61

Changelog from v1.0.0-alpha2 to v1.0.0-alpha3:

  • Fine tune “digital-analog” conversion on module inputs and outputs to more precisely match hardware behavior:
    • Centralize conversion math for all modules into one place.
    • Set teletype calibration data to get exactly 0-16383 out of 0-10V signals on IN, and the max range of PARAM.
    • Change trigger inputs to fire on rising edge crossing ~2.2V (rather than on any 0V to >0V transition.)
    • Add a small voltage offset to outputs to improve average V/Oct accuracy of 12-bit DAC conversion.
  • Disable the Teletype screensaver.
1.0.0-alpha2 release notes, 2021-10-02

Rack SDK v1.1.6
earthsea v1.9.4 6d12465
meadowphysics v2.1 39a2139
teletype v4.0.0 efd6503
white whale v1.5 6dfef61

Changelog from v1.0.0-alpha1 to v1.0.0-alpha2:

Highlights include teletype scene import/export, improved grid communication, 256 support including a virtual 256, and lots of bug fixes.

teletype

  • Import and export scenes from the right-click menu. Individual scenes can be read from/written to text files, or the entire set of scenes can be synchronized to a USB stick for exchange with hardware.
  • Copy active scene to the clipboard / paste active scene from the clipboard (a @scanner-darkly suggestion)
  • Re-focus the screen after using a right-click keyboard shortcut
  • Fix: restore M timing immediately when loading a patch
  • Implement DEVICE.FLIP (#66)

grids

  • Rewritten grid-module serial communication layer
    • Adds support for 256 hardware (#28)
    • Restores support for Series and 40h grid hardware (#44)
      • note: not all module firmwares support 64/256, see #61
    • Fixes stuck notes in earthsea (#59)
    • Fixes flickering on 40h grids (#36)
    • Provides additional thread safety (#42)
  • Fix: eliminate a potential crash when unplugging a hardware grid from USB
  • Fix: update the VCV Rack patch correctly when manually reassigning a grid to a new module
  • Fix: always clear grid when disconnecting, regardless of method
  • Virtual grid improvements
    • Virtual 256 added (#28)
    • Selectable LED color and protocol in right-click menu, for older device emulation (#44)
    • Revamped aesthetics
    • Deadzones between keys removed, entire surface is clickable
    • Improved dragging behavior

general

  • Use double-precision floats for internal clock phase in all modules
  • Display module firmware version & git commit hash in right-click menu
  • Fix: preset glyphs are saved correctly in trilogy modules (#6)
1.0.0-alpha1 release notes, 2021-09-19
  • Rack version: 1.1.6
  • Teletype 4.0.0 (plus upstream post 4.0.0 fixes up to b93538)
  • Latest trilogy modules (July 2021)

Changelog from pre-alpha to alpha1:

  • Teletype PARAM and IN ranges were off by 4 (#53)
  • Keyboard shortcuts on Teletype right-click menu
  • Minor updates to Teletype graphics
  • The Initialize command now resets the firmware state
  • Other firmware loading infrastructure changes & prep for future features
  • New CI configuration for versioned releases
    • Windows and macOS are built native rather than cross-compiled
    • Using newer compilers on all three platforms (see GitHub docs for versions)
    • Linux builds have moved from Ubuntu 16.04 to 20.04; may drop support for older distros
1.0.0-prealpha release notes, 2021-09-05

Updated 9/5/2021. The Teletype module is now in the main branch.

Rack version: 1.1.6
Teletype 4.0.0 (plus upstream post 4.0.0 fixes up to b93538)
Latest trilogy modules (July 2021)
1.0.0-pre-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
2

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?

3

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
4

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
5

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
6

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

1 Like
7

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

8

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.

9

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

10

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

11

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!

1 Like
12

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.

Incidentals: VCV Rack 1.x (development build), GCC 7.5.0, Ubuntu 18.04, latest pull from tt2020

13

A question: Is this the place to ask questions about basic operations and functions ? I’m wondering how to save and load scripts. Any advice ?

14

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.

15

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 ?

16

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.

17

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.

1 Like
18

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.

19

Working with patterns now, the tracker is a very cool feature. All working well so far.

20

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?