Proper way to divide /multiply tempo in sub patch?

[gurulogic]

I'm looking for an example of how to properly divide or multiply the master tempo into a sub patch that contains for example a Step module that is synchronized to bar. My previous approach was to put a Master Synchro module in the parent patch and feed the tempo outlet into the sub patch, modify the value with math modules and feed the tempo inlet of a Local Synchro module in the sub patch but this does not always seem to work as expected and it was suggested to me that I use the tot ppq instead but I do not understand how to make this work.
As always, thanks for any tips!

[23fx23]

indeed In my case i prefer use PPQ rather than use tempo and bar synchro.

the advantages:

_possible unlimited cycle time.
_whatever loop time ya want.
_strong sync.

if working like this mean the modules won't be set in bar or other sync, but all in 'button sync mode, and we ll contol the position via an absolute way linked to PPQ by directly feeding the stepPosition or position input of module.

then to make the loop time, we use Amod B

let say PPQ goes from 0 to forever 1,2,3.....120...50000 ect.
if you put A mod B where A is PPQ and B is the nb of beats you want in the loop
so if B is 8, result will goes from 0 to 8 then restart from 0 an loop forever.
so with differents B settings can make synced loops of different length.

[gurulogic]

23fx23, are you doing double time here?


btw. I am not sure your last post (s) came through properly? inde?

[23fx23]

yeah i dont'k now why it happens sometimes .. hope im not been hacked,


between im looking for the script i use, make it really easy to get clock, i will post in 5mn

[23fx23]

i found i have two prefered techniques:

_one where you only generate a clock pulse like usine sync modules. (think it's more cpu efficient)
the pulse is linked to the start inlet of module, set to button mode, to make it simple and test to understand:
(but then have to enter loop length in ms then on module then, with ie a tempo to delay conversion, a bit boring)

_the second use probably a tiny more cpu but allow more things and can dynamically swich clock.
it's controlling directly step or pos input of module, via an absolute way.
when using this technique, the pb is often need math braining to convert clocks in steps.
pb is you generally can have different nb of steps/bar in the module than a step/beat. here is a wiring
that match module desired nb_steps/bar, with a precision (refresh speed ratio) .


as i often use this and wanted several clocks (dividers), i made a simple script i often use to make it easier, here it is:

Code: Select all

/////////////////////////////////////////////////////////////////////////////////////
// PPQ Clocks gen_ 23fx2K10_ generate clocks from PPQ, each next one beeing divided by 2
///////////////////////////////////////////////////////////////////////////////////////
// Enter a nb of max bars, that will correspond to the longest cycle (clock0) ie 4bars
// then clock1 will be clock0/2 ie 2 bars ect.
// to match module enter the nbof steps/bar you want. ie if a line module
//   with a 32 step/bar enter 32.
////////////////////////////////////////////////////////////////////////////////////
// parameters declaration
////////////////////////
const NB_CLOCKS = 5; //    nb of clocks output to generate.
/////////////////////////////
var PPQIN, STEPSperbar, MaxBars, SUBDIV: Tparameter;
var CLOCKS : Array of Tparameter;
var i: integer;
var PREC: single;
/////////////////////////////////////////////////////////
// initialisation : create parameters
procedure init;
BEGIN  
PPQIN      := createParam('PPQ IN',PtDataField); setIsOutput(PPQIN,false);
StepsPerBar:= createParam('StepsPerBar',PtDataField); setIsOutput(StepsPerBar,false);
MaxBars    := createParam('Max Bars',PtDatafield); setIsOutput(MaxBars,false);
SUBDIV     := createParam('SUBDIV',PtDatafield); setIsOutput(SUBDIV,false);

  setArrayLength(Clocks,NB_CLOCKS);
   for i:=0 to NB_CLOCKS-1 do begin
   CLOCKS[i]:= CreateParam('Clock'+IntToStr(i),PtDataField); SetIsInput(Clocks[i],false);
   end;

END;//INIT
////////////////////////////////////////////////
// Callback procedure
var A,READSTEP,MODSTEP: integer;
Procedure Callback(N:integer); 
BEGIN

If (n=PPQIn) then begin
   PREC:= MAXS(1,getValue(SUBDIV));
      A:= round(getValue(stepsPerBar));
         for i:= 0 to NB_Clocks-1 do begin
             READSTEP:= round(getValue(PPQIN)*PREC*(A/4));
             MODSTEP:= round((getvalue(maxBars)*(A)*PREC) / power(2,i));
     SetValue(Clocks[i],(READSTEP mod MODSTEP)/PREC);
         end;
  end;

END;//Callback
////////////////////////////////////////////////////

It picks total PPQin, then if enter nb of maxbars and nb of steps per bar (ie want a line steps of 32 steps per bar) of 4bars
for longest loop, it will generate a step clock0 matching, then clock1 will be divided by2 ect (2bars).
can adjust also the reading precision (refresh speed/precision of clock).

i use this and send clocks to busses, then the modules getbuss coresponding can dynamically change with the listbox bus name trick.
quite handy, also here it's only binary, need to find time to make a more modular...
maybe can be useful for ya too

[gurulogic]

Ok thanks, I will try these examples. I did try with the script but for whatever reason I am having trouble when testing with a step module....more to think about.
Is the LocalSync module kind of reduntant then if it is better to directly control step position of a module? One thing that I thought the LocalSync module would be great for is running VST's at a different tempo than the master tempo but this doesn't seem to work so I assume that the LocalSync is not intended to be able to override tempo for VST's?

[23fx23]

try to make a 16 step module, on the script input set steps/bar to 16, prec to 1, and nb_bars to 1.
now if you put the module on "button" syncro and connect the clock0 out of script to step pos of module that should work?

in fact i forgot the much simpler technique of local sync also, yes if the module is set to bar can have various clocks using
local sync. don't remember exactly why i wanted to complexify things ...!! think because at some point need to access
arrays datas, not modules and enter a float nb of beats, not playing with cycle/bar duration of sync module.

Localsync can have a different tempo linked or not to master, and outputs leds clocks, and can have a start cycle different of master sync. so that's cool. in a case like here where want several lanes with different clocks, have to put a local sync for
each module, but that's may still be lighter in cpu that bus feeding steps all things considered... Also the mod technique eventually add a step offset possibility or a dynamic swicthing read clock,

don't know about vst, yes they are probably linked to mastersync for sequencer or other reason.s.