This all sounds really complicated, but I think it’s actually pretty simple, right? boxes don’t behave in some magic way when getting external PC messages. Sending the PC is exactly the same as manually pressing a button on the box to switch patterns.
So you can imagine what would happen if you had a 4 bar loop playing and you waited until the very last tick of that loop to select the next pattern: it would play another four bars of the old pattern again and then switch to the new pattern.
But no one plays them like this. Instead the press the button of the new pattern anytime before the current pattern loops to “queue up” the change. Then it switches automatically in time.
So just send your PC message when you would normally press the button and you’ll be fine, right?
Is this why we’ve hear so little on this from ? It’s literally working exactly as it’s alway has and was always meant to work? If it behaved differently when getting a PC, that’d actually be a little weird and unexpected.
No. If I send a PC message from my DN to my DT and I have varying track times or lengths, the DT changes a bar late. That’s not how it’s supposed to work.
Right. Which then limits the flexibility of my patterns even more. That’s the issue here. Either I have to manually change on all the boxes, or I need to make every pattern and track the same length. Neither is convenient or desired.
Sorry. Bad phasing on my part. I mean this is why we haven’t seen a patches or updates from them to “fix” this? Because it’s just doing what it’s supposed to?
Exactly! I can’t actually use song mode on the OT to map out all my other Elektron gear because I use different pattern/track lengths all over the place. As it stands now, I use my iPad and Mozaic to send PC changes to all the boxes at once, but it’s ridiculous that I need to do that.
It’s just another example of “these boxes are meant to compliment and work together, but only under very specific conditions”. It’s bull crap.
it doesn’t take long to figure out the limitations when you hook up a couple boxes together, it is what it is I accepted that ages ago. Except the Octatrack of course that’s different
As long as your master length is divisible by all of your pattern/track lengths, your digis should have no problem receiving pattern change info from your octatrack. I think @jemmons is right about the boxes behaving correctly, it just sounds like use of polyrhythms across dif devices is biting you in the butt
It’s not even poly stuff. I have all my patterns set to CHLemgth at 16 but tracks have different lengths and time divisions. It’s all still normal 4/4 stuff. My master length is always divisible fine, but then I have to wait for that whole cycle.
They work correctly if you set them to the same master length…
Just you run into limits on when you can change patterns and how long polymeters can run
To make sure I am understanding, if Syntakt is synced to OT using song mode and everything is set up to change every 16 steps, but one track on syntakt has a length of 3 steps will it change patterns in sync (after 16 steps)?
Would using longer CHlength times work in your scenario? Set it to something like 128, 256, or x number that is the amount of times you want the 16 bar loop to repeat and send the PC from octatrack early in the pattern. Or are you trying to make quick changes sooner than 16 bars?
Just wondering. Since what jemmons writes isn’t not illogical. Could this pesky problem be down to the simple fact that the DTDNST loop. So. If there was an option to play pattern once and stop, or a Plock that you could place on the last step to command a stop, then external pattern change messages should behave as expected. Though you would have to send the same PC message over and over again for as long as you want it to loop…
i’ve been using a MIDI mouse foot switch to send program change messages to my M:C & previously DT with no issues. I always sent the pattern length and change to the same number, “128” for 8 bars or whatever. I’ve noticed that if i have a four bar cycle that I’ve set to 128 for length and change in the scale menu, I have to hit the program change during the first 4 bars or if it start cycling again before changing.
So to illustrate specifically: if I send a PC message from pattern A1-A2 during the first four bars, it will run through the four bar loop twice before changing, thus anything set to ‘2:2’ trig will happen before the change.
if I send a PC message from pattern A1-A2 during bars four - eight, the pattern with run through bars 1 - 4 again and change after bar 4 is complete.
It definitely throws me off sometimes, but its a limitation i can live with. hope that helps.
edit: I responded to this to agree that I have no issues with PC other than my own timing