OK thanks think i got it:
Teletype will directly be connected to the txo and txi by two 3 wire cables and then I would connect my just friends to one of the expanders (if I see well there is a 6 pins block remaining?)?

Please add one iibackpack to mine :wink: thanks !

1 Like

also note that teletype shipped with a bus cable with 3 connectors, to attach all the trilogy modules (no idea how well it would suit the expanders with the orientation of the headers though, e.g. ansible’s was upside down). after a certain number of modules the powered bus board is needed as we know now.

http://monome.org/docs/modular/iiheader/

sorry, i’m not shure if i need one or the other, i’ll be connecting the TxO, Txi, Ansible and a White Whale.
you can add the proper one to my order :wink:
thanks so much

1 Like

Mid-Week Update

Got caught up on some of the ancillary work: making the europower connectors. First had to cut up the cable:

Then had to attach the ends:

I now have lots of band-aids on my hands. :wink:

Was playing around today using two TXi as controls for a Teletype script acting as a simple 8-step sequencer. Couple of lines of script … endless fun.

TXo pulse divider driving the BuckModular Drumfuck. Outputs from the TXi driving the pitch of the Noise Engineering Cursus Iteratas. Random values on the TXo driving various sound shaping parameters on both modules.

Short jaunt to the midwest and then I’m jumping into TXo assembly in earnest. Been doing prep work. :slight_smile:

11 Likes

That sounds like a small, weird factory assembly line tune :slight_smile:
Wondering if getting assembled power cables at this volume wouldn’t be cheaper and saved you some time

1 Like

Priced them - saved 50-70% off of assembled. Plus, what would be the fun in that. :wink:

5 Likes

I think I need an iBusboard also if I have two of each expander?

1 Like

I’ll try that this weekend. I know that two expanders are no problem and that six require a bus board. Four is probably on the line. If it were me, I’d use one of the bus boards just in case - especially if I wanted to add anything else in the future (Ansible, White Whale, Just Friends, etc.).

1 Like

No sense in messing around with a potentially flaky setup. :slight_smile:

2 Likes

So I’ve had a literal shower thought with regards to speeding up reading from the TXi…

First a little background, when an op runs on the teletype it gets given access to 3 variables of type:

  • scene_state_t: where the scripts, patterns, variables, etc are stored
  • exec_state_t: at the moment only holds the status of if/elif/else, but will eventually be used for dealing with recursion
  • command_state_t: contains the value stack

command_state_t only lives for as long as it takes to run a single command (a.k.a line of script), whereas exec_state_t lives for a single script. (When a command is run from live mode, it will run as though it’s a script with one line.)

So we could use exec_state_t to cache values returned from a TXi, they’d only be cached for as long as the exec_state_t lasts (i.e. running a script).

Furthermore if we wanted to rewrite things a little, we could return all the IN and PARAM values from a TXi, i.e. 8 values, any time a single value is requested. We’d have to rewrite all the MAP, SCALE, etc ops to run on the teletype though. This only really works if the overhead to send an I2C message is such that requesting 8 values back isn’t that much slower that just getting 1 value.

It’s probably a bit much to deal with now, but maybe in a few months we could have a go doing it, or someone could point out the fatal flaw in my idea…

3 Likes

interesting thought. it’d have to be able to invalidate cache properly when using DEL though.

another option for this is to have a separate timer for reading values, so ops would always return cached values. but that might be a bit extreme…

based on my debugging i2c with a scope passing 8 bytes instead of 1 is significantly cheaper than doing separate 8 reads.

1 Like

Each DEL command runs in it’s own exec_state_t anyway.

Good to know. I think we’d want to quantify it before attempting any code (‘premature optimisation’ and all that!)

1 Like

ah good, DEL wouldn’t need a special consideration then.

thinking some more, for the idea of having a separate timer thread - this would make more sense if we switch to push instead of poll, so the timer thread would check if the state of a queried module changed, if it indicates it did then read the full state and store it in cache. another benefit of this would be the ability to have a way to trigger scripts directly from ansible. but all depends on performance, of course…

Really love the thinking here. I’d certainly be down to exploring all options. Perhaps when we all get some time (2.0 released; TX modules in the mail) we can spawn another thread and discuss read caching in general (to cover Ansible and others). I’ve mulled some of this stuff over in my mind as I was thinking about optimizing the implementation in the past, but would love to go deeper!

For those following along, I haven’t found any real performance impacts from doing a lot of reads yet - but I’ve only pushed it as far as reading from three modules (12-16 inputs).

2 Likes

@bpcmusic, Have you run any i2c tests with an Ansible connected as well? I’m still getting lockups on my Teletype with the new backpack, 2x TXo, 2x TXi, and one Ansible. Your backpack test above looks way more intense than anything I’ve been using so far, so the wildcard in the setup seems to be Ansible at the moment.

@trickyflemming - Sorry you are still having problems. :frowning:

The video above has an Ansible connected in the front of the Teletype on its side. I’m running 4 x TXo, 2 x TXi and 1 x Ansible. Ran for hours with no TT lockup.

I did notice, however, that the Ansible CV lights stopped updating after hammering it at some pretty high tempos. This has been observed from time to time. The TT is fine - it is an Ansible thing. I need to make sure I have the very latest firmware on there. I think I do.

Here is another angle where you can see the Ansible better:

This is after turning it on without doing evil tempo things. Ansible is mirroring the Teletype’s triggers and CV values.

What exactly is happening in your setup? How are things connected?

Big question: are you sure that your bus board is providing power? Have you checked it with a voltmeter?

Thanks for the really fast response. In the backpack thread, I posted the symptoms:

I’m using the backpack, and I know that power is at least reaching the Teletype from it. What other pins should I inspect with a voltmeter? What should be the expected readings?

EDIT: I should add the freezing occurs anywhere from 10 seconds to about 30 minutes after power-up. It seems quite random, unfortunately.

I’ll move the discussion to the ii bus board thread. Saw this post first. :wink:

Progress continues!

Chugging along with the build. Ran out of jacks halfway through doing the TXo front board and panel assembly, so I’ve kept going and have assembled the first half. The second half should start up today. I need to pick up the resupply from my office where it was delivered yesterday.

I wasn’t surprised to run out; the jacks were the first thing that I purchased for the build over a year ago. I didn’t revisit the quantity as the build grew in units. Also, I’d been pilfering from the stash for quite a while. Erthenvar to the rescue!

Ready for soldering:

Solder. Solder. Snip. Snip.

Front board and panel completed:

I’m also digging in to testing the power cables that I assembled using this handy cable tester from Tsyklon Labs available in kit form from Thonk.

I’ll be out of town for a few days next week - but my hope is that I will leave with all of the TXo panel and front boards completed. It will be on to the back boards (and associated headers) when I return. :slight_smile:

b


TELEX HANDY LINKS
TELEX Microsite | Ordering Process Details
Crazy Verbose Status + Timeline | Printable Command Reference

16 Likes