Potentially unsatisfying manual answer: you can press any step in row 2 of the grid to move the play pointer to that step. So if both White Whales are externally clocked with the same source and you have your clock stopped, you can push column 1 row 2 on both grids, and then the sequences will start in sync when you restart the clock.
Hardware answer: on the physical modules, you can send a sync event over i2c from teletype. This feature isn’t available in VCV right now, but I have long term plans to expose the i2c-only features in expanders.
That is actually a great solution. Thank you.
To me, White Whale, connected to a hardware grid, is wonderful. It’s just a pity it’s a bit hard to sync it, to another White Whale, or to sequencers in Rack. But I think this might be a great way to make it work.
So I’ve got a hardware grid, and I thought it would be nice to use two White Whales, and switch between them. that works excellently.
But then I thought it would be nice to use Stoermelder 8face to create presets, so I can switch easily. But it turns out the connection to the controller is not remembered.
Would it be hard to change that?
I don’t think there’s a strong case for storing grid connection information in presets; that’s a very patch-specific and dynamic setting.
But I agree it would be helpful to be able to swap a grid between modules using a hardware controller. Hoping to have something for that in the next update.
Just getting into VCV because I’m about to go travelling and have to leave my modular behind. Was planning on bringing my grid and 16n and the discovery of these wonderful monome ports has made me very happy! Brilliant work!
I have been wondering how to integrate my 16n though. Normally I use the FB ops in teletype but of course those won’t work without i2c emulation. Instead, would it be possible to add the midi side of teletype? There are midi ops which are designed to read midi over the usb input in the hardware. Any chance of those being implemented? Or alternatively, some direct implementation of the FB ops bridging over to the 16n as a midi input?
Awesome! I’ve got a 16n as well and it’s a great Rack companion. Support for the FB and USB MIDI ops are in the long-term plan, but not until the plugin is out of beta. In the meantime, you can midi-map the PARAM knob and midi-map a constant voltage module into IN, so you can get two faders directly into Teletype, and then use the other faders elsewhere in your patch.
Did you run make dep? I don’t know what changes you’ve made to attempt lin-arm64, so it’s hard to offer advice, but make sure you leave the ragel build steps not-cross-compiled, as it needs to run on the host, not the target.
Yes! Using the (serial) grid as a MIDI controller is something there are general tools for, you don’t need the plug-in for that. I’m not super familiar with all the current options, but one possibility is this older tool:
That may need some tweaks to work with the latest Max runtime or serialosc, but we could likely sort you out here or on lines if you run into trouble, or can’t find another tool.
Some pretty substantial updates recently: the Ansible module has been added to the plug-in, virtual grid hold behaviors have been reworked, and lots of small graphics and UX updates. Full change log on GitHub: Releases · Dewb/monome-rack · GitHub
Hi there,
it’s amazing to see the Teletype in VCVRack many thanks for the good job!
I know it’s not the case on the HW Teletype but do you have any plan to make an Azerty version?
Cheers
Great question! It’s come up a few times before, and there was a release with provisional partial international keyboard support a while back, but it ended up not being very satisfying for the users that tested it. The best solution would be to offer some kind of key map configuration file, but unfortunately Teletype works internally on raw HID key codes, so a custom map would not be able to change Teletype’s internal (US-layout based) notion of which shift keys produce which characters, so things would still not make sense.
Ultimately, I think adding international support will only be possible if it’s added to the hardware module, or at the very least the core firmware is rewritten to separate key identification from the rest of the app logic. This isn’t out of the question—I had to do something similar to separate the scene saving logic from the USB and flash memory code in order to make scene/load saving accessible to VCV. But it’s not near the top of the priority list.
Support for the 16n Faderbank via i2c
The 16n Faderbank is an open-source sixteen fader controller with support for USB MIDI, standard MIDI, and i2c communication with the Teletype. It operates just like an IN or PARAM (or the TXi for that matter) in that you read values from the device. You use the operator FADER (or the alias FB) and the number of the slider you wish to poll (1-16).
I think it would not be that easy to add support in VCV for I2C devices - but midi is allready there. Perhaps you will give us “FADER” commands, that get values from a MIDI attached 16n fader bank?
(or a virtual 16n faderbank, that we can MIDI map using the VCV module).
Right now I’m focused on getting the current scope of modules and features bulletproof for a library release. Any new scope like 16n/i2c support is on hold for now.
I also use AtoV 16n hardware and I consider it pretty critical to my use of hardware Teletype, so I agree that it’s important, but there’s already so much scope in this plug-in.
Regarding using MIDI for I/O, hardware Teletype and Ansible do have USB MIDI input and output features, and I do expect VCV Teletype (and possibly Ansible) to eventually get MIDI features that closely track the hardware implementation. (So I’m not going to add new bespoke MIDI behaviors.)
