Stock VSTi Fails Timing Test Using Host Seq

[trogluddite]

It may end up that the inversion test won't work due to this after all.)

Well, if what GoI says is correct, then it should still work if you listen to the sound rather than look at the GUI representation of it - more time consuming of course, but that is surely the truest test.

[Perfect Human Interface]

Well the visual inaccuracy was just a tiny bit of rounding on the length of the drawn waveform, not something that would cause it to draw waveforms where there shouldn't be waveforms due to cancellation or anything like that. In other words, what Gol said was just the answer to why there appeared to be note timing drift on long audio, not the answer to why billv can't get perfect phase cancellation.

(I still don't know what exactly billv is doing. )

[billv]

first instant is the only one where everything is guaranteed to line up 100%

Ok.All good.
So who is responsible for the next correct note(that diss-appears) at the start of the next bar?
That's the sucker I'm chasing. If its the PPQ, then I'm thinking it means I have to tempo divide
directly from the PPQ, then s+hold the note in delivery. ...don't know

surely the truest test.

i sort of dis-agree there Trog - Look how far where zooming in- no way you can tell the difference with
human ears in those microscopic areas.

I still don't know what exactly billv is doing

And I thought i was making myself pretty clear......
Ok. No more pictures then.....must be confusing you

[billv]

I still don't know what exactly billv is doing.

Ok, It may all seem confusing. But here's the quick gist of it

I think it's all Pall's fault,ha ha
Nix was building his seq, and i was there chipping in a bit, when Pall questioned
aspects of the timing. Nix then declared that he had detected drift, so i then re-tested
my work, and found drift in everything i made.(not knowing at the time my testing method was wrong)
viewtopic.php?f=2&t=1342&start=20#p4869
So then i had to re-open my 100% accurate thread and decalare it 99.9999% whatever accurate
viewtopic.php?f=3&t=1255&start=20#p4890
and troublshoot through this thread with Nix's sample accuracy checker
viewtopic.php?f=2&t=1268#p4877
and some more referencing at Trogs thread
viewtopic.php?f=3&t=1267#p4306

And then this thread itself got created in the course of testing/troublshooting,
Which sort of speaks for itself.
So it's no wonder you not exactly sure what I'm doing.

Wow, now that's some praise

mate, think of all the tests I've done over the years-all the while using a WRONG METHOD.
About as dumb as it gets.

Too bad I don't drink!

Yeh, I'm lucky to get typsy twice a year. Not my thing either. Always keep a bottle of
Irish Whisky in the room though. great nightcap-

[Perfect Human Interface]

Okay, so, the big question I'm wondering here is whether there was ever a problem in the first place... Personally I would like to see the "bad" timing demonstrated in order to see the behavior and what needs improving (if anything). Assuming it hasn't been done already.

[billv]

Assuming it hasn't been done already.

Trust me . It's been done. Done to death, and then some. And no-one really wants to go back.

was ever a problem in the first place

I guess the only way i'll tell for sure is to test my new timer up against my old one

I would like to see the "bad" timing demonstrated

Get SM and try and make a VST with accurate timing.
Or use FS, Use the stock custom ticker. Make a vst, look at results and then ask why at the
very first marker there is nothing.
Best way is to build a dodgy circuit-and that's so easy its not funny.

[trogluddite]

Okay, so, the big question I'm wondering here is whether there was ever a problem in the first place... Personally I would like to see the "bad" timing demonstrated in order to see the behavior and what needs improving (if anything). Assuming it hasn't been done already.

Well, firstly, I'd agree with billy, it seems that it has been realised - both in his designs, and to a lesser degree in my own PPQ thread (mine constantly re-syncs using PPQ, which can't be done so easily in FL, so billy has managed to do it in the most demanding environment that we have yet found).

I think the 'problems' boiled down to twp things...

1) The legacy from SM.
There is no doubt that SM, which has only 'green' triggers and not Ruby events, was hopelessly inadequate - events could only be scheduled using Windows timers, which are not accurate even to the millisecond, let alone each sample (to be fair, Microsoft never designed them to be so).
There were 100's of attempts to improve upon this - and using PPQ and pure stream schematics, it was possible for 'audio only' designs, but never anywhere close for MIDI events.

2) What is time?
Our sequencers show us time (most often) in bars and beats - Ruby events are scheduled in seconds - but the underlying measure of time is really the sample clock. That clock may be shared between the two systems, but there's no guarantee that the maths for converting bars and beats to samples, or time in seconds to samples, will be calculated in quite the same way in those two systems - or even that it is safe to assume that the values are calculated for every single sample, rather than being quantised in some way.
And no example was provided with FS that adequately demonstrated this kind of accuracy in practice (note; accuracy, not precision, two very different things)

So, in a sense the problem was not that Ruby events had a known fault that needed fixing, rather that we didn't know for sure either way until a fully working example had been shown to be reliable in practice - something that everyone could use with absolute confidence.

As any good scientist knows, proving a positive is a damned sight harder that proving a negative, so like you, I have total admiration for billy's hard work and patience to get to the bottom of this. No doubt there will now be some optimisation of the implementation to follow, but billy has done the lion's share of the hardest part - showing beyond doubt that it CAN be done. (and after our experiences with SM, it's no surprise that there was quite a lot of doubt floating about!)

So, thankyou billy, and thankyou DSPr - the 'holy grail' of us MIDI freaks seems to be here at last!

[billv]

the 'holy grail' of us MIDI freaks seems to be here at last!

Yeh trog, it's all good mate. Did some more tests. We can all rest easy and just get on with it now.
Got to run to work, no time, details in timing post.
Will try new polarity test when get home from work.

Big thanks to Nix and yourself, and Pall too!!!!! .

[billv]

There's nothing like the "consistancy" test.
Re-tested the Stock Vsti module.
Look what i caught it doing...

ScreenShot187.png (8.89 KiB) Viewed 17148 times

At the same time my timer is still where it always is.

ScreenShot188.png (9.3 KiB) Viewed 17148 times

That's why polarity test keeps failing with my timer and stock vsti.

Stock vsti is not "exactly" right on the money.

So the thread re-opens.

[billv]

Yes it real.
Quickly did another test.
My timer still there

ScreenShot189.png (7.29 KiB) Viewed 17144 times

But look at the stockvsti. THIS TIME its not drifting behind.
It looks like its alright, but to me it seems its striking a fraction too early.
In any case, it's not the same as it was 5 min ago in previous post.

ScreenShot190.png (5.99 KiB) Viewed 17144 times