DSP Robotics Support

ok so tested PPQ Timer V3

from what I can see, there is still a variation of the timing. Now that is based off my scope grabbing samples.
Surely it should grab each beat at the same time? So there should be NO variation?

So A kick on every beat and the scope changes from

to

as you can see slight variations. Always changing.

Now lets see only one kick on the first beat . . . (snapshot taken on 2nd beat)

This shows a few samples are shifted around the synced ticker. Its not 100% but I cant think of why it would be shifting like this if it was. Also the delay in grabbing samples from PPQ ticker is around one beat.

Im not sure how your PPQ works on the inside billv so I dont know where to look (is there a buffer?)

RJHollins wrote:Working nicely here

Cheers mate. good to hear.

Drnkhobo wrote:Now that is based off my scope grabbing samples

I'm not sure about this method.......using the graph + calculating the sample...
Are you still using that damn "Tick 25" for the re-draw??????
Remove all windows timers from your test fsm. Feed the tick in for the redraw.
Upload new fsm if still not happy with results.
Not sure about the graph method, but will give it a try.
I do all timing testing in host. I still can't generate an error with v3.
Maybe try this mate, to see it from another angle.
Make vst from v3, change tempos as much as you want, and check results.
Then add your graph to v3, make a new vst, compare the graph against the host.

Are you still using that damn "Tick 25" for the re-draw??????

Hahahahahaahahahahaha! No , no im not anymore!

I tried it with the beat ticker triggering the redraw. . . same results. although slightly better.

I'm not sure about this method.......using the graph + calculating the sample...

Well you see all I want is to get a display of one beat , every beat. So if tempo changes so does the beat length. I need a variable sample size & I tried to make sure the mono2graph doesnt grab a sample as the no. of samples changes.

I do all timing testing in host. I still can't generate an error with v3.

Im glad its working for you !!!

Like I said it might be the way im doing things but I cant seem to get my scope sorted.

Drnkhobo wrote:all I want is to get a display of one beat , every beat

Ok, that makes me see your objective a bit better.

Drnkhobo wrote:sample as the no. of samples changes.

I noticed this when i mucked around with your fsm.
I fed it a single value of 44100, I think that gave one beat, everybeat.
And I did notice a slight variation in each beat that was displayed.
I couldn't explain it at the time so i put it down to the "graph method".

Got lots of old scopes, in my SM Toolbox. Will see what some
of the options are with scopes/graphs/analizers......

Thanks for the fresh fsm.....will check out tomorrow....

Got lots of old scopes, in my SM Toolbox. Will see what some
of the options are with scopes/graphs/analizers......

Nice! Look forward to it but dont they all rely on the stock mono2float component? Thats why its basic in my fsm, to see if it works with the bare minimum components. . .

anyway, thanks for your help so far man, appreciated!

Drnkhobo wrote:Look forward to it

Hey man, I think , maybe you were using the wrong tick. Host tick works a little sweeter.
Re-worked the fsm a little to test more stuff, this is what i got so far.

One irritating thing.....
Are these samples being displayed at schematic grid equivilant???
There's no background markings to "gauge" things from...know what i mean??

Also, I don't think there's anything wrong with the mono to float stock componant. i used it in
the Myco timer I just put up a few posts ago, and the FL timer versions. All were spot on.
Its behaviour is defined by the tick feeding into it.

Thanks Billv!

Hey man, I think , maybe you were using the wrong tick. Host tick works a little sweeter.

Whats the difference?
Is 'tick' calculated by Ruby as a estimated value (based on a timer) & 'host tick' is calculated from PPQ?
Or am I way off ?

As far as testing goes:

Using 'Host tick' grabs every 8th or 16th. . . its quite fast & not every beat. . .

So tempo tick does it correctly. Maybe a division of the 'host tick' to every beat is necessary?
Also using 44100 grabs too many samples (unless you are using a bpm of 60)
Acrobat's "samples per beat" works perfectly, no more no less.

Are these samples being displayed at schematic grid equivilant???
There's no background markings to "gauge" things from...know what i mean??

Yeah its just against the schm background. When its exported to vst it has the grids which are static. So its easy to tell when they are off


I know we are SO close to this because it is only ±100-200 samples off each beat. . .

