ok, is this the same master-metronome patch used by pd_grids?
basically Ive updated that patch, so perhaps you can just take as is?
did a quick test… with pd_grid/pd_grid_link, same pattern/tempo etc
a) pd_grid was showing 11%
b) pd_grid_link, connected, but with 0 other clients - 14%
c) pd_grid_link, connected, with 1 other client 17%
now, in fairness b) is a bit unfair, as basically the code is then running 2 internal clocks/sequencing - the link one, and the one that previously existed … we could strip this back to just having the link one, I guess this will save us a few %. (1-3?)
(I left it in since, I wanted to test that the tempo timing was identical between the old code and the new code)
so yes a penalty, the cost to process the incoming UDP packets.
(hmm, what i didnt test, but really we should … is comparing this to midi clock … as obviously that also has some overheard too … also these cpu readings are very crude )
yeah this is confusing …and I’m not sure i can easily explain it
basically quantum = 4 , means 1/4 notes quantisation , resolution is how to sub divide this… (assuming 1 bar quantisation)
so 1 = 4 steps of 1/4 notes , 2 = 8 steps of 1/8 notes 8 = 32 steps of 1/32
whats important about this, for patch design, is that patches really want two things (to work well)
a) tempo , like metro
b) step number
the later is important to keep patterns in sync, e.g. they may want to sync at pattern starts.
of course, how they choose to do this, is largely up to them.
Im not sure, Id need to hear this with a steady beat… i didnt notice anything very obviously wrong… and I think because I used the step output, which basically just waits for phase to catch up.
(the idea though, is with phase, you can choose to do something different… I guess there are more complex/thorough ways to deal with this eventuality )