No lower resolutions on my tracks. All 1x. I mean, pattern sequencing is a super simple thing. It should listen to that event and take into account the LENGTH parameter. And that works as long as you are in NORMAL mode. Somehow the ADVANCED mode it becomes buggy.
I remember I had this issue years ago on my DT/DN combo as well. Never gave it much thought back then.
I have found it way more stable since starting from scratch, and I also have my Digitone changing in sync (AR>A4>(thru)DN)… every so often the A4 will lose sync, but Stopx2 seems to fix it. It’s still not ideal though… I wouldn’t feel confident in playing this live, which is an issue.
Yeah, I’m gonna start blank projects too and if it works try to break it. See where it loses sync. So weird though because it’s really consistent in the way it lags behind. Clearly the pattern change event is received but somehow delayed/queued for a cycle.
The problem here is that the Pattern Change event is not sent when you select a new pattern but when the pattern change takes place. Hence it lags behind a cycle.
Just tried with initialised projects on both machines.
First. Pattern Length NORMAL mode. Perfectly synched pattern changes.
Second. Pattern Length ADVANCED mode. LENGHT 1024 (could also be any other value) and CHANGE 16. Result. Pattern change on slave machine (A4) lags one pattern cycle.
I even kept patterns initialised. Meaning standard 16 steps. No time scale changes or pattern lenngth. All super default. Just changed from NORMAL to ADVANCED mode on Pattern Scale
This must be a bug. A pretty fundamental one if you ask me.
Sorry if this is a granmother/egg situation, but have you connected the ins and outs of both devices? ( I had to double check the manual for that, or someone on this forum told me…can’t remember which.)
Sorry, after looking into it a bit more I realize that I got confused for a while - and you are of course correct. Whenever a program change is received the device will cue the corresponding pattern. The change will happen based on the state of the receiving device, just as if the pattern was cued locally. If the pattern setup is equal between two devices the behavior should be identical. The behavior you describe is a bug and I will immediately talk to our developers about it. Thanks again for reporting!
Say what? That makes less sense than their original comment. How can the receiving device know that the sending device has hit the end of its CHNG cycle?
I guess the end of the sender’s CHNG cycle (or slightly before) is the moment when the pattern change is sent? If the sending device is readying a pattern change, it will (or should) send that PC message out to other devices near the end of the cycle so the receiver will get ready to change too. Right?