Home | ER-101 | ER-102 | ER-301 | Wiki | Contact

Sc.cv deleyed one step

i’m having issues with the sc.cv unit, i made my own midi to i2c interface with an arduino, and after a certain amount of time, the incoming i2c data is delayed one step, could be my novice programming, but rebooting the arduino does nothing, while rebooting the 301 makes everything align again.

for example if i play “c” “d” “e” on a midi keyboard, the incoming sc.cv values would correspond to “x” “c” “d” where “x” would be whatever note i played before “c”
the sc.tr is still triggered “where it should”

Sounds exactly like my problem, except (afaict) I never have cv delayed but tr, and I’m i2c-ing from a teletype…

I think @odevices is looking into it, I send him a couple of humble test files. The tough one for me has been trying to figure out what triggers the problem, and I frankly have no idea, it just seems that i2c is scrambled after “a while” “sometimes”… Very frustrating, imagine for Brian as well…

https://forum.orthogonaldevices.com/t/strange-experience-with-sc-tr-p/4051/7

EDIT: are you by any chance sending more cv than tr? Reason I ask is because I’m sending more tr than cv, so if you are more heavy on cv, that might explain why you’re having trouble with vc while I’m having trouble with tr…

I have a 75uS delay in my I2C transmission code if it’s been less than 1ms between messages. This was to fix dropped notes when they were being sent in rapid succession. Perhaps that might help the issues that you’re having.

i do have a delay after each i2c transmission

i use gates mostly, so on midi note on i set sc.cv, then set sc.tr to high, then set sc.tr to low when i receive midi gate off, so i guess i also mostly send sc.tr commands

also: do recall that the gates where “flipped” low on gate high and high on gate low…

Are you using SC.TR.TOG or SC.TR to set the gate high and low?

EDIT: Also might be worth seeing if SC.CV.SET fixes the delay issue as opposed to SC.CV. Perhaps something odd is going on with the slew.

I’m always using SC.CV, no slew, almost always using SC.TR.P occasionally SC.TR, never SC.TR.TOG

NB: I have two txo’s (also i2c) they are rock steady, never ever missed a beat.

If one knows about the lower levels of implementation it might be obvious why, but from my chair what is odd is that messages are always delayed exactly to the next M cycle, not some tiny, random amount of time.

Have you noticed different settings of pulse time having any effect on experiencing the issues you’ve been having?

Im using SC.TR, sending it 1 for gate on and 0 for gate of, SC.TR.TOG seems unreliable to me\

also im only using the slewed sc.cv command for cc’s
the notes are sent without slew

1 Like

Kind of/maybe…

I normally don’t init SCTR.TIME, but as we speak I’m experimenting with initing them all to 10ms (from looking at them they look like they are 5ms un-initialized). After adding adding this init to the track I’m working on this morning, the bug didn’t bite, but it’s too soon to draw any conclusions…

1 Like

I just wanted to add that this can be really hard to notice if not using a keyboard to play notes, as I’m guessing most of us use sequencers rather then keyboards.