pattern length is mirroring the octatrack. im sorry im unsure what you mean by change value? thanks
The RYTM Pattern has a parameter called Change (CHG) if you are in Pattern Advanced Mode
1 Like
up until now change has been off. what should it be set to?
Iām not sure how that reacts to program change messages, I was just trying to get more info on your settings so @Olle can answer.
Hmm, is it that you use the MIDI sequencer on the Octatrack to send out program changes to the Rytm? In that case you are not doing it right. Skip the MIDI sequencer completely, itās not needed.
What you have to do is in the Octatrack Project -> MIDI - Sync set the Program Change Send to for example Ch 15.
Then on the Rytm Global -> MIDI -> Channels set the Program Change Receive to the same, 15.
Make sure that in Rytm Global -> MIDI -> Sync Program Change receive is ON.
Now when you change pattern on the Octatrack the pattern on the Rytm will Cue and they will change pattern at the same time when the pattern has ended.
Why this works is that in this mode the Octatrack will send the Program Change in advance as MIDI is not instant. Using the MIDI sequencer the Program Change will be sent on the actual pattern change but since it takes time for MIDI, the pattern on the Rytm has already started playing as it doesnāt know about the program change it has not received yet.
6 Likes
thank you Olle! this is working as I hoped it would when I ordered it. loving the sound of the rytm 
3 Likes
olle, im trying exactly the same on analog 4 and digitone and it doesnt work when i have advanced pattern length on on the target machines. the octatrack seems to send the message still to late so the other machines cant react in time. tried to send the prgm ch commands from ableton with a -300 ms track delay and everything works fine. But not if im sending from Octa. Rarely it works, but not constantly.
Tried everything, fresh proejcts, midi settings, all kind of stuff. i literally spend days on this. of corse all machines have their ch. lgh on 16 steps.
You are correct, that will sometimes not work. When you use 2x or 1/2 or individual lengths all kinds of conceptual issues will emerge. Remember, you are trying to sync two units with different clock and sequencer running att different clock divisions and length.
1 Like
but thats not the case. im just using normal time signatures 
im just having basically some tracks on 16 steps and some on 64
What do you mean with advance then?
having different lenghts per track . i.e. 16 steps or 64 or sometimes polyrhytmic stuff
You say itās inconsistent. Isnāt it just that you are not triggering the pattern change on a bar that is in the middle of the pattern cycle? It can be hard to determine where in the pattern cycle you are on the receiving unit when using different track lengths.
1 Like
i was investiagating this already as i suspecetd it to be the problem. anywayā¦ as far as i can remember i couldnt find a pattern (in means of inconsistency) hereā¦ also by pressing double stop it should reset all the clocks resulting in at least doing the first pattern change right, which was not the case.
However i could investigate more if thats somehow the issue.
However i dont get it conceptionally. If i set the Chng lengh on 16 steps on all patterns on all machines, that means every 16 steps it should make a jump to the next pattern, if it received a prgm ch in the meantime, regardless which page the single tracks are on right now. its just a global division of a internal counter starting with the moment you start the machines.
which leaves me with the feeling that the issue is only, that the change commands are send too late from the octa. because i tried the same with external commands and it worked fine (on all machines). which tells me that the ch. lenght indeed works as intended. these commands were send -300 ms before the pattern should change, and this always worked as expected, with the weirdest polyrhythms. sending it a little bit later eg -200ms the behavior was exactly like when sending the commands from octa, meaning it went for another round.
ok i did investigate further. i does indeed has something to do with the cycle its currently in. but the funny thing: regardless of what the master track lenght, the change lengh, the individual pattern lenghts are set to:
a correct pattern change will only occur if i change in the cycle 48 - 64 steps.
So only after exact 4 bars it will change correct (which brings me to the idea that it might work with all ch. lngh set to 64?). and this is even my master pattern lengh is set to 16 
and the individual tracks to 48. ch lngh 16 . nowhere i have the 64 set.
This makes all no sense whatsoever. i think the reaction to a pattern change command should be exactly the same than changing the patter by a manual button press. and as manual pattern change works perfectly fine, and you never have to wait another round for it to change, the only left explanation is buggy programming .
You know what ?
After submitting a ticket to the support regarding this issue,Iāve been answered that midi wasnāt able to loo into the future as a first replyā¦
I always enjoy being taken seriouslyā¦
After several exchanges, which proved that I was at least half aware, of what is midi and how it is supposed to workā¦
I had to ask the ultimate question : Why MnM, MD, A4 and AK have a feature that makes them switch patterns instantly by using midi notes ? ( Along : Do their midi implementation see the future ? Why the other boxes did not get that ? Is this feature does not invalidate the whole argument of midi protocol being so bad ? Why not make the user choose if the latency between a message and is execution is acceptable or not instead of forcing two steps delay ? )
I then, got the most honest reply of the whole conversation :
āItās not a simple question to answer as there are a lot of reasons some features end up in some units and not in others. The subject is too big to be discussed here, but it includes resources, bugs, design decisions, conceptual clashes and politics.ā
I let you make your own opinion on what this really meansā¦My ticket is still openā¦
1 Like
quite a honest answer you got. i also had to diskuss quite a lot until they admitted its a problem.
while i can understand that instant pattern switch might be an issue if not implemented from the ground up, for this behavior there isnāt much excuse.
the easy solution would be:
just make the octatrack send the PC command at the same time you press the button. Not at the end of the patternā¦
This way, if all machines are on same ch. lngh. it should work everytime.
or if thats not possible, make it a bit earlier. it seems to be to late.
at least thats the conclusion from my tests. shouldnt be super hard to implement one would think.
1 Like
You are not talking about the same issue and itās not the same thing at all. That functionality triggers a pattern, not cueing it. They do that with latency causing them to go out of sync. It works fine when playing it manually since you donāt need to be that precise. But not if you plan to sequence them that way and expect them to be in sync with another sequencer.
I already admitted that there are issues:
Most of these issues are conceptual and will be there, work around them.
Then it might arrive early instead as the unit has no idea what the receiving sequencer is at in its sequence. It sends it as late as possible but early to avoid this. How would chains and the arranger solve this? When are they pressing the button. There are so many cases that you really have to make these kinds of compromises. They can absolutely be tuned, but donāt expect them to work flawlessly in all use cases as they are compromises. Itās not at all as simple as you try to make it seem. The units do this fine in most of the cases.
2 Likes
i do understand why its done this way. because a sequencer which actually changes instantly whould need it to be send on the switch.
unfortunately your own products dont work this way. they need it in advance, and if its just a bit. and if they are on the same ch. lngh its all fine.
thats how i send the commands from ableton and it works everytime.
your argument with the arranger is totally valid thoughā¦ but its a different use case.
ok then make the octa send the change some millisecs earlier please ā¦
the units dont do fineā¦ the only way i find that it actually works is if im only using 16 step sequences. that cant be the solution, right?
1 Like
thought about it again and from my tests yesterday it seems that the octa is just sending the command on time, when itself is on the end of its pattern, eg 64 steps. if it changes early because of its ch.lngh set to 16 (what i always have) it failsā¦
cant wait to try
edit: tried and doesnāt work again. sometimes it does, sometimes notā¦ i dont get it.
Iām not saying that patterns by midi note is the same thing, Iām just saying that this features works as almost every user expect it to work. This feature should have make it to every other box !
Iāll continue to dedicate one track of my pyramid exclusively for elektron boxes because they are the only hardware I ever owned which canāt handle program changes the way it 's expectedā¦
I work around, like you saidā¦