Stock VSTi Fails Timing Test Using Host Seq

[billv]

During tests using the just the stock VSTi and FL studio.
No timers. generate the notes in the host.
It drifts after a few seconds, check length of example

ScreenShot161.png (6.42 KiB) Viewed 22747 times

at the start of measure its

ScreenShot164.png (4.2 KiB) Viewed 22747 times

then at start of measure 2 its

ScreenShot163.png (4.23 KiB) Viewed 22747 times

After a few minutes it's just horrible.

Can someone please explain this.?
Looks to me like there's a problem with the stock vsti......???

[trogluddite]

How big (in samples) is that drift exactly?

If I had to hazard a guess, I'd start by looking into a couple of things...

1) Sample difference is around +/- 16 samples.
The stock synth uses envelopes that are hopped by 16 samples - and hops don't begin at zero when a note starts AFAIK because they are all synced to the same counter, so the delay will jitter within the 16 sample 'frame' size depending where it catches the hop cycle.

2) Sample difference roughly +/- soundcard buffer size.
It used to be common that sequencers only ever sent out Midi at audio buffer boundaries, which unlike ppq won't always fall at beat divisions - in the days of hardware synths, this didn't matter because hardware MIDI is so slow. Whether any sequencers (or FS/SM) still work that way, I don't know, but a buffer's worth of MIDI jitter used to be the norm.
AFAIK this is how green->stream conversion works; the green values only get read in once per buffer, so maybe the MIDI thread works the same way?

[billv]

How big (in samples) is that drift exactly?

Don't know. Nix gave me a wicked little "sample timing calculator" last week.
Guess i could try to rig it up in the vst somehow and find out.........
Jeez Trog, Does this mean a re-writing of the Midi to poly module will be required
before i can re-sume polarity testing my timer again??
PS:
Ican't believe that the stock VSTi, that we have all been using for years, is faulty like this!!

[Perfect Human Interface]

It was a bit confusing what you were saying in the other thread. So if I understand correctly, by "stock VSTi" you're referring to the "default" VSTi schematic that loads in Flowstone, correct? It almost sounded as though you were saying there are timing errors in FL Studio using the included FL synth plugins. But really we're still talking about timing issues in Flowstone. Right?

That inversion technique is really useful for finding any kind of discrepancies in audio signals, not just timing (for example, you can check if an EQ plugin's filters are causing phase issues). But thankfully Trog is full of knowledge about all of the little loose bolts that could effect outcomes of timing tests.

Have you tried using the "Voices" module rather than MIDI in FL?

[billv]

"stock VSTi" you're referring to the "default" VSTi schematic that loads in Flowstone, correct?

Yes. export it. enter notes in fl seq. record it. have a look.

That inversion technique

Is absolutly pointless if my my synth with my timer is accurate and the same synth without
the timer, using the host seq to generate the notes, drifts.
Export stock vst to fl and try it.

Quote;
Have you tried using the "Voices" module rather than MIDI in FL?

No. its a test concerning the STOCK VSTi and FL.

[Perfect Human Interface]

I'm not seeing timing discrepancies with recording this thing into Edison so far, but doing so did make the audio start popping very audibly...

Anyways, another thing if you didn't know, you can zoom in much further in Edison than you can in the FL playlist. Like, you can see the interpolation between samples. Also make sure you enable tempo sync in Edison (click the invisible button next to "tempo" right above the waveform window) to have the correct tempo-based markers drawn (you can do this after recording too).

Quote;
Have you tried using the "Voices" module rather than MIDI in FL?

No. its a test concerning the STOCK VSTi and FL.

When I load the stock VSTi in FLFS it uses the Voices module. I'm assuming that loading it in non-FL FS uses MIDI to Poly. Trog mentioned some possible idiosyncrasies within the MIDI standard so it may not be wise to assume the difference is insignificant here.

[billv]

I'm not seeing timing discrepancies with recording this thing into Edison so far

Ok. It's just not happening here at all. tested again for 3 min and stock vsti fails everytime after a while
At start

ScreenShot166.png (8.01 KiB) Viewed 22728 times

About 3 min

ScreenShot167.png (7.83 KiB) Viewed 22728 times

See what i mean?
My timer does not miss that black host mark. Stock vsti fails.
Polarity test can't continue till some sort of "ppq" fix to the midi to poly module, is created,
so the Stock Vsti can carry its own weight during the polarity test and keep up with my timer.
If the stock VSTi with all the host's help, can't keep up with my timer, then I'm just going to be arrogant
and not bother to turn up for the "polarity testing"
Unless there's another way to do "polarity testing"......

[Perfect Human Interface]

Upon closer inspection I can see that there are TINY differences in note start time, where the beat lines are drawn, and even where the "song jump" markers are placed in Edison (every bar). The notes mostly appear to start approximately 1 sample before the line (not exactly but very close). The "song jump" markers are within a fraction of a sample from the line. I don't see any drift after a 1 minute recording, more like "jitter" like Trog was suggesting.

Once again, these are tiny differences, one sample length or less. And thinking about it, it's not actually possible for a sequencer's timing to be absolutely "perfect" because sample rate and tempo are completely independent, so there's always going to be rounding, if I'm not mistaken.

It's also worth noting that since this synth is free-running, the appearance of the waveform itself is going to be different on every note, so that could very well effect what you're seeing trying to eyeball it in the playlist as well. If you used a recorded sample or a synth with no free-running qualities it would be consistent.


Now as for whether or not any of this makes the inversion test useless, I don't (necessarily) think so, because the ideal you're aiming for would be to match the host's timing since it's fair to assume you won't/can't do better. But the question here would be whether possible rounding differences that Trog suggested may surface, would could cause that test to fail even with a "close enough" to perfect timer. But about that I don't know.

**Okay I just now see the last post you made as I went to post this, and all I can say is that I'm looking at it in Edison, not in the playlist. Also your waveforms appear to be identical so I'm wondering why that is, since the stock synth's OSC's are free running, right?

[Perfect Human Interface]

Just did a 5 minute test and the notes at the end do appear to start slightly sooner compared to the lines drawn IN THE PLAYLIST. This does not hold true for the waveform and lines drawn inside Edison before dragging the recording to the playlist.

This may be an inaccuracy with the way the waveform is drawn in the playlist in FL. I would trust the view in Edison more since that's made for editing with down-to-the-sample accuracy while the playlist is just for sequencing music.

[billv]

Upon closer inspection

Firstly, thanks for digging in and having a go.
Second, please note, all my tests are done in pattern mode, and all tracks are sent
to playlist. I always send to playlist, cause that's the "real world" scenario.
Most users will send the track to playlist...that's the place where all timing is most relevant

worth noting that since this synth is free-running, the appearance of the waveform itself is going to be different on every note,

Uummmmm.....

ScreenShot168.png (20.89 KiB) Viewed 22725 times

I don't (necessarily) think so, because the ideal you're aiming for would be to match the host's timing

Na mate, I'm there waiting on the money, at every host black marker.
Where's the Stock vsti and the host seq?...........Failed to qualify for the race.......
diqualified....that's where..

stock synth's OSC's are free running, right

Yeh Trog has mentioned this "free running" thing before. I don't really get it, seeing the picture above.

Just did a 5 minute test and the notes at the end do appear to start slightly sooner

What do you think about the "creating a ppq fix in red" for the midi to poly?