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?

2 Likes

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.

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.

1 Like

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.

That is correct. My comment above refers specifically to the int16_t value argument and ignoring the command and port arguments.

It only receives s16. There is no sending implemented.

All of the values from SC.CV commands are converted to the ER-301’s internal representation for audio/CV which is 32-bit floats, and such that 1V becomes 0.1. In other words: (s16 from Teletype)/16384.

1 Like

thank you! this is incredibly helpful. i wasn’t sure about the get status of all the SC ops. crow by default is ready to get all the things it sets, but if it’s just a one-way set from crow to er301, and the er301 never sends back, this simplifies the support code. i’ll get a revised patch back to the upstream github issue asap. thanks again!

No problem at all :wink:

Oh and by the way, if @bpcmusic’s TELEXo is already supported by crow then you should be able to just follow exactly what is being done for the TELEXo. When I implemented Teletype support for the ER-301, I basically just had the ER-301 emulate a subset of the Teletype’s TELEXo-specific commands.

1 Like

TXo is not supported by crow yet, but there is a stub placeholder for TXi support. TXo is probably just as straightforward, but i’m not sure if anyone’s working on it. in the meantime, crow can bridge TXo and TT, then send those values to er301 in its expected format. :slight_smile:

my reference implementation for recreating the er301 ops for crow, besides the TT integration wiki, was actually Just Friends/Just Type: jf.lua.


next day edit: 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.


oct 1 edit: it’s just about in! @tehn pulled in my patch, so after a bit more review, crow will support the er301. (view) :bird:

11 Likes

Sweet! Thanks for your efforts here. Very cool.

1 Like

My Crow showed up last night! I’ll be playing with it and my Norns a bit today, and if I get brave I may even try applying that pull request with ER-301 support and doing my own build of Crow.

5 Likes

Good luck ! Let us know the result :slight_smile:
Mine is still in Chicago, not even arrived in Paris CDG yet…
I guess I won’t be able to test before Tuesday or Wednesday…

Crow is amazing! I forgot just how much I hated dealing with my FH-2, or any midi interface, as an intermediary, I got into modular because I was sick of midi and notes and all the assumptions that come with it, so it’s very freeing to just type crow.output[1].volts = 1.25

But I underestimated how fussy and annoying i2c is! My gaffer taped bundle of female jumper cables that I’m trying to use to get my Crow talking to my Ansible (and then from there daisy chain on to the ER-301 once that support is added) isn’t working. And I definitely wish I could buy official i2c busboards and ribbon cables from people who are DIY savvy.

I can already see how helpful ER-301 support will be, 4 CV outputs go very fast, and I very much want to set up crazy dense polyphonic patches on the ER-301 that are controlled by the Norns.

2 Likes

Yes :slight_smile: At some point, discovering the polyphonic capabilities (with Crow and Norns) of the “Just Friends” module I thought I’d try to buy one but the 301 can surely host a polyphonic patch. And we could even make it MPE compatible !

Generally it’s quite straightforward, 3 cables. I’ve even had good results with long (60cm) cables, each setup is different but generally the shortest is the best. I’m surprised it doesn’t work. I’m using cheap DuPont cables bought on Amazon, and the bus is fine. Could it be a Pull Up resistors issue if there are more than 2 devices on the bus ? I don’t know if there are any Pull Up resistors on Ansible. You might need to activate them on Crow, I’m not sure. There’s this thread on Lines if you need help https://llllllll.co/t/whos-on-your-bus-aka-lets-find-i2c-buddies/25871/8

Apparently the Er-301 patch for Crow is not working yet but I’m sure it’ll be fixed very soon. :wink: In the meantime you can try to connect Crow to Ansible directly, bypassing the 301, and see if there’s any improvement.

Edit

From lines:)

Well, I got Crow and Ansible working via some Dupont cables!

It turns out my “hardware” problem was a software one - Ansible channels are numbered starting at 0 even though Lua typically starts numbering things at 1, so it was your classic “off by one” error.

I did notice it stopped working when I daisy-chained to the ER-301 (in preparation for future support), so it seems like a device may need to be supported in software before it can be connected?

Probably, I haven’t connected the ER-301 and Txo yet because I suspected that would cause some issues.

By the way, @ioflow is there anything we can test ? I’m available if some testers are required :wink:

Do you mean that Ansible stopped working when you connected the ER-301? I’m not sure that should have happened. I was able to query TXi’s input knob with ER-301 connected.

(Note TXi is not finished/fully working either yet, as far as I know; this was via a script that Galapagoose provided to me).