Is there any VST host that doesn't quantize live MIDI ?

[mbncp]

In this case I want to eliminate the software problem.
Even with the tightest rock solid hardware in the world, if you use a 2048 sample buffer, all your live MIDI IN will play with a random latency of 1 sample to 2048 samples.
With VStHost, the latency will ALWAYS be 2048 samples, and that's what I was looking for.

Now of course I'm not playing the guitar with a 2048 buffer.
I just compared SX and VstHost with 256 samples buffers, and the feel I get is better with VStHost, when strumming like a maniac

Anyway, I found what I was looking for, so all good

[mbncp]

Ask Jorgen, Charly, Tobybear, Ron or Babya, they will all tell you the same thing

er... *really*..?

If so, you might have just lost some credibility there - I hope you're joking!

You mean about Charly ?

[mbncp]

Ok, remember my test on the previous page, with the 2 events at 10 msec interval with a 2048 buffer ?
All those host will either play them at the same time ( 0 msec) or at the buffer size, which is about 46 msec, as the timestamp is always zero.

The lowest interval I had with VSTHOST is 397 samples (8.9 msec) and the largest 544 samples (12.3 msec), with an average of 464 samples (10.5 msec), which is not bad at all.

Should a host play every incoming MIDI event as soon as possible, or try to preserve the relative time to each others ?

[JonasNorberg]

Hi guys, I'm behind mbncp 100%

I'm a "hobbyist" vst developer, and discovered this quantisize "bug" a few months ago. When playing live all midinotes are quantisized to the beginning of the buffer. I tried Cubase LE and SX3, and Minihost.

I'm using EMU 0404 and I'm pretty sure it's not a hardware/driver issue. It should definately be a host issue.

I do not know of any host providing constant latency instead of jittered.

I only play a keyboard (no midi-guitar) and at 14ms I have no trouble when playing live.

The reason I know about the issue is that I got a crash in my (work in progress) synth when several notes was started the same frame. So I checked it out in the debugger and noticed the quantization when playing live.

Your best bet is to get a soundcard that can use really low latency. Or get a real guitar for strumming


Jonas

[mbncp]

Thanks Jonas, finally someone who knows the truth

Well I use 2 sound cards, one for SX3 to record the MIDI (but not connected to a synth) and playing back the existing tracks, using a 2048 buffer, with a bunch of tracks, fx with delay or whatever.
Live playing is done on another host and card, with a lower latency. Until now I was using Forte, but 256 is about the limit with this setup, and this is still a little high when strumming.
But now with VSTHost it's nearly perfect, nothing gets quantized.
The only problem is that changing MIDI ports settings will kill the timestamp like on the other hosts. Really weird, I hope Arakula isn't on vacation right now
And yes I have a real guitar, but it's not as fun as playing my EZ-AG, especially with my new plug

[Rock Hardbuns]

Does this occur even when the sequencer is stopped?

I don't know if you already covred this (long thread) but it happens simply because most apps are layed out to use syncronized buffers that gets passed on directly too the ASIO and so there is only one call to each synth per buffer.
If your midi message come in a millisec too late, it missed its chance and will have to wait on the next buffer.

To make matters worse, most synths are structured to take advantage of this architecture, so if you were to make an app that uses say 32 float buffers internally before filling up an asio buffer of 256 you'd get a pretty massive performance hit.

edit > atleast I'd thing you get a big performance hit with all the extra calls back and forth. To over come this, at it's root so to speak you'd need a new plug in standard that was based on per sample processing rather than ASIO buffers...but that will never happen.

[JonasNorberg]

To over come this, at it's root so to speak you'd need a new plug in standard that was based on per sample processing rather than ASIO buffers...but that will never happen.

No need to change the API. There already is a deltaTime member in the midi event sent to the plug by the host. When playing back you have sample-perfect resolution.

The problem described only applies when playing live, where all (I think) hosts tries to minimize the error in time, and introduce jitter (by setting all deltaTime to 0) instead of fixed latency (keeping the deltaTime).

On one hand I think this thread should go in the dsp-dev forum, on the other hand I think you need a special midi-controller (like guitar) to even hear the jitter.

Jonas

[Rock Hardbuns]

The problem described only applies when playing live, where all (I think) hosts tries to minimize the error in time, and introduce jitter (by setting all deltaTime to 0) instead of fixed latency (keeping the deltaTime).

I heard you on the live thing, and if you want to have the quick consistent live response you need to let go of buffer processing, since as soon as a synth is called to produce another batch of 256 sample, it's too late for any midi messages to get in on that buffer.

Keeping delta time makes no sense since that time referes to the buffer that is already gone. It's set to zero because that's the first opportunity to trigger the note. At the first sample of the next buffer.

[mbncp]

Does this occur even when the sequencer is stopped?

Doesn't matter, the timestamp is always zero.

I don't know if you already covred this (long thread) but it happens simply because most apps are layed out to use syncronized buffers that gets passed on directly too the ASIO and so there is only one call to each synth per buffer.
If your midi message come in a millisec too late, it missed its chance and will have to wait on the next buffer.

