Thanks for the replies. This all makes sense now. It’s wonderful to have this many talented people working from different angles on the TT firmware. I can barely contain my excitement for my incoming ER-301
So just updated TT firmware with latset beta, yet the screen shows:
TELETYPE 2.1.0: grid be6cc6e
isn’t it supposed to be 2.2?
That is the correct version. As noted above, the Grid beta (which is the one that includes the ER-301 support) has not yet included the yet-to-be-released 2.2.0 features. It is still on the previous version (2.1.0).
Once 2.2 is live, it will be integrated into the beta.
For those here who are just now becoming aware and wanting to learn more about Teletype and these firmware updates that are occurring, like Orthogonal Devices here there is a momentum of improvements and innovations that are happening on a fairly regular basis. Since I got my own Teletype just a few months I’ve seen huge steps that have greatly extended the capability of the device.
I’ve been told though that this can move in fits and spurts, so users have to be patient as they wait for things. The Teletype is open source so for the coding inclined it’s a straight forward bit of going to the Github repository, forking your own branch, and tackling the fix or adding features just as @scanner_darkly (Grid integration), @bpcmusic (Telex modules and ER-301 integration), @sam (Euclidean rhythms, and Sliderule (Turtle, Chaos, and Bitwise operators) have done over the past approx. 6 months.
The Grid emulation in the Teletype is amazing, though I’ve not played with it in weeks as I’ve been entrenched in testing EVERYTHING in the new 2.2 firmware, now that I’m so accustomed to 2.2 and those new features it will be tough to give them up to start testing what will be the candidate for 2.3 with Grid operators and the new ER-301 functionality. I can’t wait for @scanner_darkly to merge the versions when 2.2 goes to release.
The point here is that Monome gear like the Orthogonal Devices ecosystem are evolving entanglements of mind snares that invite the inventive and curious to explore the depths of complexity. If you aren’t prepared to be boggled at the possibilities and the waiting times for your particular wish or need to be satisfied, you might want to forego the desire to acquire more cool gear and really let it sink in that one knob one function is not a design philosophy you are going to find at work here.
On the other hand if you’re intrigued by exploring stuff that hurts your brain, pride, sense of knowledge which allow you to thrive proving you have just enough to ultimately tackle the seemingly impossible; this stuff is going to make you ecstatic.
Which is why I am so grateful you are pushing to get the documentation for 2.2 finished. As my understanding is that this is the main reason why 2.2 has not been officially released.
Here is hoping for soon!
I’m done with what I can do. I believe sliderule has probably already passed it on to Brian by now and we just need his seal of approval
OK, so I have done some further investigating, which got me a bit more confused about this situation.
First I commented all of the I script.
It made no difference: the TT froze when er-301 was booting (always at the same point in time).
Then I disabled the METRO.
That prevented the freeze. Which would seem to suggest that the cause of the crashes was inside the M script. (Even though, I could see/hear METRO executing everything fine in my previous tests, before that specific moment of the er-301 boot).
So, something here:
M C; TO.CV 1 VV SUB 600 C
TO.ENV.DEC 1 DIV C 4
TR.TIME 1 10
C ADD C 11; TR.P 1
IF GT C 400: C 20; TR.P 2
Although curiously: nothing here talks to ER-301, just some Telex commands and mainly changing the value of variable C determining the timing of subsequent M cycles.
So I started commenting individual lines of the script, which pointed at the very first line:
M C; TO.CV 1 VV SUB 600 C
when I commented out that first line, everything else worked, and TT did not crash.
Uncomment that first line, and we have a crash again.
I thought that maybe somehow it was the use of the sub command via ; in the first line was causing problems, but that was not it, as I eliminated it and only left:
TO.CV 1 VV SUB 600 C
Which also caused the crash.
This is as far as I could take it tonight.
MY suspicion is now with the way Teletype communicates with the Telex unit via i2c, which is somehow stressed by whatever happens at the moment ER-301 loads the QuickSave. (Which again happens, after all the loading percentage values go all the way to %100, the screens go dark, and when the LEDs on the CV input grid cycle through the panel: the Teletype consistently crashes when the LED cycle begins.) Even though the script being executed contains no SC.TR nor SC.CV commands.
I would be curious to hear what @bpcmusic would think of this.
Is there some way the ER-301 loading procedure could be corrupting the i2c communication flow between TT and TelexO? Other?
Great investigation @laborcamp! Top notch sleuthing in my opinion.
i2c uses a shared bus so it is absolutely possible that electronically the ER-301 is doing something to the bus that is preventing communication between TT and other devices. I’ll be taking look. There are also other possibilities involving things like the i2c master (TT) not handling unack’ed messages properly.
Glad to hear this!
And thank you kindly.
this would solve the problem with crashing but then you’d have a problem with Init script not doing what it’s supposed to do.
at this point it’s hard to say what is happening in your case without looking at the actual i2c communications with a scope capable of i2c decoding. i might be able to take a look once i have it all set up (finishing grid integration has to remain my top priority though).
i’m hoping this is something that could be easily addressed on the er-301side. from my experience investigating previous i2c issues the i2c library we use in TT is not very resilient and doesn’t handle corrupted requests well (the main fix was to give i2c interrupts the highest priority).
one more important point - are you using a powered i2c board? if not that might also cause issues with i2c, especially with multiple devices connected.
Yes. Using the powered “backpack” I got from @bpcmusic.
With fairly light load: 1 TxO, 1 TxI, and ER-301 attached.
This has probably already been covered here BUT if the teletype is controlling the 301, does it use all of the ports on the 301? Meaning can it send in essence 16 different commands, or will it be able to send what it could normally send via the teletypes’ physical jacks?
Does the teletype still have enough headroom to use its physical ports elsewhere?
Same question with the 301,if the teletype is controlling it through i2c are the physical ports still available?
The “virtual ports” are ON TOP of the physical ones. So, yes, you can use both on both modules.
In the same boat. Intrigued but slightly worried my day job would be creeping into my studio. Highly likely I’ll give in at some point!
How does the software allocate those? Instead A1 on the 301, does it say V_A1?
pulse trigger out 1 on Teletype:
pulse virtual trigger out 1 on ER-301
On the ER-301, there are two Teletype units, one for triggers and one for CV. These units have a ‘port’ parameter (modulate-able, range of 1 to 100) that determines which signal will appear on the unit’s output.
So, let me get this straight. This means that instead of 16 possible input options, there are now 100 when used in conjunction with the teletype?
Does the i2c connection support audio as well? (is the protocol capable of a much denser data rate?)
100 Trigger / gate ins + 100 cv ins + physical ins.
No audio on i2c, it’s slightly faster than your old USRobotics modem (100Kbits IIRC).
Is that theoretical or can the teletype in reality support 200 connections on top of its physical connections?
That is a seriously massive amount of control between the two modules. Is there any latency that happens as a result of the 301 now polling the i2c network?
I’m trying to not freak out. Need to take a serious look at the teletype. Might be time to ditch the toolbox.
Edit: and you know what the ironic part is? I dismissed the teletype because I thought a sudo programming language as a method for sequencing stuff seemed dumb, not to mention programming is my day job. This is closer to bash though and when I really think about it a script is sort of the ultimate way of sequencing alot of information. Its trade off is intuitiveness and accessibility. However being able to interface with only the 301 like this is a bummer. It looks like the teletype only has 4 CV and 4 gate outs which really limits its physical capability. Need to dig in some more.