It cant be the way we are doing things because logically they make sense (to me anyway). . .

In my case:
Detect when there is a beat
When beat trigger received, grab audio snapshot of x samples (x = correct amount of samples per beat)
Display snapshot

Simple. . .hmmmm

Okay, lets say that the timing components we are using are correct, they are 100% accurate & WE KNOW THIS. . .
Then maybe there is a delay in the detection & sending of the beat trigger TO the actual grabbing of audio & drawing of graph.

The result would show us that every beat the sample would be off slightly (caused by the delay in triggers) BUT IT WOULDN'T JUMP AROUND! It would stay exactly in place . . . so why is it still moving around?

This leads me to think that the drawing of the graph is correct but NOT the timer to the beat.

Thanks for having a look.
I set it up like that just to try and see what was going on..
Having different choices for everything enables more tests to be done with the one fsm in host,
rather than making a new VST for every change and testing again.

Drnkhobo wrote:So tempo tick does it correctly

Yeh, checking it this morning, It seems the tempo tick(or note tick)is what is needed.

Drnkhobo wrote:When its exported to vst it has the grids which are static.

I'm not getting these show up in host...??

Drnkhobo wrote:they are 100% accurate & WE KNOW THIS.

I know, this is the beat in the host, I don't understand what this "graph method" is doing.....

Drnkhobo wrote:Then maybe there is a delay in the detection & sending of the beat trigger TO the actual grabbing of audio & drawing of graph

Yeh, you might be right, i was suspicious about that part too.
But I don't see how we have got the "circuit" wrong.
Didn't find any clues in SM Toolbox about graphs and their "display" behaviour.
Did notice the stock scope in FS is built different. Tried it but result seems the same.

Maybe open a thread in "general" about graphs and scopes, get some better input.
I never really used them for timing stuff, and don't have much experience in their behaviour.
.....audio guru's should be able to break down this "Graph" issue very quickly.

Anyway, did some more tests on v3 (consistancy checking)-still all good.
v3 was built to handle the PPQ issue. Still can't generate a error from a tempo change.
Someone needs to generate a error in host, real quick, or I'm gonna be pouring some
Irish Whiskey into the "chalice" and start drinking
.....and I'm not sure that's a good thing for FS and Synth people
- I am a Guitar player(first)....your worst enemy

So com on guys....shoot me down...this mountain is too high...air is thin....not enough oxygen..
Run v3 as VST, as it is, generate a midi/timing error..and post the result..
so i can crash land again

Someone needs to generate a error in host, real quick, or I'm gonna be pouring some
Irish Whiskey into the "chalice" and start drinking

LOL! I think you can start already man!

I think I will make a topic about scopes. . . hopefully gather interest

Anyway, did some more tests on v3 (consistancy checking)-still all good.

Nice my friend, you can relax & get to that drinkin now!

I think that PPQ & the timing issue is sorted thanks to you and some others here on the forums. . . *Clapping hands*

Drnkhobo wrote:LOL! I think you can start already man

I wish we could end it that fast . But not yet..still to early.....

My main focus at generating a error is this......

Look at the v3 circuit. Notice it works simply by holding the user's selection
and delivering it at 0. the beat starts at 1.
I know if the user times his selection at point 0, the S/R accuracy seems to take care of it,
But I can't help thinking there is 1 in 16 chance of an error happening.

So i have been playing around with these two parameters.(ticker time and count number)
This seems to "tighten" that gray area up, no human is going to be that fast...

So if anyone gets an error, the first pic is probably why, and second pic is the Fix.
At the moment I'm leaving it as is with a host tick and a count of 16. No errors yet.

I new if took it up, sooner or later I would get an error, because the circuit is not "optimized".
Next i went up to 256 on the count and the circuit, as suspected, could not keep up.
The real interesting part is when increasing the count and the the timer like this,
watching those 128 numbers fly instead of just 16, sort of "opens the door for sub-sampling".
Based on this....
The circuit should be re-created in ruby, with a ruby count as well.
That will allow us to get those monster tick rates discussed earlier, enabling a more "pro" solution.

(I would have used Trog's Ruby counter, but i got a slight re-draw issue with it, one of the values
won't re-draw for me, so i can't use it for testing until work out why I'm not getting an immediate
re-draw under certain circumstances.)