#1

I have a long sample with 32 slices loaded into a raw player. In the teletype, I’m using a counter going from 0 to 31 to select the appropriate slice to play.

I’m running into this intermittent but persistent problem in which 0 in my Teletype counter isn’t triggering the first slice in the 301. It’s offset (late) by about two slices. So while the Teletype variable is at zero, the 301 is still only on slice 29. Does that make sense?

An INIT sometimes realigns the counter/slices, but usually I have to restart the case to get things back to alignment.

Any ideas?

#2

yep i’ve experienced something similar. the solution for me was to add a micro delay after the trigger, which ensures that the cv changes the slice before it starts playing again.

#3

The following points might help:

Slew
Make sure the CV slew is set to zero (SC.CV.SLEW port 0), or, use the SC.CV.SET command instead of the SC.CV command. The SC.CV.SET command ignores the slew setting.

Ordering
Place your SC.TR commands after the SC.CV/SC.CV.SET commands in your Teletype script. At the moment, Teletype I2C messages are sent one-by-one and there is no grouping functionality (i.e. here is a bunch of messages to treat as simultaneous). So the order in which your Teletype program generates the messages is the order in which the ER-301 will receive them along with a non-deterministic time interval between the messages (especially if there are a number of devices sharing the i2c bus).

1 Like
#4

I seemed to have made improvements to the stability by reordering the commands. Especially the ones related to the counting, interestingly.

Thanks, as always, for your help.

#5

I did make another little discovery. On one ‘track’ in which I have the 301 at about 80% cpu, it does tend to get the incoming triggers/cv garbled more regularly. Instead of restarting the case, this time I just re-load the entire saved state of the 301 and when it came back online everything was triggering in sync again.

So without understanding the technicalities of it, it does seem like the i2c bus is getting corrupted somehow…and it may be more on the 301 side, by this discovery…

1 Like