Persistent Reset probs?

OK now I’m confused! :confused:

My setup here is basically the same as vocoder’s setup in the diagram in the previous thread. Just instead of a x24 clock being divided down in the ER-101/2, I’m using x16 with no internal division.

Let’s break this down. In your last example, your reset signal was coming from the PW but it was 1x which means it should just be a copy of the original clock. So how about not using the 1x from the PW in to the ER-101 reset, instead plug the original clock directly into the ER-101 (using a multiple if necessary). No division necessary.

So assuming that still has the problem, the next I would like you to try is to plug your external clock into both the PW and the ER-101 clock input. Use the PW to divide by 16 and run the result to the ER-101 reset.

Finally, before any of this can you please make sure the PW has no delay adjustments set as per p.7 of the PW manual. Check both the 16x clock signal and the 1x reset signal.

I see the confusion, I’ve actually been clocking the PW at 24 ppqn as clocking the PW at 1ppqn doesn’t really work in practice. But let’s say we get rid of that variable (the PW is little jittery under DIN sync) and just run the internal clock of the PW, so it is now the master clock and each output is a division or multiplication of it. Unfortunately it doesn’t remedy the behaviour.

Here’s a diagram of what I’ve been doing to try and examine the problem on an O’Tool scope.

My rationale here was that if I sent out a sequence from the ER-101/102 with 1 gate for each clock pulse, I could compare them on the o’tool and it would be easy to see any clock pulses getting lost somewhere along the way, i.e. I’d see a clock pulse but no corresponding gate.

I’ve tried this with the original snapshot where I noticed the problem and a couple of fresh new snapshots with no other track, part, or group data on them and used different tracks to run the test patterns (I’ve tried various patterns too) and I’m always having this problem.

I have also checked the PW delay settings and everything is in order with no delay applied.

Hope this info is helpful, let me know if I can do anything else.

Any other Pam users had this kind of problem?

So the goal at this point should be to find a patch where the reset behavior is working for you. We don’t need anymore examples of where it is not working :smile_cat: Then we can compare what is different between the patches and concentrate there.

Perhaps, a picture of your case will help me determine alternative patches that we can try to simplify and isolate the problem? To move on, we really need to get the PW out of the loop at least temporarily for information purposes.

Down the road, if we determine that it is the combination of PW+ER-101 or just the ER-101, or just the PW, that is causing the problem then we can focus on that. At the moment, we don’t have enough information to say which though.

Hey Brian, I’ve changed tack as suggested and tested with a Pittsburgh Game System. It has a mode that spits out different divisions of it’s internal clock.

I’m really sorry, but it’s another example of where it’s not working. If there was a hide under chair emoji, I’d use it! :fearful::camel:

Super late here again, I’ll try tomorrow with more clock/reset sources.

No reason to hide underneath that chair. This is helping me as much as it helps you!

Here is another idea:
Disconnect the ER-102 from the ER-101 and try your test with the ER-101 in standalone.

I’ll be trying various things here too.

I’ve performed some more tests and things are getting stranger round here. :dizzy_face:

I’ve tested now with clock and reset coming from the PW, Pittsburgh Game System and finally, the CV outs from an Analog Keys.

I’m afraid the bad news is I still haven’t got the reset working properly with any of them. The severity of the problem (i.e. the number of times a pulse is dropped over a given number of resets) seems to vary with each device used to perform the test. All exhibit the problem to some degree though.

I’ve also disconnected the ER-102 and tested the ER-101 in standalone mode and the problem changes in nature here. Basically, instead of observing a missing gate on the track gate output (which is a copy of the clock in), I get an instantaneous trigger instead of a gate.
This will successfully hit, say, the trigger input of a Mutable Peaks, but of course no good for an envelope set up to respond to gates. Basically, in standalone mode, I can use reset if I stick to triggers.

Another thing I’ve noticed is that with the ER-102 connected, gate lengths of duration 1 and gate 1 are shorter than in standalone mode. They come out as a trigger, and don’t seem related to the clock pulse.

I’m totally baffled by all this, but I hope I’ve explained everything ok?

Hmm I wonder if what you are actually seeing is the portato bug reported over here:

It has nothing to do with reset behavior but rather when steps with gate=duration (i.e. portato) and really slow clocks were used, gate lengths were not being generated correctly.

Could you try installing that pre-release firmware that is posted there?

Just installed and it fixed the erroneous gates, but I’m afraid it’s had no effect on the reset issue.

