FYI, I just tried @laborcamp’s example and indeed it looks like the Teletype (2.1.0: 205521A-ER301) is forwarding ports 5-8 to slave address 0xB1 and so on.
I thought I was losing my mind…
Hold on! We both might be using the wrong firmware for the Teletype.
Yup, that is definitely it. I just tried teletype.SCALPHA2.hex.zip and now it works as documented. And I believe the mix up is my fault because I linked to the SCALPHA version instead of SCALPHA2 version on the wiki page. Sorry!
Of course you are right - I was too short here.
What I meant was in the context of the question if i2c to ER-301 is “still limited to the 8 available scripts” that the scripts are conceptional bound to their corresponding trigger input. You can crosstrigger them but the idea is 8 inputs, 8 scripts.
The last statement I know of from Brian is that this shall stay like it is but there may be something like a timeline mode in future to expand the programming capabilities.
Sorry for posting an interim version. I’ve merged the final code into @scanner_darkly’s grid branch - which should be the next official release of the TT firmware (2.3) which will start queuing one 2.2 is official (any day now).
There IS also talk of “alt” scripts (like an alternative “layer” of additional 8, etc.), which I personally am keen on
Hi…as per my knowledge virtual bus of cv and gate inputs inside the 301 that is addressed via teletype scripts. Using teletype scripts to “poll” the 301’s physical input states, basically turning the 301 into a hardware input expander.
Apologies if we were daydreaming about new functionality here - but for the sake of clarity, I figured I would post this.
In the current implementation, it is actually the other way around.
The Teletype sends i2c events to the ER-301. The events manipulate the trigger states, voltage values, and behavioral characteristics of the virtual inputs that you can integrate into your ER-301 patches. It’s like having 100 extra trigger inputs and 100 extra CV inputs to do crazy stuff with - programmatically controlled by the Teletype.
that’s f!&@^%# insane!
It totally f$%#!ing is!
i badly need a Teletype now! (thanks to all the people involved in making this synergy happen)
I have a specific crash circumstance to report:
Teletype: SCALPHA2 2.1.0: 205521A-ER301
ER-301: er-301-v0.3.08 48kHz
EVERY RRAND 1 8: TR.P 4
PROB 12: TR.TOG 3
SC.CV 5 V RAND 10
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
TO.ENV.ACT 1 1
TO.ENV.ATT 1 10
TO.ENV.DEC 1 222
TO.CV 1 V 7
The above SCENE, when set as a startup scene on TT it hangs/freezes Teletype at the moment when ER-301 begins loading it’s Quicksave (when the LED sweep begins to be exact).
There are a couple of seconds before the freeze happens, where I can see/hear that Teletype actually executes the scene (since the main action takes place in METRO script. It stops when the ER-301 kicks in. This makes me think that the problem is not with TT or the script, but rather some sort of interaction between TT and Er-301 during load.
I can avoid the freeze, when right after startup I can switch manually TT to open a different scene. Then everything works fine. I can even load the above scene, after all modules are running, and it works just fine. The freeze only occurs during the load time at the moment described above.
The freeze also occurs when no external patches are present, so only with the i2c communication taking place.
Curious to see if anyone could replicate this?
I ran another test, but this time I set the ER-301 to start with a Quicksave that was empty (no chains), and this scenario produced no crash on the Teletype…
the chances are tt starts sending i2c before er-301 is ready, causing i2c messages to get corrupted. there isn’t an easy solution for this, other than adding a couple of seconds delay before Init gets executed.
you can test this theory easily - try moving content of I to a free script and then call it from I using
btw, i’ve posted a new teletype beta here: https://llllllll.co/t/grid-ops-integration-beta-jan-12-er-301-support/9216/293
this is the latest grid integration beta which now also incorporates the latest implementation of er-301 ops from @bpcmusic!
I’m a little confused with the various branches of the TT firmware. Does this beta also contain all the latest features sliderrule (over on the monome forum) has added? I know the grid integration firmware has a grids simulator but is this still only of use to users with a Grid? Sorry, I haven’t been closely following the discussion on this firmware!
the latest official release is 2.1. there are 2 beta versions right now, one for the upcoming 2.2 release driven by sliderule, and the other one is for grid integration (which now also includes er-301 support). once 2.2 is officially released i will rebase my grid branch on that, at which point we should only have one beta that will incorporate 2.2 features, grid and er-301 support. this beta will become 2.3 release once tested and documented.
you can totally use grid ops without a grid. obviously, there is the immediacy of using an actual grid, but you’d be surprised how usable the grid emulator is. i often don’t connect grid at all. this all depends on the scene too, of course.
[EDIT] And now from the Department of Redundancy Department … (sorry for the overlapping post): [/EDIT]
Yup. It is confusing; lots of activity going on.
Teletype 2.2 is the version with all of the new stuff from sliderule. It is currently in its final stage and should be released any day now. It doesn’t not have ER-301 support included as it was way too close to release of 2.2 to try to sneak the ER-301 operators in, which are still in the early integration testing phase.
The decision was made to include the ER-301 support (and some other things I’ve had cooking) into the next big Teletype release, which was to be @scanner_darkly’s version with Grid support. He was kind enough to agree and support this approach.
The plan is that once 2.2 is released, @scanner_darkly (sorry to speak for you) will pull in all of the changes that were made in 2.2 into his Grid branch. This version will then be on path to become version 2.3, once we are through the testing period with all of the changes.
Unfortunately, this means that until 2.2 releases, there will be features that are in 2.2 that aren’t in the Grid beta. We need to wait until 2.2 is fully final to do the merge in order to keep the amount of work and risk in that integration to a minimum. The good news is that this is not too far away!
Hope this all makes sense.
I will run the test you are suggesting.
But isn’t it concerning that the setup has the capacity to freeze on load?
The TT definitely starts before the er-301, because I can see/hear it working before ear-301 is done with load procedure.
Seems that perhaps some sort of block might need to be set upon the re-301 to not accept the i2c commands until it is done with the load procedure?