And here is the solution:
A fully functional MIDI clock that bypasses the need for sync~ object,
thus freeing oodles of processing power. Assumption precludes that one
does not need sample accurate timing naturally.
Note the second tier counter which is used to position new counter heads
in correct ratio to received clock. Without this you cant change clock
divisions in real time and loose the "1" of the beat. It's purpose is to
retain your relative position in time,
Hope someone will find this useful
I'm trying to extract from rtin the ticks so I can create a clock for
use in non-audio patches. I know how to create clock via phasor~ but I
would prefer to have clock information on the data path instead of on
the audio path. This primarily because i want to clock 80 different
modules together and if I use audio paths the processor just goes
"clunk". I figure if I can extract a metro/counter from the rtin, then I
have what I need to map my sequencers and LFO's.
here is my example patch with the clock on the data path vs. signal
path; I kinda feel like I am "hacking" at it with a hammer. As you can
see there is a weird inconsistency in the clock rates from both paths -
and I can't tell why it occurs - could someone help me to understand how
I could extract '248' messages and make them into an accurate metro or
counter? I would be most grateful.
Or am I forced to use the signal path? If so, what would be a smart way
to get clock, and divide it into segments for all my sub modules without
creating dozens of signal connections?
Haven't found anything directly helpful on this subject in the archives:
thanks in advance,