Timing

[Drnkhobo]

Something which is bothering me quite a bit in my schm is the sample size. . .

My reasoning is the following:

I want to get a snapshot of one beat using the mono2graph module. . .
So i need to know how many samples to grab every beat. (Fixed cause its a fixed tempo). . .
For that we need to know how long a beat lasts. . .

length of every beat (in seconds) = 60 / bpm

Now we know how long a beat is, we need to get how many samples make up that time. . .

no. of samples in beat length = Sample Rate * length of beat

an example:

bpm = 150
Sample Rate = 44100

Beat length = 60 / 150 = 0.4
Samples in beat length = 44100 * 0.4 = 17640

get me?

So technically it should grab exactly the right amount of samples. . .WRONG!

I tested it at a bpm of 140(host). But set the bpm for the calculations at 150 & it got it spot on!

Seems that the 10 bpm difference made up for it.

Why does this not calculate correctly?

[Nubeat7]

hmm no idea, why this is happening, i usually use this one

[Drnkhobo]

Ah, sorry Nubeat7 must've posted my reply just after yours!

Will check it out now now & see if its better at keeping times. Man I'm excited!!!!!


Will also post about the sync module u just uploaded too

[Drnkhobo]

So the new sync module works pretty good! It doesnt crash the host when you change tempos much but I think its down to the mono2graph trying to grab x samples when x is changing!


The ppq ticker works well (must say its an accomplishment of yours!) but it still drifts slightly. Check the schm:

Test Beat.fsm

(16.28 KiB) Downloaded 1309 times

It seems that even though its accurate its still drifting around the sample start. Its an improvement tho

[billv]

Why is the PPQ module not 100% accurate?

It is accurate, we are probably not using it the right way..??
I'm not really sure weather the actual PPQ module is required, because
it is just a counter....so I'm really starting to think, why should we bother with it all???.
The Ruby ticker is proven accurate, using many different designs.
I hinted at this several times i think in this thread, that maybe the best answer
is to modify the ruby ticker, writing the ppq into the step parameter.

ok i experimented a bit more

I couldn't get a decent result from the "get trigger" module...

ScreenShot223.png (15.2 KiB) Viewed 24301 times

With your previous FSM, I used the Ruby ticker to "deliver" the goods-so I was probably cheating, yeh??

ScreenShot224.png (19.58 KiB) Viewed 24301 times

While i'm here talking about "Ruby ticker accuracy using different designs", here's another one...
This one is based on the "Myco" timer, the timer that the X11 has been running on since day one.
Gets the same wicked result, but offers a slightly different method....might help

Ruby test_0_with PPQ_Myco style.fsm

(37.02 KiB) Downloaded 1333 times

[billv]

modify the ruby ticker, writing the ppq into the step parameter

Further on this...

See this part where the delivery happens...

Code: Select all

output 1,on
output 1,off,t+0.125

We need to have something in there that says
Check if output is allowed via (PPQ code that needs to be "created" or written in somewhere), and then output.
It seems really simple in theory.....perfectly sane and logical to me....
I havn't got the ruby skills at the moment, so only a ruby guru can finish that idea.....
(another good reason for me to keep this issue on a backburner, and work on other stuff...)

I hope I'm wrong, because if I'm right, then DSPR have probably successfully done the same thing, and will
not bail us out cause were so close.

[billv]

havn't got the ruby skills at the moment, so only a ruby guru can finish that idea.

No need for the ruby skills...I created the idea in green and it works.
It uses 2 ruby tickers, and tempo changes are in sync.
And there's no PPQ Module. In short, I've created a small automation circuit,
(in theory similar to the X11 system), to handle that PPQ Sync.
This is the first working version, I've got some more ideas to better it still.
. Maybe a few more tweaks here and there.....

X11 2.01_v3_Timer.fsm

(35.68 KiB) Downloaded 1363 times

[RJHollins]

Working nicely here billv !

[Nubeat7]

@billv:

the problem with your last examples is when you dont start playing on a barstart the position of the notes are always offset -
they do not syncronise to the ppq position, and it also starts playing always from the first position of your seqence, doesnt matter where in the host you start playing -
for example you go to positio 2.3.2.109 in your host and start playing from there, so your sequence will start here which gives you an offset, so it is never ppq position synced when you not start playing exactly on a barstart ( or what ever position is needed to start from depending on the beatfraction you are using)

for test turn off the snap to raster in your host and start from any position somwhere in between the some beats,
so your examples are useful when using a note arp because this should always start on the position where the note starts and not where you are in your host
but not when it should be always synced to the ppq position, like when using stepsequencers or steplfos -

lets say you start on position 1.2.2.0 with a resolution of quaternotes and a four step sequence, the next played note should be the 3rd note of your sequence at position 1.3.1.0, right, so there fore you need an exact position
in this example it would work right - there is just one issue: trogs ppq is precalced and have a delay compensation therefore it always sends a tick at start playing because the first step wouldnd be read because of the precalc - so when you start from somewhere in your host it always sends 1signal at start playing which is not in sync but the second is already synced to the ppq position

[billv]

......in the FSM that your using your ppq setup, with some old work of mine.
None of my other timers were built for PPQ.
V3 is a PPQ timer. Please refer to that with PPQ tests.
please try again using the X11 2.01 v3 timer I just posted, and don't use any other form of PPQ.