So the conclusion so far is that you have working reset behavior with your ER-101 in standalone but no matter what you try it doesn’t work for the ER-101/102 combo. Correct?

No, gates are not being outputted correctly in standalone mode. The initial gate after receiving a reset pulse comes out as as trigger instead of disappearing completely like in 102 mode.

Hmm. I feel like I’m going in circles here. So I’m going to slow down and spend a few days thinking about this and conduct some more tests.

In the meantime, if you can measure how late or early your reset pulse is with respect to the nearest rising clock edge, that would help.

Hi Brian,

So I’ve repeated @Odan s test and I am able to repeat his problem (based on how I understood his description).

I set up the same experiment that was on the hand drawn diagram above posted by Odan I.e.

Test 1:
Pamelas New Workout (PNW) sending x16 pulse (width 10%) to ER101 clock in
Pamelas New Workout sending x1 pulse (width 5%) to ER101 reset
Single step in the ER101 of duration = 1 & gate = 1.
1/1 clock multiple/divide

I then send the ER101 gate out to one channel of an O’Tool scope and the reset pulse (mult’ed from the ER101 reset input) to the other O’Tool scope channel.

What I observe is that when ever the ER101 receives the x1 reset signal the ER101 gate output drops a gate output. I think from Odan’s description this is what he is observing … I think.

Now I haven’t observed this before because I’m always running a x24 pulse from PNW to the ER101 as the clock, with a /16 reset from PNW and using a 2/3 multiply/divide clock settings.

If I modify the original Test 1 but using my typical clock multiply/divide setup:

Test 2:
PNW sending x24 clock
PNW sending x 1 reset
Single step duration = 1 and gate = 1
2/3 clock multiply/divide

Then I don’t observe the dropping of the gate output when the ER101 receives the reset pulse.

OK, so then I decided to keep things even simpler and modified Test 2 by changing the clock multiply/divide to 1/1:

Test 3:
PNW sending x24 clock
PNW sending x 1 reset
Single step duration = 1 and gate = 1
1/1 clock multiply/divide

And now the dropping of the gate returns whenever the x1 reset pulse is received.

The outputs from PNW are extremely tight timing wise (I tried to see if there was any delay even at the 100 us scope setting but couldn’t see any delay from two x1 outputs from PNW) so I’m guessing a clock and reset are received by the ER101 almost simultaneously which is causing the ER101 some trouble whereas if you activate the ER101 clock multiply/divide option the calculations that are being made to determine the new clock somehow mitigate the ER101 receiving a clock pulse and reset pulse simultaneously. Does that sound plausible?!

I hope I haven’t complicated things by adding the above but seeing as I had previous experience of reset issues I felt that I should lend a hand if possible as it wan’t clear things were moving forward in the thread.

2 Likes

This is tremendous help. Question: It drops the gate 100% of the time in cases 1 and 3?

Yes - I didn’t observe a time when the gate wasn’t dropped in tests 1 & 3 when a reset pulse was received.

Bingo.

Thanks so much for taking the time to do this mate, appreciate it.

Oh dear, are my descriptions really that garbled? :upside_down:

You’re spot on.

Actually my homework for this evening is to try your setup of x24 clock divided down internally, I reckon it’ll probably work for me too.
If you were inclined you could unplug your 102 and I think you’d see the gate not dropped completely on reset, but a weensy trigger instead.

I wouldn’t go so far to say garbled :wink:

I do a lot of testing (at work & modular related) so I always put myself in the shoes of the person reading the test report if there’s a problem & thinking "is there enough information here to completely describe the issue for something to be done about it?"
Of course this adds quite a bit of extra effort on the tester just to be as clear as possible & sometimes it might seem over the top but it might be the one insignificant detail to the tester that is the key bit of info for the developer.

Anyway, glad I could help a little.

Hey Brian,

I’ll just add that in test 1 I’m seeing that some gates do pass and some appear as just a trigger. Most are dropped though.

Also will add that I tried a x24 clock with 2/3 multiply/divide settings and my reset blues have disappeared! Needless to say, I’m having a super fun time again.

Anything I can do to help further, please ask of course.

Thanks for the support!! :+1: I appreciate it very much (^-^)v

2 Likes

Just dropping by to say that I haven’t forgotten about this!

http://wiki.orthogonaldevices.com/index.php/ER-102/Tracker

1 Like

Update: My PNW has arrived and I can start looking into this issue efficiently. Love the cute display…:heart_eyes_cat:

I should have more info next week.

3 Likes