Why I'm not able to stay in sync with DAW using stream/blue?

[Nowhk]

i don't know what you mean, ppq is pulses per quarter and should show always the actual playposition in pulses (or ticks) per quarter, so it has nothing to do with the speed at all it just shows the actual playposition in your song..

I mean, even if I use PPQ prim (that is more accurate/sync) instead of my own counter, when I change BPM tempo in FL Studio (with mouse, quickly, for example) and I link the counter to a visual step progression (or a Mono Readout, and watch it at slow BPM counter) I can cleary see that the position of FL Studio cursor is different than the value I'm watching. Also: using PPQ, when changing the Tempo, it moves my cursor back/ahead (which I won't).
P.S. It starts when DAW start, it is not always running.
Here you can see, with your code:

Sequencer_PPQ_Nubeat7.fsm

(1.88 KiB) Downloaded 1055 times

This because it seems that FL Studio compensate/slightly change position in a uncommon way. So that's what I mean I'm not able to sync it. I guess it's a things that I can't manage from FlowStone, so I need to live with it. Right?

That's why I'm thinking to not use Time Signature for speed, but Hz (0.5Hz to 50Hz should be enough). I will have the same problem on not having perfect sync with the Hz value and the actual reading speed (because of rounding error as for the Time Signature), but at least visually there is no comparison, so no noticeable artifacts (and more range of values to use):

Code: Select all

streamin isPlaying;
streamin hz; // from 0.5 to 50
streamin samplerate;
streamout index;

float i;

// reset
index=(isPlaying>0)&(index);
i=(isPlaying>0)&(i+hz);

// counter
index=index+(i>=samplerate)&1;
i=i-(i>=samplerate)&(samplerate);


This should be always in sync with the Hz I set.

[Nubeat7]

it really depends for what you need it, specially in fl people normally don't start to play somewhere between beats, so a free running sync maybe would be enough, the small rounding errors would have to been tested, if it doesn't matter in a 5 min song its fine, if it is used for liveacting where you press start and play 1 h without stop in between it can be really bad... also fast tempochanges are not so common, you need to choose..

[Nowhk]

the small rounding errors would have to been tested, if it doesn't matter in a 5 min song its fine

The problem is that PPQ reset at every pattern restart (which I don't want; the step/beat counter must be cumulative, so I wrote my own code). But with my "bad" code (uploaded as first post in the topic), after 2/3 bars I can already see it is not sync anymore with the FL current position/cursor. So rounding errors are huge there. I don't think math is wrong; maybe can be improved, but for this easy task FlowStone is able to do these operations in time

also fast tempochanges are not so common, you need to choose..

Yes. But even if I do a small tempo change, PPQ prim "compensate", and my cursor jump back; so instead of decelerate (as FL Studio cursor does), PPQ prim set a back value. i.e. if I'm at 3.34534 and I slow down, it could jump to 0.42322 for example, which mess my cursor progression.

[Nubeat7]

Yes. But even if I do a small tempo change, PPQ prim "compensate", and my cursor jump back; so instead of decelerate (as FL Studio cursor does), PPQ prim set a back value. i.e. if I'm at 3.34534 and I slow down, it could jump to 0.42322 for example, which mess my cursor progression.

so ppq jumps while the "real" playposition changes smoothly?
thats bad, sounds like a classic fl behaviour

the only way i could think of, is to set a flag while tempo is changing to activate a dezipper to the ppq, like this you would avoid jumps but it will be difficult to keep it in sync with the real playposition while tempochanges,

this would maybe help at rarely tempojumps but not at smooth tempochanges..
maybe ask also in the fl studio forum how to solve this issue

[Nowhk]

so ppq jumps while the "real" playposition changes smoothly?

It scale accordly to the actual position of the beat. If I have 2 bar, 120 BPM. At the end of first bar, the PPQ value is 4. If, at that same point (end of bar 1), I halve the BPM (60), PPQ back to 2 (which is the beat if I had use 60bpm from the beginning). This make sense, but its messy (especially if you want a cumulative PPQ).

Note apart (related to this): I don't understand how PPQ (coming from FL) could be "perfect" since it is float (so with some rounding error). Even if double, there will be always some rounding errors. I don't talk about FlowStone here, but inside the DAWs itself: is there a more sophisticated method to get precise counter? Or there will always be some rounding errors (even within a DAW) at keeping the tempo sync to the "real" world?

the only way i could think of, is to set a flag while tempo is changing to activate a dezipper to the ppq, like this you would avoid jumps but it will be difficult to keep it in sync with the real playposition while tempochanges,

Yes. Even because FL cursors (when I edit tempo) also change with a slight movement back/forward (a sort of auto compensation; I don't know). I will never know this smooth value, so having the two cursors sync will be somethings impossible I think. Until this won't be necessary for me, I'll stay in Hz domain (and maybe implement Linear Interpolation for the integer/read point, keeping the curve as linear as possible with different ratio).

[Nubeat7]

just had soem tests in cubase, the jump back what you described also happens there when changing the tempo manually, but its different when you automate the tempo with a tempo channel then it stays at the actual position and just gets slower or faster without any jumps...

here is a little video how smooth it works with cubase and automated tempo...

[Nowhk]

but its different when you automate the tempo with a tempo channel then it stays at the actual position and just gets slower or faster without any jumps...

Not in FL Studio. It jumps even with automations. No way, I keep in Hz Thanks!

[Nubeat7]

hmm, strange.. finally i found the time to do some tests in fl studio too.
i'm using my vst effect dizztroy2 which has an envelope generator with a resolution of 512 points (interlopated)

it seems that it is running very well also at dramatically fast and big tempochanges, no big jumps!
it just looks that its sometimes a little bit out of sync but thats minimal, maybe its just the update rate for the cursor which is a 100 tick/4 (so less than 30 ticks/sec) but all works pretty smooth..

here is a small video for demonstration..

[Nowhk]

it seems that it is running very well also at dramatically fast and big tempochanges, no big jumps!

Not here. Maybe its FL 12? Here you can see the PPQ prim how reacts when changing BPM with automation (the same is manually, with mouse): http://www.fastswf.com/PM2bwDY

[Nubeat7]

yes but i see no probblem there, because its still in perfect sync, just at halfspeed, so you are at half of the road at this speed, at 4 instead of 8. And the modulus (of 4) is 0 in both cases, that is what my module does to keep it always in sync, did you tested the stepseq too? the only thing you need to take care is to set the fl flag when using different timesignatures then 4/4...