Oh that’s wonderful! Will try and report back.
Hello all!
I’m having an issue with the latest Ansible where all lights in trigger view would suddenly disappear except for the first step and eventually stop sending cv. It’s happened over and over and I can’t figure out what triggers it. I can plug along happily for a long time and then it flips out.
I recently rolled back to 2.1.5 and this has stopped, but I had a random problem where patterns weren’t working properly. For example I had a pattern on P1, then I’d move to P2-P3 and create variations. When I switched back to P1 it would play as expected, but upon switching to P2 or P3 it would continue playing P1. Sometimes it would just play a blank pattern. Anyone experience this? Am I doing something wrong?
Had a thought last night, no idea if it is possible, but I would love a way to send pitch and gate sequences from VCV to Just Friends and W/ via Crow’s I2C.
The module could connect to a Crow that’s connected to the same PC via USB, similar to how Midi-Map connects to USB-midi devices. I guess it would translate CV signals received to I2C messages for the modules. I know Crow and the I2C bits like LUA and VCV modules are C, so maybe this wouldn’t work?
I know just enough about dev to be dangerous and somewhat inefficient, but if this was a beginner level project and someone could point me in a direction to get started I could take a lil stab at it.
The easiest way to do this today, if you have Max, is to set up a Max patch that receives MIDI or OSC from Rack and forwards messages onto Crow. The i2c example in the Max-Crow documentation demonstrates controlling Just Friends (and the same patterns should adapt to W/ synth mode.)
Sorry you’re running into an issue, do you have a patch you can share that exhibits this problem?
Version 2.2.8 is now available through the library. There have been two updates to the monome plugin since the last release announcement in this thread; here are the release notes for both:
Changes from v2.2.3 to v2.2.7
- Teletype
- Firmware 5.0 for the hardware Teletype is out of beta! See the lines thread for details and credits.
- Teletype 5.0 is now the default for newly placed modules in Rack. Any instances in your existing patches will remain on 4.0.
- You can change firmware versions from the right-click menu under Firmware Tools > Switch Firmware. This will reset the module memory, so export any scenes you want to save before switching firmware.
- New features include
DR
drum ops,CV.GET
andSCALE0
ops,$F
$L
$S
and related ops to call individual lines of scripts, and support for multiple faderbanks. 5.0 also includes lots of bugfixes and documentation improvements, including improvingTR.P
timing and correctingN.CS
scales. See the teletype 5.0 firmware release notes for the full changelog.
- Ansible
- Allow the Ansible CV outs to reach zero when used as gates, so they can trigger modules that do not use a Schmitt trigger input with a threshold above zero. (#187)
Changes from v2.2.7 to v2.2.8
- Hardware grids and serialosc
- monome-rack will no longer claim grids from serialosc at startup, and will instead wait until a module is assigned to connect to each grid. This makes it easier to use one or more hardware grids simultaneously across VCV Rack and other grid-hosting environments like Max or seamstress.
- monome-rack will no longer listen for OSC messages on all network interfaces, avoiding firewall warnings that previously appeared in some situations.
- Teletype
- The version number displayed on the screen at boot has been correct in builds posted on GitHub, but incorrect in builds downloaded from the Rack library – in the library version of the plugin, both Teletype 4.0 and 5.0 firmware displayed “4.0” on the startup screen (in both cases, with the correct commit hash.) This should now be fixed in library releases.
- Ansible
- The firmware version is now correctly reported in the right click menu > Firmware Tools submenu.
- Documentation
- The Development guide now includes a walkthrough of using monome-rack as a development environment for testing changes to the device firmware, and running those changes on hardware.
I’m using the “feat/14bit-fb” branch with your 14-bit 16n faderbank firmware. Will 14-bit support happen to the main library branch too ?
thnks
Good question! The plan is to work with the 16n folks on making 14-bit support official before landing it in the plug-in. No promises on timing as it’s not solely in my hands, but it is at the top of the stack.