I’ve spend most of yesterday and all of today trying to get closer to my teletype/301/i2c problem (sometimes some i2c triggers are delayed exactly one M cycle), I’m still hoping to produce a teletype scene + an er301 quick save that will trigger the problem, but it’s hard, since it seems it takes some unknown ingredient to trigger the problem.
Anyways, the strange experience was:
Yesterday while working on a track, the problem appeared, and I decided not to reboot (which is what I tend to do since it always fixes the problem and I’m in the middle of trying to make music). I poked around with the two modules for about two hours and found that sending to to all SC.TR with “L 1 99: SC.TR.P I 0” after every metro cycle made the timing correct again. Removing the line and it was all bonkers. I also noticed that while in the bonkers state, and looking at the scope, all triggers (SC.TR.P x from teletype) on the 301 showed up as just a spike (so extremely short, I assume 1 ms or less) and also that it wasn’t possible to adjust the length with SC.TR.TIME 1 20 (or similar). TO.TR worked just fine.
I looked at the teletype firmware, and although I don’t understand everything, it seems like SC opcodes are simply copies of (a small subset of) the TO opcodes, at least I don’t see anything odd there.
@odevices Any chance you could take a look at the i2c implementation in the 301 for me? Does this strange behavior ring a bell with you? Anything I can do to help (I’m still working on reproducing the problem reliably)???
It seems like the attached combo will trigger the problem, first a simple rhythm, then it speeds up, let it run for a while, F1 will slow back down to check it rhythm is bonkers or it needs to run some more, F2 will go fast again.
It’s not a real world example, but it should make the problem appear after an hour or two. If it doen’t sound off after a few hours, try loading WITHOUT REBOOTING an actual set of real life quick-save/scene, and I’m pretty sure it won’t sound like you expected.
Just wanted to chime in and say that I’ve also been able to get some weirdness with SC.TR.P commands as well.
My setup is using a Cirklon to send MIDI clock to my Transit module, which is then passing along the 24ppq clock via SC.TR.P commands. I’ve been able to send them at very high speeds with extremely low jitter (80Hz, 24ppq @ 200BPM). Unfortunately after some amount of time (seems somewhat random, but usually happens between 15-30 minutes) the clock becomes extremely jittery. I can still send SC.TR(.P) and SC.CV commands, but the timing of things becomes odd.
As far as I’ve tested, it’s an issue with the ER-301, since pressing the reset button on the Olimex daughter card fixes the issue, even with the Cirklon/Transit clock combo continuing to run during the reboot.
Once the ER-301 is rebooted and the quicksave is reloaded, the timing is rock solid again.
I’ve also attempted to just reload the quicksave, but it doesn’t fix the timing issue.
Let me know if there’s any other info I could provide to clarify the issue.
Hi. I can confirm that it happens to me frequently, and that only rebooting the ER-301 fixes it. I switched to 0.5.01 firmware to see if that made a difference but it has not. I have been using the ER-301 and Teletype much more frequently during the pandemic.
To further add, I don’t have to be doing anything with either the 301 or the TT to make the behavior occur. I can turn it on and wait and it will always eventually happen.
I am using the same script I uploaded to a previous thread [Metrotype ]. The ER-301 is ~51% load. Playing 4 samples triggered by teletype w/ a few different delay effects as well as 2 aliasing saw oscillators for a bassline (with several mixers, VCAs, and envelopes). Nothing too complex or even any custom units.
The incoming i2c triggers are not processed in any way and go direct to the trig slots of the samples.
Thought I’d chime in with a bit more info that might help if this issue gets looked at for fixing.
Just spent a couple hours using I2C communications via my Transit module. This time I turned off sending MIDI clock so that it wasn’t getting 60+ messages per second, and instead was only receiving an average of 5-10 per second.
In this setup the issues described above (delayed propagation of messages sent to the ER-301 only on the ER-301’s end) took an hour or so to occur, as opposed to a matter of minutes when I was sending MIDI clock. Perhaps this might shed some light on why this issue is occurring.
EDIT: Of course I have to eat my words, the issue happened within minutes as I was typing up this post.