Monome Crow and ER-301

[Nordseele]

https://monome.org/docs/crow/

It’s finally here ! Just ordered one, barely looked at the specs (tbh I’ve been following the GitHub repo for months, but it’s such a good surprise it’s finally released today), I hope I can connect it to the ER-301 via I2C without hassle This opens up so many possibilities. LUA scripts (on Norns or standalone, even live coding) for sequencing and controlling the 301, connection with Max, MIDI?(*), Ableton Link etc

(((Now that I think about it, it might even be possible to control the 301 with an IPad . * Edit: Not every midi devices are directly recognized according to Tehn but through a Raspberry Pi running Norns, I guess this shouldn’t be a problem.)))

[Nordseele]

Hmmm there’s one small issue…
Crow doesn’t speak to the 301 yet…

According to Tehn on the lines forum:

“ ER-301 is not yet mapped out (neither trent or i have one)— but it’s incredibly simple to add new i2c modules— see https://github.com/monome/crow/blob/master/lua/ii/jf.lua as a reference.

if someone would like to make er301.lua and send in a PR we can release an update right away. i think the TT can be used as a reference implementation for the protocol.”

Edit: this might work https://github.com/nordseele/crow/blob/master/lua/ii/er301.lua

Here: crow

[Joe]

Thanks for the heads up. Just ordered one myself.

[chapelierfou]

This opens a lot of possibilities.
People like me love to code stuff on Max like sequencers or algorithmic stuff but I prefer to rely on hardware when it comes to sample players, granular delay, etc.

[Nordseele]

Yes, afaik the hardware solution we have now is the Teletype, it is fun but honestly I’m glad I’ll now be able to code a complete script using LUA without the 6 lines x 8 scripts limitation of the TT. Crow might be a game changer (as soon as it can speak to the 301, but Tehn wrote it’s “easy” to implement) I would try this by myself but I’d be more comfortable if Brian does it

And about Max, I was thinking about getting back to it today (and upgrade to 8) and how I’d use it along the 301…

[shellfritsch]

couldn’t crow be scripted to send the same i2c messages (SC.CV + SC.TR) that teletype sends? i don’t think any work needs to be done on the 301 side of things if the same commands and addresses are used.

[Nordseele]

Absolutely, there’s no firmware mod needed on the 301 side. But there’s a Lua script (er301.lua) that needs to be created on the Crow side. Apparently, the Monome and Whimsical creators do not own a 301 so if we want to bring communication between Crow and 301 we have to do it by ourselves following the example linked above and push the script to GitHub

[Nordseele]

Deprecated : in progress: I don’t have the possibility to test without the module of course. Ansible seems to share the same set of commands as the 301, so it’s basically a clone of the Ansible file with adjusted name and address 0x31

2/10/19 : Deprecated -> ER301 support has been added to Crow https://github.com/nordseele/crow/blob/master/lua/ii/sc.lua

Not sure about the “getters” though, I don’t think the er301 will respond to this, will it ?

If anybody wants to take a look at the I2C implementation doc, it is here https://github.com/monome/crow/blob/master/readme-development.md#i2c-adding-support-for-new-devices

Edit: renamed the file to sc.lua instead of er301.lua it will be easier :

“The lua_name field must match the filename (sc.lua -> ‘sc’), and is the name by which users will refer to this device in their scripts eg: ii.sc.trigger() .“

[Joe]

Go @Nordseele go!

[mimetaur]

Ordered my Crow and I’m excited to see some discussion (and progress from @Nordseele on the lua script!) here. I’ll be experimenting with using the two of them together over i2c as well in the coming days.

(It’ll be great to keep the CV outs on the front of the Crow freed up for non-ER-301 purposes too.)

[josker]

Could some kind soul share some use cases for the Crow with 301? I’ve read the available materials, but am not sure if I fully connect the dots w/ regard to making the most of what’s on offer.

[Nordseele]

I haven’t tested it but here’s how I see things according to what I’ve read. In the case of the 301, it will give the ability to control the sound computer in many different ways.

Here’s how I’m planning to use it:

I’ll use Norns as a hub, Norns (or a simple Raspberry Pi running Norns) will be connected to Crow via USB and Crow will be connected to the 301 via I2C.

One can connect anything to Norns, Midi keyboard, Linnstrument, Monome grid, midi faders, 16n faderbank or even Bluetooth devices like Roli blocks (Norns code needs to be modified a little bit for Midi over Bluetooth but that’s another topic), OSC devices and apps.

You can write a complex sequencer (Norns lua script) controlling the 301 for example, and on top of that, Norns can convert some external MIDI to Teletype protocol and transmit all that via I2C (I hope the connection is super strong) I imagine that most of the existing Norns sequencers will be updated for using Crow as a possible output. Anything Norns receives may be converted and sent to the 301 using a custom script, and LUA scripts are quite easy to write. So Crow is a communication tool. Grid + Norns scripts + midi controlling the 301, that’s my plan, I do hope it’ll work and be super reliable as I imagine it

Crow can also be used in standalone mode, without Norns, it can host some LUA scripts, you can even do some live coding and control Crow with a terminal (? Haven’t seen this yet , Its similar to Maiden but it’s called Druid) + The 2hp module has 2 inputs and four outputs for talking to the regular modules without I2C or to the 301 through it’s hardware cv inputs and I believe the amount of outputs can even be expanded with some Txo modules but a script needs to be created for that too, it should be easy according to the creators of Crow.

There are also some M4L devices and Max objects created for it. I believe it supports Ableton Link as well. This opens up even more possibilities…

I m sure we’ll see many demos and use cases in a week or two.

