Clock Sync Strategy for special kind of step sequencer // link working now
Hi guys,
i had an idea for a special step sequencer and face problems to implement the clock sync. I'd kindly ask you to switch over to my blog where i described the problem with better formating available than here.
EDIT: This link is working
https://karlchenscoderdasein.blogspot.com/2020/10/oddy-sequencer-maxforlive-device.html
I hope my problem is clearly defined. Can you define how such a strategy for syncing the clock could work? Please be sure to read the post carefully, the problem is not syncing the clock in a common step sequencer concept, but the problem is caused by the requirements "switch patternfragment immediately" and "disable pattern sync" and "support tripplets and dotted notes".
Maybe the problem is some kind of academic, because i think for a quite long runtime the timers and the sync will be adequate and there still is the pattern sync which will force sync frequently, just for musical reasons. But i wanna do it perfect, so the sequencer should sync to the master clock frequently to avoid inacuracy caused by the subtimers and the delay when starting the msp-delay caused by the runtime of the sequencer. The problem is how to find the points when the step sequencer can sync to master clock without breaking definition of the sequences.
Thanks a lot in advance.
i already stuck at the attempt to edit your blog post. ;)
lol. please stay focused :D
but how when your link doesnt work.
I believe that what Roman is wryly trying to tell you is that the link doesn't work.
What max said
oooo sorry. i didnt get this. i see i took the edit link by accident. i thought roman tried to hack my account :p
it was late yesterday. ;) i replaced the link in the original post...
i hacked his account before, that´s why he posted the wrong link, but shhht about that, guys.
so, after reading it i must say i dont fully get the point... but that´s probaby not your fault... is the main issue about when to switch to another tempo?
the basic principle is easy:
at a speed change (or any other "sequencer row" or "pattern" change) you either use the last active step , or the last possible step, or the last possible step+1step as trigger for the next pattern.
my chaincount module f.e. does the latter.
and i would say that if you also allow triplets (by adding a ratchet function to the main 1,2,3, counter?) you will not come around to strictly distinguish bewtenn the clock data and the output data, the pattern can be as free as you want - but the switches to other patterns may only happen controlled by the 1/16 clock.
if you need to "resync" stuff later, you must calculate in advance how long a pattern will be in relation to the oringal clock you started from.
is that what you want?
Hm maybe the question is how to do the tick-generator at all.
i do it like this, that i start a timer when the transport changes to active. (time t1)
Then the sequencer calculates everything. This takes some amount of time. When it has determined after which delay the next tick comes, it starts the next delay. (at time t2)
Now we have a time jitter of t2-t1. [1] which results in a inacuracy of the sequencer if not treated.
This is why is sync my "simple step sequencer" to bar changes of the main transport. In this case the time built up through this inacuracy will be cleared on each bar to be exact again. But in this "new" sequencer concept, it's not for sure that the next tick can be synced to the barcount change of the transport object. I need to find another way to do it.
[1] I did a calculation: If the jitter time t2-t1 is just 100 microsconds, (Which is not too much for max i guess) then the delay will become audible after 20.000.000/100 = 200.000 ticks. (20ms is the delay where human ear detects two transients) If you set a tempo of 1/128 this would happen after 200.000 /128 = ~1563 bars. At a tempo of 130 bpm this would happen after about 48 minutes of live jamming. I guess that is acceptable? (i made various errors in calculating i hope its correct now :p still 100us is a guess.)
So maybe it's ok to just ignore this inaccuracy. Still i miss some kind of QuantizedClock object in max. It would make the thing more easy and would allow to encapsulate fixing the problem of this inaccuracy...
your image looks familar. i think this is what i need.
So i dont see the meaning of the connections but if that means, that the second chain count starts when the first chain count is done, this is exactly what i want.
this is one of many ways how to build it, among other things i have a all-in-one-module - and this here is the most "modular" version you can have (it´ll allow branches and loops)
it is very simple code, yet it was quite a brainfuck to make up the idea for the very first time back in 1907.
you set thing A to count to 5 at 120 bpm and thing B to count to 10 at 150 bpm.
if you now give the instruction "first play A then B", thing A starts counting from 1 to 6, but the 6 is sent out another outlet and triggers B. (resulting in an immediate output of "1")
in your case, you could also count something else for A in foreground and the 1-6 is only used in background to find the right moment to trigger B.
there were various [transport] vs. custom clock threads here while you were absent, with solutions/suggestions/opinions for both.
you dont really need to resync T2 to the main clock. you can just make everything dependent on the main clock if required. or restart the main clock from the last exceptional subclock.
(yes i know, max4live context)
hi roman, thanks for your answer, yes this sounds quite similar to what i did / plan to do. just office is catching all my time at the moment. i spent on one (sic) bug almost the last two weeks together with up to 4 collegues and the rest of my engergy is spent for making music. ;) i almost forgot about the step sequencer project haha. but maybe i will finish it some day, then read the other clock-topics and check your patcher.