Latency Problem (in V3.6.3) Options

[Anatolyj]

Hi, there is a problem - by default, grm plugins not transmit to DAW their delay (latency) info.
i.e. DAW cannot automatically compensate latency which produce plugins.
It`s starts work only if we disabled and enabled again specific plugin in rack.

Here i record short video wich good demonstrate this problem (for example two identical tracks, one track with GRM Equalize, you will hear the difference): https://youtu.be/LEqGHPW1rsI

VST 64bit Complete II v3.6.3, Windows, DAW Studio one 2.


(And BTW - delay 87ms for EQ, it's not a bug ? i.e. its should be ?)

This post has been edited by Anatolyj: Dec 5 2015, 07:40 PM

[Anatolyj]

And what I wanted to say about latency of whole GRM bundle.

Plugins with zero latency (no delay):

Band Pass 0ms
CombFilter 0ms
Delays 0ms
Doppler 0ms
Freeze 0ms
PitchAccum 0ms
Reson 0ms
Shuffling 0ms
SpaceGrain 0ms
Spaces 0ms

Its very good.

Next plugins which produce signal delay:

Contrast 40.6ms
Equalize 87.1ms
FreqShift 17.4ms (default bands 512), and 180ms with 4096 bands
FreqWarp 40.6ms (default bands 1024), and 180ms with 4096 bands
Fusion 40.6ms
Grinder 5.8ms (default bands 128), and 180ms with 4096 bands
SpaceFilter 87.1ms

And offcourse Evolution are king here, 365.7ms (default bands 8192), and almost 3 second (!) delay with bands 65536

I can understand about all plugins signal delay (especially Evolution), but come on guys, normal graphic equalizer with 87ms latency, need something to do with that. It's fantastic agitation system, really love it, and very sad that it's almost not a usable in realtime.
Please, It may be possible to optimize this?

In vst world are there tons of powerful EQ-s which have at least 0.1ms delay.

Also can assume, that if can optimize EQ latency (that certainly can be done), then in general, it should be possible to optimize whole GRM tools FFT engine (just in the sense of latency), i.e. delay for the other grm plug-ins. That would be really cool.

This post has been edited by Anatolyj: Dec 5 2015, 11:04 PM

[brahmat]

And what I wanted to say about latency of whole GRM bundle…

…In vst world are there tons of powerful EQ-s which have at least 0.1ms delay.

Also can assume, that if can optimize EQ latency (that certainly can be done), then in general, it should be possible to optimize whole GRM tools FFT engine (just in the sense of latency), i.e. delay for the other grm plug-ins. That would be really cool.

sorry, but you are demonstrating a clear misapprehension of FFT based real-time analysis and processing. Comparing such tools with the "tons of powerful EQ-s which have at least 0.1ms delay" is meaningless, read a bit before making statements like this.

[Anatolyj]

sorry, but you are demonstrating a clear misapprehension of FFT based real-time analysis and processing. Comparing such tools with the "tons of powerful EQ-s which have at least 0.1ms delay" is meaningless, read a bit before making statements like this.

Well, at that moment I really got excited perhaps, possible reason for this first impulsive emotion when you see such dream tools, and in the same time such latency restriction, as the only obstacle hindering to nirvana.

On the other hand, using them for some time, and read old messages of this thread (in what condition grm plugins had been before), now i can say that has done a really great work to current version: i had to hard test a couple of plug-ins from a collection in a completely different modes - primarily it was all that concerns to overall automation, then render\bounce, and save\reopen plugin in any different settings\condition in DAW project - damn, it all was works absolutely properly. I really appreciated it, very cool.

But again - problem with Studio One 2 (about non work latency transfer by default) - a controversial issue imo. (BTW this problem i solved via jbridge, oddly enough )). But nonetheless, considering above, i can say it's worth it.

I hope the grm folks is not very offended by me.

This post has been edited by Anatolyj: Jan 4 2016, 07:28 PM