If you don’t own a Norns there are now 3 different diy Norns projects available including an official one which allows you to include this powerful device in your setup for about 100€. Again, Norns is totally optional with Crow, using Crow with Max for example might be really fun and super powerful as well !

[Nordseele]

Yeah I’ll do my best but I’m not sure the “types” are correct in the script, I don’t know which one is required for the 301. Will have to test when I receive the module. Tehn said that it would be easy to create a script for the 301, right now it seems too simple to be true. // @odevices if by any chance you have time to take a look at the Lua script on GitHub, that would be really cool , do you think the “types” of arguments are correct ? I only modified the address and names in the script as a starting point, I think the commands are already implemented in the 301 but I’m not sure. thanks a lot

29-09-19 edit : Someone else, IOflow on Lines, has done the work and has sent a pull request, so here are the actual file and notes

add i2c support for orthogonal devices ER-301

[josker]

Thanks so much for this - this clarified the matter up for me more than any ”official” documentation

[nocables]

Yeah it’s ready to roll already via II commands as mentioned…

This I think might be great for us as it’s fully open source and I think there are many monome/mannequins owners here (every module for me - sold the arc though)

The fact it’s scripts are uploadabe so be fully untethered from a computer and totally works into the er301 framework to enhance

This and the nerdseq dev. I’m in heaven as I never ever ever plan to move away from er301

[ioflow]

hey, all. checking in. i had no idea anyone else had been looking at integrating crow with er301 when i coded the initial support last night and sent in the pull request.

as @Nordseele mentioned, there are still some questions on certain value types/signed-ness, but what i wrote is an attempt at something coherent. it’s not always clear what the 301 internally expects to be sent, compared to the signed float values the user sees onscreen in a unit. also, i haven’t added support for multiple 301s; it’s not clear how to handle multiple identical devices within crow’s lua framework. for now, crow support is limited to the first 301, at address 0x31.

you can follow along with crow+301 i2c progress on github.

[odevices]

it’s not always clear what the 301 internally expects to be sent, compared to the signed float values the user sees onscreen in a unit.

The ER-301 understands Teletype messages which (at the time) were 2 or 4 bytes where the first byte determines the message type, the 2nd byte is the port number (1-100), and the 3rd and 4th (optional) bytes are interpreted first as a 16-bit signed integer and then scaled depending on the message type. Has this changed?

[ioflow]

i don’t think anything has changed. if it’s always a u8 number for port, and then the rest of the values are expressed as s16, that simplifies things greatly. the expected signed-ness and type (integer, float, etc) and length (e.g. u8 for simple 0-or-1 values) was mostly what i was looking for. here are the types that crow uses, taken from the crow development readme:

• void – the lack of an argument (typically not needed)
• u8 – unsigned 8-bit integer (0,255)
• s8 – signed 8-bit integer (-128,127)
• u16 – unsigned 16-bit integer (0,65535)
• s16 – signed 16-bit integer (-32768, 32767) {teletype’s default}
• s16V – voltage as signed 16-bit integer (-32768, 32767) {converts teletype to V}
• float – 32bit floating point number
  u16 s16 and s16V expect MSB before LSB. float is little-endian

this is some of the crow-301 .lua i wrote. the full file is here, and mixes a few different signs and types. docs strings are slightly modified from the wiki:

(lua code sample)

  , { name = 'tr_time'
    , cmd  = 4
    , get  = true
    , docs = 'Time for TR.PULSE *port* in *value* milliseconds'
    , args = { { 'port', u8 }
             , { 'value', u16 }
             }
    }
  , { name = 'tr_pol'
    , cmd  = 5
    , get  = true
    , docs = 'Polarity for TO.TR.PULSE *port* set to *value* (0/1)'
    , args = { { 'port', u8 }
             , { 'value', u8 }
             }
    }
  , { name = 'cv'
    , cmd  = 6
    , get  = true
    , docs = 'Set *port* CV to *value* (bipolar), following SLEW time'
    , args = { { 'port', u8 }
             , { 'value', s16 }
             }

i took a quick look at the SC ops in the teletype source last night, but at the time i couldn’t entirely glean what actually is sent/received, and how it translates into the onscreen values within 301. if some are float, if a unit’s voltage 0-10V (for example) is internally expressed by a 16bit number, signed or otherwise. but based on your comment, i’m starting to think TT source lines 51, 63, and 68 indicate the types that TT works with.

given all the above, i may be able to simplify er301.lua further, without needing so many different data types.

[odevices]

Actually all of the calls in er301.c go through SendIt which has call signature:

void SendIt(uint8_t address, uint8_t command, uint8_t port, int16_t value,
            bool set);

So all values are sent as s16 but then re-interpreted on the receiver based on the command type. I wasn’t even aware that the Teletype could send floats.

[ioflow]

i’m guessing uint is unsigned int, and plain int is signed? i’m not too familiar with C. but that last bit is something i wanted to bring up with @tehn – based on the crow docs, there doesn’t seem to be a specific way to set/get boolean values. the best that i could come up with was using u8, and hoping folks know to only use 0/1.

teletype uses 16bit integers internally that requires crow conversion to float:

s16V bridge

Note s16V is used to bridge from teletype native 16bit integers, and crow’s floating point voltage representation. If you typically use N or V teletype operators on that parameter, you want this!

…but i don’t think it comes into play here, since crow doesn’t have to talk to TT first, but instead is sending/getting directly to/from 301. if 301 also expects to just receive/send s16, then i don’t have to worry about whether crow should be sending float. i had only guessed it was necessary because some of the onscreen parameter values, e.g. filter freq, are expressed as float.