07-11-2024, 05:58 PM
(07-11-2024, 12:10 PM)XORadmin Wrote: 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.

