@CCMP for me it works without a problem
If it works for you, great.
Maybe we’re not talking about the same level of sync control though, because it’s far from straight forward.
I just noticed another post on another thread here though that seems like it could be a solution to getting the PC messages sent early enough to the slave devices.
This is for the Digitakt, but same should/could go for the Digitone;
Don’t need all of that just to sync the 3 boxes though.
There’s a sync option in the system settings you do stuff in. I just needed to have all 3 boxes change patterns at the same time and it wasn’t working. I found the problem was that the pattern i was changing too had different length and stuff under func+page menu. Once I set all my patterns to the same info, it changed fine
I hear ya, I’ve been there too, then it’s stopped working consistently.
I’m not being a dk or beating on Elektron here, it just is what it is… it’s never worked consistently for me in that way.
If it works for you, cool.
Do me a favour though, report back here if/when they start losing sync. (Usually it’ll be one unit starts changing a bar late).
Hey I had it working inconsistently for me just now and I was looking for a solution, but I couldn’t find it here (maybe this solution is already documented somewhere, but I couldn’t find it). So I just dug a little deeper into what @Brockstar said about the page parameters. I found out that the problem starts when I enable length per track. Specifically, if I put the master length on infinite on the box that needs to follow the other box, it will start changing program one bar too late. But if I put it on 16, 32 or however long the pattern actually is, it changes in time. (but of course with 32 it might be late if the 32 hasn’t completed yet). The page parameters do not need to be the same between the boxes and ch. length can be off or whatever. The only thing that seems to matter (for me) is if master length is set to infinite on the box that receives the program changes.
For what it’s worth, I discovered pretty much the same thing when attempting to sync M:S <-> M:C,
Interesting. I wonder if it’s a bug or if it’s intended behavior somehow.
I pretty sure it’s very deliberate, whatever the motivation. I’ve seen (somewhere in the many threads on this topic) detailed feedback from Elektron support about why PC works “within the Elektron ecosystem” but no guarantees about what happens elsewhere.
The fact that it doesn’t work with varied track lengths on at least two machines suggests it’s coded not to accept program change when it’s ambiguous where the pattern ‘ends’ (starts to repeat exactly).
EDIT: Link to Elektron feedback on PC.
It does work with varied track lengths though. It only doesn’t work if master length is set to infinite. And if that is the case it does in fact change, just one bar too late. Beyond that the tracks can be as different, but of course if one is set to 32 and the master to 16, you’ll need to align the changes properly yourself, but that at least makes perfect sense. I wonder what about infinite master track length makes it so that it changes one bar too late
Aah … I can’t explore that on my setup (M:C/M:S only, the master option is not there). I’ll doubtless read some more though.
On the M:S/M:C, when when the receiver track lengths do not match (mode=TRK) then the change happens one bar late, same as your setup when set to ‘infinite’.
hi all, is it possible to connect syntakt and digitakt and one of them always changes pattern for both? or would i do that via one of the digitakt’s midi channels …
Yes, with Program Change, Clock, Transport SEND activated in MIDI SYNC for the master sequencer, and Program Change, Clock, Transport RECEIVE for the slave sequencer.
In that case, patterns have the same number. If you want to load patterns independently you can use midi tracks Program Changes…
thanks a lot!
Just to summarise if I have understood everything correctly:
to have a good sync between the 3 boxes, you need to have the two boxes that receive the program change in “per pattern” mode and you can afford to have the machine that sends the program change in “per track” mode.
It’s a pity … we can’t take advantage of a different scale per track anymore?
Ok I just figured out how to do it: just set all boxes to “per track” and set CH.LEN to OFF.
In fact you can set the master to for example CH.LEN 64 as long as the slaves are set to CH.LEN OFF.
Sorry for the flood, but maybe it will help other people.
Good music to everyone. Enjoy life.
So 5 mins ago i had same issue as all of you here…
it works, then you enable TRK lenght and youre done, the problem is here…
then i thought i found a “how to” and then it didnt worked when i wanted to confirm it…
now it seems to work when CH.len and M.len are same…
Tomorow i will test it again, because all my patterns are polyrhytmic…
so this will be essential for me to work properly…
no matter what polyrhytms you have in patterns, on boths machines you need to have ch.len and m.len same number
Thanks for checking and reporting. I’m running into the same issues, especially when DT is receiving pattern change messages from ST. I’ll try keeping CH.LEN and M.LEN the same
I feel like there may be a bug… But its probably not… I just dont understand it right
-once you introduce M. LEN INF and also you have any TRK set as non 16/16, then things start to break down…
Master box pattern is 64/64 only… So change is always after 64
Slave box has one or more TRK which is not 16/16
M.Len is INF
CH.Len is 64
I change pattern to A2
Change happens off sync…
-it seems like when M.len is not introduced it gives priority to that non 16/16 trk
-the change always came late, next pattern, or maybe page length?.. But it was always after the master box was already playing the A2.
What will i try to understand today is
-if theres no M.len but there is CH.len… When is the CH.len countdown started in relation to “when i change patterns”…
*i will also go and read manual, as i never really used pattern change via midi, and so i have no idea if the manual explains this logic…
anyways ill come back and share my findings