Yes there is only one call to processEvents, the function that receives the MIDI events, but the host didn't receive all the events at the same time.

To make matters worse, most synths are structured to take advantage of this architecture, so if you were to make an app that uses say 32 float buffers internally before filling up an asio buffer of 256 you'd get a pretty massive performance hit.
edit > atleast I'd thing you get a big performance hit with all the extra calls back and forth. To over come this, at it's root so to speak you'd need a new plug in standard that was based on per sample processing rather than ASIO buffers...but that will never happen.

If Hermann's VSTHost can do it why not others. I mean it's not a big deal. I guess that when this started the idea was to pass the events as fast as possible to the vst synth, so the average latency was smaller this way.
But really I don't know why, it's easier to work with a constant latency.
Now I have to say, that most of the time it doesn't matter, that's about 4 years I'm aware of this and it didn't really bother me. It's only since I'm playing with the MIDI guitar that I had to lower the latency or I would start to lose my tempo. First I though that was just to much MIDI for my hardware but then, why was it better with a smaller buffer ?
Then I tried using a very small buffer and add a constant latency, and noticed that the playing was easier than with an equivalent buffer. Then I recalled that these host where quantising live MIDI and that was certainly the source of my problem.

Now if I don't have to change my buffer and turn off a few fx whenever I want to record the guitar, all the better.
And it's not a problem recording just the MIDI in SX and using VSTHost for the live playing.

[Arksun]

Sorry, but I really dont understand what it is thats the problem on your system.

Regardless of what latency setting i have in Cubase (5ms, 10ms, 20ms), if i record some fast live frilly keyboard playing and play it back, the relative differences between the notes remain the same.

But I guess my computer must have special voodoo magic eh mbncp

[Rock Hardbuns]

If Hermann's VSTHost can do it why not others.

I don't know how he did it, but sub-buffering is the only method I can think of off hand. Regardless, once that processing call has been made there's no going back.

I noticed now (after scanning the thread ) that what you are suggesting is to offset all the input by a fixed value, presumably larger than the buffer size. That would certainly work, and if I'm not mistaken some hosts have that kind of feature. Simply an input delay on the midi that you can set to a value larger than the buffer induced latency.
I would assume though that the reason it's not a common or well known feature is that most people want their synths to respon as fast as possible. Most people don't use guitars, and once you get below 20 ms or so, people can't really tell.

[contrast]

This is really for anyone who might still be confused as to what the issue in question is. Imagine you have your audio latency set to 8 samples just for the sake of illustration.

Code: Select all

"Wrong" behavior that is being complained about:
12345678-12345678-12345678
+   + + -*  +   +-*

"Right" behavior that is being asked for:
12345678-12345678-12345678
+   + + -*  +* *+-   *   *

The numbers are each sample of the buffer. The dashes are just there to separate them for clarity. Below that, the pluses are where you played MIDI notes, and the asteriks are the point at which those notes are played back by the synth when, and only when, you are playing live. If you stop recording and rewind and play it back it will come out just as you played it.

This is because the audio is always generated ahead of time. So when you are hearing and playing over that little 8 sample block, it's already done and over with as far as sound generation as concerned, and therefore obviously it's too late to add new notes to it. Apparently the common means of dealing with this is to play all the notes accumulated during that 8 sample block as soon as possible (ie at the start of the next block), when it is potentially a better idea to delay them all by a constant value (ie play them at the same positions relative to each other but in the next 8 sample block).

The times at which the notes were played are not lost, and when you play back something you recorded, the sequencer knows where the notes are in advance so you don't have the problem of notes being played after the point in time at which the audio for them would need to be generated.

BTW didn't see the post before mine until after I had made this one. I'm not sure if the track delay in SX works on live input or makes it work the second way even if it does, but it's definitely there... Too lazy to test it myself but I'd be curious to know the result if anyone else decides to do it.

edit#2 - I take that back, I tried it and it doesn't seem to work on live input nor does it fix the problem.

[Rock Hardbuns]

No argument, but I think he wants it wants it to SOUND good playing live.

[mbncp]

Hi contrast, that's it.
The only problem you get with constant latency is that your brain will compensate and after the recording, you will have to move all events, but in sequencers like SX, it's just a macro, thus a click or a hotkey and you're done.

I tried playing with a constant latency of 100 msec on the keyboard, and it's actually pretty easy. Now try that with a latency that can be for each note anything between 1 and 100 msec, it drives you nuts.

[mbncp]

I noticed now (after scanning the thread ) that what you are suggesting is to offset all the input by a fixed value, presumably larger than the buffer size. That would certainly work, and if I'm not mistaken some hosts have that kind of feature. Simply an input delay on the midi that you can set to a value larger than the buffer induced latency.

You got it

I would assume though that the reason it's not a common or well known feature is that most people want their synths to respond as fast as possible. Most people don't use guitars, and once you get below 20 ms or so, people can't really tell.

That's true, on my previous pc I had to use a 11 msec buffer, playing the keyboard, and it was ok, but with guitar strumming it's a real pain, just doesn't sound real.
And that's the fun part about the guitar, and the only controller that allows that.