Mapping strangely stops working

[zeitkunst]

Hello,

I have a strange problem that I'm trying to diagnose. I use mapping with triggers to the four inputs to advance four tracks at differing rates (basically a different clock for each track). Recently I am having an issue where when I first turn on the Nerdseq and start the tracks this mapping works as expected, but then if I stop those tracks for a while, and then try and start them again, the tracks are not being advanced (even though the incoming triggers are still present, confirmed by using those triggers outside of Nerdseq, but also by seeing the values change on the mapping screen). I am at a loss as to how to approach this because I can't figure out what causes this issue. I've reformatted my SD card but the problem still exists. I'm on v2.01.

Note that things work properly using the internal clock, so it's also not an issue with the outputs.

I've attached my project file if this helps at all.

Thanks for any suggestions!

[XORadmin]

Are the tracks running already when you start them again?
The rules for these tracks with starting and stopping are the same as for normal tracks and they start mostly at the zero cross of the clock.

And word of advice: Formating the SD Card will never solve any issues which might be firmware related.
If the firmware is flashed then it works.

And is it V2.01 or V2.01A?

[zeitkunst]

Are the tracks running already when you start them again?
The rules for these tracks with starting and stopping are the same as for normal tracks and they start mostly at the zero cross of the clock.

And word of advice: Formating the SD Card will never solve any issues which might be firmware related.
If the firmware is flashed then it works.

And is it V2.01 or V2.01A?

No, the tracks aren't already running. I'm starting the tracks from a complete stop. And I'm on v2.01.

This is what I have for my mapping:

CV    IN 1
CALC    PASS    00=6 > TRCK    TRK1    TICK
CV    IN 2
CALC    PASS    02=6 > TRCK    TRK2    TICK
CV    IN 3
CALC    PASS    04=6 > TRCK    TRK3    TICK
CV    IN 4
CALC    PASS    06=6 > TRCK    TRK4    TICK

I've also just been able to reproduce an issue that has come up in some of my performances, which I wasn't sure whether or not it was caused by my beta module that I'm developing, or the Nerdseq...but I think now I've confirmed it's the Nerdseq   So either it's a bug, or I'm doing something wrong. After a while of running, and with rock solid triggers coming into the inputs, the timing goes haywire. It's hard to describe exactly what happens (although you heard it happen at my VCA performance back in January ), it's as if the timing for the track speeds up to its maximum, no matter what kind of trigger is coming on the input. I luckily just was able to catch a recording of this happening which can be heard here: https://nebula.tranxxenolab.net/s/WW8e5nPascq9ooc . Note that I have 4 voices, each with a different trigger coming in providing the "clock", so basically each voice is running to a different clock. You can hear what that sounds like for the first 25 seconds or so. After that is when things start to go "haywire"...I don't change anything, I don't change the rate of the triggers (I confirmed today that my module that is outputting the triggers is functioning properly), I don't change anything on the Nerdseq...it just goes crazy. While this was happening today I went to the mapping screen and the reported values for the inputs were still matching the incoming triggers (that is, still changing at a regular rate and not going crazy, so it's not as if the CV IN is changing at such a rate to cause the track to advance like you hear in the recording).

I know that what I'm trying to do is a bit esoteric (a separate clock for each track!) but if there's a way to figure out what's going on I definitely want to try and fix it!

Let me know if there is anything else I can provide to help track down what is going on.

[XORadmin]

One guess is that the CV IN does sometimes generate a value even if it is at zero volt
then. Like 0 is very close to 1 and 1 would generate already the triggers.
I do have a new user definable threshold in the upcoming version which could solve that possible issue. But I don’t know if it related (to the bursts).
I will check those out again and see if I can find anything and why it should possibly stop.

[zeitkunst]

One guess is that the CV IN does sometimes generate a value even if it is at zero volt
then. Like 0 is very close to 1 and 1 would generate already the triggers.
I do have a new user definable threshold in the upcoming version which could solve that possible issue. But I don’t know if it related (to the bursts).
I will check those out again and see if I can find anything and why it should possibly stop.

Okay, thanks for the insights. And thanks for looking into this! From my inspection the "low" of the trigger is reading around 060-150 and the high is at FFF so I would expect there would be enough discrimination between the levels there. If you want I can try and take a video of the mapping screen when the triggers are coming in.

[XORadmin]

One guess is that the CV IN does sometimes generate a value even if it is at zero volt
then. Like 0 is very close to 1 and 1 would generate already the triggers.
I do have a new user definable threshold in the upcoming version which could solve that possible issue. But I don’t know if it related (to the bursts).
I will check those out again and see if I can find anything and why it should possibly stop.

Okay, thanks for the insights. And thanks for looking into this! From my inspection the "low" of the trigger is reading around 060-150 and the high is at FFF so I would expect there would be enough discrimination between the levels there. If you want I can try and take a video of the mapping screen when the triggers are coming in.

Then I would expect that the trigger doesn't have a proper 0 level or the CV input is not calibrated correctly.
The Pass command doesn't have a threshold and so it is 0 or anything else. 060-150 is way beyond that!
The question is why does it seem to work then and my only guess is here that on the raising edge of the trigger the level goes below 0 shortly. But that is just a guess. I will check out your project this weekend and get back to you.

[zeitkunst]

Okay, I tried calibrating things as best as I could but I could never get it exactly at 0 for pass to work on its own.

But! I did figure out a workaround that creates a kind of threshold, and it seems to work in my limited testing so far.

Basically I take the input CV for each channel, save it to a variable. I then compare that variable to a pre-defined variable that acts as my threshold. If it's above that value, then the output of that calc is 1, otherwise 0. What I do then is save that calculation to the same original variable. Then, in my pass calculation, I check if that variable is 1, if it is, I pass the 6 ticks to the track.

This is the basic idea:

CV    IN 1    >    SETV    VA    SRC
CALC    IF >    VAVP     >    SETV    VA    SRC
CALC    PASS   VA=6    >    TRCK    TRK1    TICK
VAR    #P    #0A0

So far it's been working for about an hour like this with none of the "haywire" that happened before.

Now, why, using my old method, it would work for a while and then go haywire, I don't know   But this works perfect for me and what I need right now.