So many questions, haha. First two that come to mind:
I have an ER-301, a Just Friends, a 16n and soon a Crow (this feels like the intro to a “walks into a bar” joke). Is it possible to have them all connected on one i2c “network”? I would specifically have the following goals in mind:
Crow talks to ER-301 over i2c
Crow talks to JF over i2c
16n talks to ER-301 over i2c
Bonus: 16n talks to Crow over i2c (this feels unlikely)
The USB port on Crow is device and not a host. Therefore, if I want to send Crow MIDI info over USB I would need a USB host intermediary. Does the host have to be a computer? Or could I use one of the many MIDI USB device/host modules/hardware out there as long as it has a way to route MIDI between connected USB devices and I write an appropriate standalone script on Crow? Or, to put it a simpler way: can I send Crow MIDI without using a laptop?
Ansible 2.0.0 supports this via the ANS.G/ANS.A Teletype ops, and their corresponding I2C messages: you can use ANS.G.P x y to emulate a Grid key press, ANS.A.LED n x to read the LED state of ring n, LED x on an Arc, etc. You can also switch what app Ansible is running with ANS.APP. It would probably be straightforward to add support for these I2C commands to Trilogy modules. Teletype does not (currently) have any I2C follower implementation.
I am not personally very familiar with how 16n communication works, but my understanding is that different firmwares can be compiled for it to behave as a leader or a follower? In that case you may have trouble with simultaneous “Crow talks to XX” and “16n talks to XX” because each leader device expects to be the only leader on the I2C network. In practice this will sometimes work fine if only one leader is communicating at a given time, but the more traffic both are sending the higher likelihood that I2C transmission can start failing, or that one or more devices lock up. “16n talks to Crow over I2C” doesn’t seem unlikely to me at all, this is probably a straightforward device mapping that could be written for Crow with Crow switched to follower mode.
I don’t know how it works code-wise but wouldn’t it be possible to have ii.<device> be an “alias” for ii.<device>[1]? Might need a custom type/object to make that work, but seems to cover both usecases.
This kind of polymorphism does obviously make the interface a bit muddy.
The indexed version seems cleaner and clearer to me than the alternatives, although I guess ii.<device>1 and ii.<device>2 is pretty easy to understand. Maybe even in combination with ii.<device> that points to ii.<device>1?
I thought sc meant SuperCollider, so definitely seems confusing to me
I’d just use the device name, so er301 in this case. This might have some impact on the naming scheme above, because ii.er3011 and ii.er3012 are also confusing. ii.er301[1] is a lot clearer.
apologies if this has been asked and answered previously, but if i had an older version of teletype without a backpack, could crow reliably support an i2c network in my system (ansible, jf, w/, teletype) on its own?
Right now, no more than can be done with Teletype, since this isn’t adding additional commands to the I2C commands supported by w/. But I agree, that’s certainly one of the thing that would be nice, along with the ability to add cue points
i submitted the revised patch for er301 support. should be all fixed up: set all gets to false, as er301 never transmits data back. also, all data from crow is sent as signed 16bit integers, s16. view: er301.lua.
also, @Galapagoose made a good point regarding the device name within the op, to not be confused with supercollider stuff. so i left the device name as er301 as per my original patch, rather than change it to teletype’s character-limited sc. crow’s coding environment has more relaxed constraints, so the device/op names don’t need to be so compressed. if it would assist readability, i can expand the current tr_foo and cv_bar commands to their full names, e.g. trigger_toggle and cv_offset.
Are the limits to script size and memory limits in standalone mode stated anywhere?
I’d like to replicate a clocked voltage recorder (like Malekko Voltage Block) script that I had going with the Teletype and Faderbank. The teletype was tricky given its limited 4x64 pattern memory, so I only had a maximum 16 steps per track.
I’m sure with Crow and Lua I could exceed this memory limitation, and clock the input much faster for smoother resolution of recording per channel!
Related teletype/crow question as I continue wrapping my head around this:
I understand the instability that could result in having both crow and teletype controlling the same module (say, Just Friends), but I assume it’s generally fine to have both on the same i2c network doing their own independent things?
In other words, can I introduce crow to my larger i2c network by connecting it to my tt backpack?
Added a little info on this here under “faq”. The problem is that only one device can be transmitting on the bus at a time, so having multiple leaders increases the odds of contention even if they’re talking to totally separate modules. The situation you describe might be fine, or it might cause some modules to lock up and need a power-cycle to work again – how best to deal with this kind of thing has yet to be figured out / implemented.
Lovely - that’s helpful. I suppose the crow / teletype relationship is hardest for me to grok. I’m tempted to get crow primarily for the m4l integration and devices (and for norns interaction), but the teletype is still a major part of my small skiff.
I am not the authority on 16n I2C despite what it might seem, but in a nutshell:
in follower mode, 16n can be queried over I2C by other devices (eg: Teletype). If Crow has support for 16n/“ability to support 16n because of how it works” in its ii library, it should Just Work.
if there is a sane way for crow to be follower and 16n to be leader, that requires an addition to the 16n firmware, which I’m happy to receive guidance/submissions on.
Given the way it’s described, though, it feels like it’d be a follower.
Multi-master is a bad look and basically shouldn’t even work.
I wonder if crow will be able to take advantage of Ableton’s recent CV Tools additions? I can picture some of those tools being recreated in m4l for interfacing with crow.
the CV Tools are all written for dc-coupled audio interfaces, so there’d need to be a bit of crow-specific code to translate the signals into data for crow.
they’ve been adapted, at least . I tried to take as much inspiration from existing tools to keep things appealing while also adhering to an opinion. please feel free to hit up the ^^ crow help: max and max for live thread if you have any requests or hit any speed bumps!
(staff notice: to keep this release thread on topic, which is for general crow questions, the lengthy side discussion on “how should crow be documented?” has been moved to crow & end-user documentation.)
Not exactly sure how to ask this, but will Crow will run the Teletype language or something like it? Using Druid, perhaps? How do they compare? I’m intrigued by the idea of live coding, and I believe that is something TT does, but it would be much easier to fit and afford a Crow or two than a TT… plus Crow runs M4L too, which I would like as well…
Crow is a pretty simple device. It really has two functions:
it is a USB device (not a host!) that can produce and receive eurorack CV signals. a USB <-> CV converter, with some extra tricks like LFOs. The M4L devices support this use case.
it is also an accessible standalone development environment for eurorack. The language is Lua, with a special framework specifically designed around CV processing. The processor is a lot more powerful than Teletype. It does not use the TT scripting language. The “druid” environment supports this use case.
The bindings to the norns scripting environment are kind of in between, allowing norns users / developers to treat it as a CV expansion module.
There’s no reason to worry about the second use case if only the first interests you. And vice versa.
If you want to do live coding for eurorack, in Lua, then this is for you. You need an external computer, to act as a code-editing interface
Crow does also embed a domain-specific language called ASL for easily describing sequences of voltage transitions within Lua scripts.
If one wanted to write an interpreter for a stack-based language (like TT-script) for doing something or other with CV, this seems quite achievable to me as a project entirely within Lua on Crow, and would probably be quite a neat encounter with several of the sacred digital mysteries. Perhaps a fun Crow study!
