Sample accurate VST sync'

[trogluddite]

Following on from Billy's thread about accurate MIDI timing, here's something that may interest all you step-sequencer and arpeggiator fanatics out there...

Here's a prototype of a synchronised clock using Ruby and stream 'frames' to read the PPQ clock....

PPQ Test 002.fsm

(20.32 KiB) Downloaded 1754 times

Very basic at the moment - there's a simple synth triggered by the Ruby MIDI output set to play a short 'blip' once every beat. Recording the output in Reaper has shown perfectly repeatable accuracy of the note at the beat divisions. Everything is set up inside one module that you can just export as a VST and start experimenting straight away.

The Ruby CPU load should be pretty low - I realised that with a bit of maths, the beat positions within the PPQ can be found without having to read the entire frame, just the first and last samples.

However, I also discovered something else rather interesting...
In my first attempts, I found that there was a latency of precisely one ASIO buffer. I investigated this further using some audio stuff, and it seems that this is inherent in using the 'frame' data type.
Because streams are designed so that we can process samples one at a time, it always takes one ASIO buffer to fill the 'frames' with sample data. Testing with a variety of buffer sizes shows that this effect is precisely predictable.

So the example schematic includes latency compensation by one buffer - predicting what the PPQ signal will be one frame in advance.
However, this has a couple of consequences...
1) If you start playback precisely on the beat, there is no output on the first downbeat - because the latency compensation is already looking beyond that point. So if you need a first downbeat, your playback cursor will need a small pre-roll.
2) Sample accuracy will be ever so slightly off during tempo changes. The maximum error is one ASIO buffer size; though for smooth tempo changes, it would normally be much less than that. As soon as the tempo becomes constant again, things immediately lock back into precise sync'.

Still plenty to do with this - things that I'm working on at the moment are...
1) If the beat position is exactly at a 'frame' boundary, it won't be detected - so it needs a little extra code to detect this case.
2) Beat sub-divisions. Should be fairly simple by scaling the PPQ ramp before the modulus maths.
3) Getting that note to play on beat one when playback is started! 'Is playing' primitive may provide a workaround for this.
4) Output for the current beat/division number so that sequencers know where they are in the beat - just needs some simple maths. But note that the output would have to be a Ruby value - converting it to green would ruin the timing. So any sequencer relying on the new clock would also have to be written in Ruby.
5) MUCH more rigorous testing!!!!

I'll keep working on those - but I'm very keen to hear the results of anyone else's tests before adding too many more features - in particular, whether it is working equally well in other VST hosts besides Reaper.

And as ever - bug reports, suggestions, code improvements will be most welcome!

[trogluddite]

Just re-upped the download - stupid type when I commented the code! Sorry about that folks!

EDIT) Ha ha - stupid typo' in the post about the stupid typo' ^^

[trogluddite]

Next Update....

PPQ Test 003.fsm

(21.07 KiB) Downloaded 1669 times

This adds...

- First beat output correctly when starting playback from a beat boundary (thanks billy - your earlier schematic pointed the way to a solution).
- Sub-divisions of the beat added - and they seem to be perfectly in time.
- Test that the host is playing to avoid spurious notes when moving the playback position.

[billv]

Will test later tonight.

[Tronic]

Test Result:

samplerate 96.000 Hz
buffer asio 1024 sample

FS CPUmeter 100%

[trogluddite]

Phew - had me worried there - but the PPQ module is fine.
I should have made some things a bit clearer in the instructions, so thanks for giving me a kick!

PPQ is for syncing to the tempo of a VST host - when you're inside FS there is no PPQ signal. As it's just a prototype, there's no code in there yet to cater for the PPQ signal not being there.

However, the 100% CPU isn't caused by the PPQ module - it's the 'scope that's doing it.
I set the scope to view a whole second of samples while testing, which is rather a lot!! I should have just deleted it from the schematic.

So my apologies- I should have made clear that for testing, you must use the module as a plugin within a host!!
I'll get the download edited so that this doesn't happen to anyone else.

[billv]

PPQ Test 003.fsm

Tested in FL Studio. Great stuff Trog, but there's a small problem. She's dropping a few notes
here and there. These happen at regular timings, so there's your way in for the fix.

ScreenShot112.png (15.34 KiB) Viewed 39080 times

After about 5 min, your still right on the money, but the error still there

ScreenShot113.png (14.16 KiB) Viewed 39080 times

Your "Master Clock" theory sounds perfect. create it in one place and then distribute via ruby
through the schematic. Would also help to make FS "solid as a rock", and make it feel like it
was made out of cement.

[trogluddite]

Thanks Billy,

Think I have an idea what the problem might be - after more Reaoer testing, I have seen the same thing sometimes: seems to be if the ASIO buffer boundaries match the beat boundaries. I'm getting occasional double triggers in looped playback too.
Have an idea what I can do to fix it- i just need to store the last value from the previous buffer to paper over the cracks! Should have an update this evening.

[billv]

Hey Trog. I made it work it green.!!!!!!
viewtopic.php?f=3&t=1255
Can't thank you enough for your help.

[trogluddite]

Looking good, billy - amazing how tight that Ruby clock is; and great to see that calculating the time period in green isn't throwing it!

Getting closer with the PPQ too - sorted out getting it going in VST host looped playback. I'll try and finish this one too - to give the option of knowing the exact song position. PPQ/Bar-Pos plus your flexible "free running" solution would make a nice pair for a "universal synchronise anything to anything" pack.