Continuing this discussion…
Generally it would be good to settle on a unified approach for clocking in Orac modules. At the very least the clock module should output the beat as a phasor so modules can easily play in time. Dividing the beat into 24 ticks as MIDI clock does is woefully inadequate for expressing anything but the simplest divisions of the beat, so something with a little more resolution is desirable.
I like how Ableton LINK ouputs a beat 0-1 floating point beat phasor, so when I started working on the seqencer_bpm stuff the idea was to use this 0-1 beat phasor to drive everything… But it turned out to be much easier to deal with an integer beat phasor when building patches, so I settled on 360 ticks per beat (numbered 0-359). 360 is nice because it is easily divided, it has a nice ‘circular vibe’, and it is sufficiently high resolution (if it were more ticks it wouldn’t really matter since the scheduler in Pd doesn’t run that fast anyway).
So a module can expect a stream of numbers 0-359 every beat, with 0 at occurring at the top of the beat. This is sent out as ‘beat-clock’. Ticks are not repeated, so if the clock is running slowly, so we don’t see 0, 0, 0, 1, 1, 1, 2, 2, … etc, we always get 0, 1, 2. Ticks are not skipped, so if the clock is running quickly (i.e. ticks are going past faster than the Pd scheduler) we still always see 0, 1, 2. The clock module in the sequence_bpm collection has a [clockfix] object before the ticks are sent out which ensures this behavior, filling in any missing ticks so the modules always see 0-359 exactly. When the clock source is external MIDI (24 ticks per beat), we multiply by 15 to get 360 and [clockfix] fills in the missing numbers, effectively quantizing the beat-clock to 24 segments, but there is nothing we can really do about that…
That is the long answer for why 360 ticks… better resolution, easier patching.