#120

This is great.

Mine was from the first batch too.
The necessary modification is pretty easy and took two minutes. The other component is that the pin out is in the wrong order so you need to connect each header independently or get one of those custom cables that @bpcmusic sells.

2 Likes
#121

it would be incredibly easy to write a script that takes a keyboard input to norns and displays messages back from crow, like TT.

font size might be an issue— but there are some smaller ones on norns available.

7 Likes
#122

thanks, the premade cable sounds great! didn’t know it existed. but i’d need to find someone who has the soldering tools and ability to do the cpu board mod. degenerative nerve disease; i don’t have the dexterity or physical ability to hold the thing steady, much as i’d like to try. a local friend graciously soldered on the i2c connectors for my earthsea module a few years ago, so i might reach out again.

i plan to have a revised patch up today. maybe er301 support can be added before crow ships, or for the first firmware update afterward. :bird:

1 Like
#123

Another question, for a thread full of questions: is it possible to experiment with microtonal scales with crow? a microtonal scale is just a arbitrary range of voltages right?

4 Likes
#124

for sure! there is a built-in n2v helper, which takes a MIDI note value and spits out a v/8-tuned voltage, but everything else is just a matter of doing the maths or including a lookup table in your script :slight_smile:

2 Likes
#125

Yes indeed! The rear connectors are laid out identically with this in mind.

Unfortunately this is a DIY-only for now. The reality is, ‘available for purchase’ means I DIY one and send it to you :confused:. I am 100% happy for someone else to provide these to the community (with whatever markup you feel appropriate).

You can reliably stream every 5ms to a remote host on both channels simultaneously, down to ~2ms if there’s not much else going on.

This is something that requires some design work for the i2c framework. I’d love to see proposals for what that sc.lua file should look like to support the other addresses in crow. Also, how you’d like the function calls to work in the crow: ii.sc[1].cv(2,3) or ii.sc.cv(1,2,3) or `ii.sc1.cv(2,3)? How many people have multiple er301s anyway?

(sidenote: for those asking, this is the same question re: multiple jf modules. it makes the interface more complicated even for those with only 1 unit)

Small note - we specifically decided to avoid too many abbreviations in crow as the primary coding environment is a desktop computer screen where character limit is not a limitation. I’m unsure why er301 is shortened to sc, but could it not be confused with supercollider (especially in the norns context)?

This functionality is forthcoming, though we have yet to finish designing just how it should work.

These are some of the scripts that will be provided with druid as an introduction!

Very clean & precise. It’s a DAC (not an audio codec), so there’s no anti-aliasing filters which typically cause these problems. All the outputs can switch their functionality on the fly.

Absolutely. Crow talks ‘volts’ but with decimals, so you can easily make custom scales:

twelvetone = {0,1,2,3,4,5,6,7,8,9,10,11}
output[1].volts = twelvetone[note]/12

microtonal = {0, 0.1, 0.121, 0.999}
output[1].volts = microtonal[note]

justint = {1/1, 4/3, 3/2, 15/8}
output[1].volts = justint[note] - 1.0
26 Likes
Telex: Teletype expanders
#126

Thank you for exploring this line of questioning. For the ER-301, the existing implementation on Teletype provides a good model:

JF I2C comms are much more complex, and I share your concern about making things harder for the more-common single JF use case. However I don’t see a reason why the existing JF OPs should change; and then what’s wrong with having matching JF2 OPs? There are, after all, two incredible modal behaviors available within JF.

I think the issue will eventually become moot for me as I create another (my third) I2C bus within my euro ecosystem for crow.

1 Like
#127

It’s short for Sound Computer, and I suspect it was to avoid the collision of ER and err/error… but I have to say, part of me died inside when I first took note of it.

Naming, amirite?

1 Like
#128

I think it was to avoid a collision with euclidean rhythm OPs.

#129

It’s a suggestion made in order to save a few bytes and avoid writing ii.er301.trigger() in the scripts, shortened to ii.sc.trigger() :slight_smile:

#130

It would be nice if we could use crow as a switch to pass grid, arc and keyboard coms from the Norns to any of the monome eurorack modules. Is that feasible?

1 Like
#131

So many questions, haha. First two that come to mind:

  1. 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)
  1. 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?
1 Like
#132

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.

3 Likes
#133

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 :stuck_out_tongue:
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.

1 Like
#134

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?

1 Like
#135

Very interested to see what people come up with re: w/+crow. I’d love to be able to smoothly control tape speed while in CAPTION mode.

#138

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

#141

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.

2 Likes
#150

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!

1 Like
#151

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?

2 Likes