PPQ from DAW: understand the value and trigger somethings

[bitwise]

With 3583 we are lucky and it works, but take this example, when DAW send to me the 4° clock: it should be 0,041667 in ppq (91,875*4=367,5; 367,5*1/8820). But DAW send to me rounded value (368), which is 0,0417234 in ppq.

So in which sample do you expect the clock, in 367 or 368?

368 of course Even because I receive only 368 (0,0417234) from DAW. But if I compare prev tick (0,0417234 - 1/8820) the error of that one (even if I never got it) is smaller, and the control fails. But I don't know if I or I don't get that tick, that's why at each tick I think I need to check prev and next.

It should be 367. You can't expect the clock to go hand in hand with multiples of 92 if its period is 91.875.

[Nowhk]

It should be 367. You can't expect the clock to go hand in hand with multiples of 92 if its period is 91.875.

91.875 is not "integer". Thus its multiples. DAW can't send to me float values since samples are expressed in "int". In any case there's approximation. In case of FL Studio its 368 because of Banker's rounding.

I guess there is a "unique" way to get "when I am into a pulse" due to provided ppq value by DAW. Isn't?

I think we shouldn't think in "samples", but just in PPQ, which is derivated samples (already rounded).
But I'm going crazy to get this "algorithm". Its going to ruin my life

[bitwise]

It should be 367. You can't expect the clock to go hand in hand with multiples of 92 if its period is 91.875.

91.875 is not "integer". Thus its multiples. DAW can't send to me float values since samples are expressed in "int". In any case there's approximation. In case of FL Studio its 368 because of Banker's rounding.

I guess there is a "unique" way to get "when I am into a pulse" due to provided ppq value by DAW. Isn't?

I think we shouldn't think in "samples", but just in PPQ, which is derivated samples (already rounded).
But I'm going crazy to get this "algorithm". Its going to ruin my life

I created this function. It seems to work, even though i didn't check if the clock positions are right:

Code: Select all

q = 1 / 96;
k = 96 / 8820;

function detect_clock(sample_pos, ppq_pos)
    
    t1 = pos_ppq / q;
    f = t1 - int(t1);
    e = min(f, 1 - f);
    
    if e < k / 2 then
        ck = 1;
    else
        ck = 0;    
    end
    
    disp([sample_pos, ppq_pos, t1, e, ck]);

endfunction

[Nowhk]

I created this function. It seems to work, even though i didn't check if the clock positions are right:

Code: Select all

q = 1 / 96;
k = 96 / 8820;

function detect_clock(sample_pos, ppq_pos)
    
    t1 = pos_ppq / q;
    f = t1 - int(t1);
    e = min(f, 1 - f);
    
    if e < k / 2 then
        ck = 1;
    else
        ck = 0;    
    end
    
    disp([sample_pos, ppq_pos, t1, e, ck]);

endfunction

If you test this function in FL Studio, it will fails for some values. I've recreated it in C++: http://cpp.sh/6otj
As you can see, it will consider 0.0417234 (368) as "not pulse". When in fact it is

[bitwise]

If you test this function in FL Studio, it will fails for some values. I've recreated it in C++: http://cpp.sh/6otj
As you can see, it will consider 0.0417234 (368) as "not pulse". When in fact it is

367 "is pulse"

[Nowhk]

367 "is pulse"

No man Or better: it depends. 91,875 * 4 = 367,5.

If it approx using floor, you are right, and you will get 0,041610 (367).
If it approx using Round to even, you are wrong, and you will get 0,0417234 (368).

[bitwise]

367 "is pulse"

No man Or better: it depends. 91,875 * 4 = 367,5.

If it approx using floor, you are right, and you will get 0,041610 (367).
If it approx using Round to even, you are wrong, and you will get 0,0417234 (368).

367 and 368 are just one sample apart, it doesn't make much difference. But as the sample count rises, the gap between the real tick position and n * 92 becomes more obvious. What is important is that you don't detect two consecutive ticks in place of one.

[Nowhk]

367 "is pulse"

No man Or better: it depends. 91,875 * 4 = 367,5.

If it approx using floor, you are right, and you will get 0,041610 (367).
If it approx using Round to even, you are wrong, and you will get 0,0417234 (368).

367 and 368 are just one sample apart, it doesn't make much difference. But as the sample count rises, the gap between the real tick position and n * 92 becomes more obvious. What is important is that you don't detect two consecutive ticks in place of one.

Sure. That's wont happens. But 1 samples apart make huge differences when I'm doing some null test between my output and DAW output. That's my trouble...

[bitwise]

Sure. That's wont happens. But 1 samples apart make huge differences when I'm doing some null test between my output and DAW output. That's my trouble...

It could depend on something else. Do you update the buffer or generate an external signal?

[Nowhk]

Sure. That's wont happens. But 1 samples apart make huge differences when I'm doing some null test between my output and DAW output. That's my trouble...

It could depend on something else. Do you update the buffer or generate an external signal?

No man Its exactly this the problem. I made a log on "when" the pulse is reckon (which will output a note on that buffer). FL studio handle MIDI received from VST at the buffer when I send it. And it assure that every 1/96 beat it send the buffer.

But my "1/96" of buffer is 368, not 367 (as yours). Because its Round to even as rounding, not floor.

[bitwise]

No man Its exactly this the problem. I made a log on "when" the pulse is reckon (which will output a note on that buffer). FL studio handle MIDI received from VST at the buffer when I send it. And it assure that every 1/96 beat it send the buffer.

But my "1/96" of buffer is 368, not 367 (as yours). Because its Round to even as rounding, not floor.

I suppose you are sending midi messages. But audio data and midi messages follow different paths, so i guess you might incur in some delay.