KVR Audio

mbncp · Post by **mbncp** » Sun Jul 16, 2006 11:41 pm

What is this values exactly.

Is this the time of the last asio switch callback ?

BertKoor · Post by **BertKoor** » Mon Jul 17, 2006 7:48 am

It's supposed to be the "system time" I think. The real-world clock instead of the song's time position. It holds a timestamp, but I don't think these are actual nanoseconds of which 1.000.000.000 fit into one second. How this was exactly established totally depends on the host.

mbncp · Post by **mbncp** » Mon Jul 17, 2006 8:53 am

What I would like to do is to synchronize incoming MIDI events (received directly by the plug) with the audio buffer.
So I need to know the time of the last asio switch callback.
Is this possible inside a plug (using SX3) ?

BertKoor · Post by **BertKoor** » Mon Jul 17, 2006 9:21 am

As I understand it (only having read a VST Plugin sdk pdf, never coded a plugin) there is a DeltaFrames field for this in each midi event you receive. Keywords: ProcessEvents (call before Process() or ProcessReplacing) and WantEvents, all described in the chapter about Handling Events.

If you don't get your Midi events from the host, that's in violation with the VST architecture I think. Not recommended...

mbncp · Post by **mbncp** » Mon Jul 17, 2006 9:58 am

The problem is that all the host I tried will set the deltaFrames field to zero on live MIDI, and I would like to try to keep the latency constant for all events, to see if it makes my guitar strumming easier with larger buffers.

I know it's not the way to go, but it's just for testing and maybe convince host builders to allow synced live MIDI, even if that means that most events will be delayed even more, but at least it would be constant.

BertKoor · Post by **BertKoor** » Mon Jul 17, 2006 10:23 am

I can imagine the host wants to forward all live received midi events as fast as possible to the plugin. But killing all timing info on them would make no sense.

If what you say is true, then if I set the buffer size to the largest size possible, then I would not be able to play any fast notes without them getting quantised to the buffer size. Rather hard to test (at least for me.)

The VST specifications do not guarantee that the VST buffer size is equal to the ASIO buffer size. Depends on the implementation...

Did you also test all hosts that are built for live playing instead of sequencing? E.g. cantabile, chainer, stacker, minihost, and not to forget receptor...

I can't help you further I'm afraid, seems you're looking for a red herring.

mbncp · Post by **mbncp** » Mon Jul 17, 2006 11:08 am

They all seem to set the deltaFrames field to zero, except MiniHost that always sets it to buffersize -1, but that doesn't help.

You can try this yourself, with this little VSti plug:
http://homepage.hispeed.ch/mbncp/download/VstSpy.zip
You will need a monitor window (dbmon, dbwin32,..)

MIDI events will display like this:

Code: Select all

1092	12492109	01	2047	90	076	077	000	000000	000	000000

Fields are: GetCurrentThreadId, timeGetTime, event #, deltaFrames, status (hex), data1, data2, noteOffVelocity, noteLength, detune, noteOffset.

BertKoor · Post by **BertKoor** » Mon Jul 17, 2006 12:23 pm

A technical note regarding the midi implementation in hardware.

The Midi protocol uses a baud rate of 31250 bits/sec. Since a note-on event takes 3 bytes, this means there only can be 312500 / 10 / 3 = 1040 note-on events squeezed into each second over Midi. {edit: forgot theres a start & stop bit on each byte}

Suppose your host is set at a sampling rate of 48kHz and you only use 16bits stereo outp: 192kByte processed each second. With a buffer size of 128 this means there are 1500 buffers processed each second. Only one note-on event can be handled in each buffer, and jitter (event delayed for the next cycle) may occur.

If you want a higher resolution, you should configure your host accordingly. When each buffer takes less than 0.7 ms to process you've hit the max resolution of Midi hardware. Then it's the Midi hardware again that can't keep up with the tempo.

But true real-time processing is something that is very hard in the digital world, since everything is buffered and has to deal with latency. Alas, it won't ever get perfect.

VstTimeInfo::nanoSeconds