Strange experience with SC.TR.P

ER-301
#15

I’ve been experiencing the issue I mentioned above with only my Transit module and 301, no other modules.

#16

Ok, thanks, good to know (although I’m not the one that’s gonna look at fixing it)

1 Like
#17

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.

2 Likes
#18

Thanks. In any case, I think you’re unto something. Although there’s not a linear correlation, it does seem that the more busy traffic is on the i2c bus, the sooner the bunkers state kicks in.

1 Like
#19

May I ask everyone to retest their I2C setup with v0.5.02 please?

4 Likes
#20

I have a good feeling! to early to say, but nothing is inverted, missing or delayed

#21

ok, nope, gate is inverted :cry:

#22

Inverted gate? I’m not following.

I’ve been looking for timing issues…

#23

Been running 2x Transit → 301 setups concurrently with 70+ I2C messages a second for a couple hours with no issues :+1:

Thank you so much for working on this issue! So excited at the prospect of not having to reset my case every so often while working on tracks.

3 Likes
#24

Very happy to report I have been running continuously for over 7 hours with solid timing, same script that used to fail everytime between 30-60 minutes. Great Job Brian!

4 Likes
#25

Thanks so much for working on this! I’ll be running i2c all day and report back! Thanks @odevices

EDIT: Purely out of curiosity, which of these is addressing the issue in the current thread? The “grew over time” makes me guess the first one…

  • FIXED: Teletype Integration > Jitter in message timing grew over time.
  • MAYBE FIXED?: Teletype Integration > Need to wait for ER-301 to finish booting before booting other I2C devices. Feedback needed.
#26

Sry, did not really explain, my original thread below, but did not really mention the gates, but its kinda the same thing, like the whole input is offset one step back, when sending gate high, the 301sets gate to low, and vice versa. restarting the i2c transmitter changes nothing, while resetting the 301 makes it get back to normal

#27

I’m testing away, stressing the i2c that extra bit, so far no timing issues.

However I had a freeze about 15 mins after boot, removed a raw player and when trying to insert a varispeed player the 301 froze. Might not be related to the fix, but I can’t remember the last time I had a freeze, so I suspect something new caused this. I know it’s not much to go on, but there you have it, will obviously keep an eye out, and report (and try to recognise a pattern) if this happens again…

NB: the 301 was receiving on the i2c bus while this happened…

#28

Update: The i2c bug bit me again. Been sound designing all day on the 301, connected to a blank, not running teletype. Decided to throw a beat together to hear one of my new units in action, timing was off :frowning:

The triggers I’m pointing at in the video are the two triggers send on the same line in the teletype script: SC:TR.P 3 and TO.TR.P 1, all other triggers (teletype hardware and txo connected to teletype via i2c are in sync, triggers over i2c to the 301 are delayed exactly one M cycle.

So I’m sorry to report we’re not there yet…

https://www.dropbox.com/s/r1pv8y5o3nw7vry/i2c_301_fw_052.mp4?dl=0

#29

Some questions:

  • Is the ER-301 receiving any i2c messages on that “delayed” beat?
  • What is the script producing the wood block sound?
#30

To answer your questions:

  1. Yes (the 301 is receiving on all beats, M sends out “clcok” on SC.TR.P 100)
  2. Its script 1

Everything is quite simple and sparse, but in my experience it’s something that accumulates, so when the bunkers state occurs, even the most sparse timing will potentially be off. I attached the scene in question…

sound_design_i2c_stress.zip (722 Bytes)

#31

Hopefully this finally squashes it.

2 Likes
#32

Amazing, thanks! Finger crossed! Will go crazy testing the entire day tomorrow!

Thanks!!!

#33

Just wanted to say that it seems (dare I say it) the i2c bug is fixed. I’ve been using the er-301 both in relaxed situations, deliberately stressful situations and “just normal”, and haven’t had this happen since 0.5.03!

Thanks alot @odevices for caring and taking the time to work on this (I imagine) very frustrating bug. The teletype and er-301 are the cornerstone of my setup and I’m so happy that it’s now really solid!

Thanks!

5 Likes
#34

And thank you for your patience and the bug reports!

3 Likes