Possible? Fix Beat-Synced Plugins to follow PDC.

[Lykdraft]

Hey,

I wonder if this is possible. When PDC adjusts the latency of the plugins, all plugins that rely on Sync-to-Radiums clock get out of sync completely. I guess this is because the modules are delayed/adjusted/shifted in time, but the clock is still coming...I don't know..like too early?

I hope you know what I mean... ;)

[Lykdraft]

(When there is only low latency that needs to be adjusted, it's barely noticable. But when higher latency gets introduced the tracks become a mess, because I use beat-locked plugins a lot, that's why I am asking.. :) )

[kmatheussen]

Ouch, this sounds complicated to fix. You mean that the clock VST plugins use for syncing also needs to be latency compensated? Do you have a small example song using u-he plugins which demonstrates the problem, that you can send to me?

[Lykdraft]

uHe I think has way too low latency to make this audible I guess. Probably they are even zero-latency plugins. I'll try later to to chain them up multiple times to see if I can make this clearly audible.

I really stumbled over this with pitch-shifting and declicking plugins and stuff like this that introduce high latency. Before that, I really didn't notice at all.

And yes, because when you lock an Instruments LFO Rate to beat (which means it relys on the clock of the Host) and the latency is too high, the LFO is out of sync. Same goes for Midi Step-Sequencers or whatever is synced to the host. Basically true for everything that uses beatsync for something.

(I think this might be manually manageable somehow with the time-adjuster module, but I havent tried yet...)

[kmatheussen]

I meant using u-he for syncing, since I have those plugins on linux. To set a high latency somewhere in the mixer chain, we can just use the TimeSkew plugin I guess.

I've looked a little bit at the code, and I don't think it's so difficult to fix, but it's not so simple that I can do it blindly. :-)

[Lykdraft]

Ah it seems that the problem came from another direction...

It is that when a high latency plugin is _bypassed_ everything gets messed up. So that PDC from the plugin is still calculated for time adjustment, but the plugin itself is bypassed, so there is no real lateny introduced in the dry audio signal. Also I can hear this clearly with the dry/wet slider. With high latency, you can only use the wet signal. This is in sync with everything else, but when you mix in a part of the dry signal in there, it is like a horrible out of sync echo effect.

I have no idea how to sync up the dry signal to the PDC adjusted wet signal, I guess there is not much that can be done about this. Sounds pretty coplicated already... :)

(Only thing I can think of to get rid at least of the bypass issue, is an ability to disable the plugin temporarily, so that it is not calculated anymore at all, which would have the nice side-effect that it also saves CPU. But I am not sure if this is neccessary right now. Also this might be impossible at all, as bypass is an automation target...)

[kmatheussen]

I've tried to reproduce this, but I can't wrap my head around what the problem is. Here is a song (with samples embedded) where track 1 goes through u-he filterscape to filter a bass sound in sync, and track 2 is a bass drum going through two timeskew plugins in serial. The first timeskew plugin adds a 80ms latency (without changing the sound), and the second timeskew plugin adds a 80ms delay. This sounds as it should, but perhaps you can change this song so that it doesn't sound as it should. http://users.notam02.no/~kjetism/synctest.zip

[kmatheussen]

(oh, and for some reason, the filterscape plugin needs 2 bars to get in sync if you restart playing, at least on linux.)

[onukore]

i already have this issue in other host , when you bypass plugins and restart it ,the bpm sync as keep, but not the block sync, in renoise with lfo meta reset bottom (automatable) as made to restart lfo sync, for some other plugin i never found solution , only thing i found is, never stop plug ,make 2 connection wire and mute one you don't need work fine for fx, but for vsti no solution ,reset sync object when you unbypass it is solution but i don't know if it's hard to do

[kmatheussen]

Sorry @Lydkraft, I didn't see your last message yesterday. Anyway, this is too complicated for me now. If something is wrong, please just make an example song, it's too hard to follow explanations at this point.

[kmatheussen]

So that PDC from the plugin is still calculated for time adjustment, but the plugin itself is bypassed, so there is no real lateny introduced in the dry audio signal.

Oh! Of course. Not that complicated. When bypassing, Radium must add a delay of the same size as the reported latency of the plugin. And same with the dry signal when dry/wet-ing. I'll fix that.

[Lykdraft]

Right something like that... :) I have project here, where I added the ladspa pitch shifter (Hq) on a short sound and automate the dry/wet slider from wet to 50% . You'll hear right away, what I mean.

When we are 100% wet, all is good, the introduced dry signal (same when bypassd completely) is whacky out of sync.. :)

https://www.dropbox.com/s/zz4pm19qjgpd0sf/ExampleMessedUp.zip?dl=0

[Lykdraft]

(so probably Radium must add a delay of the same size always to the dry signal as well, not only when bypassed... Because otherwise the wet/dry slider can't be used anymore, as the signal is only in sync on 100% wet..)

[kmatheussen]

Yes, exactly. And when the sound is 100% dry, it is also possible to readjust the reported latency to 0, since radium is able to recalculate latency compensation at any time, but I think that would produce some kinds of artifacts to the sound.

[Lykdraft]

Probably. Especially because it is an automation target. But might be worth a try. It might be easier to just add the reported latency to the dry signal, even when bypassed?

I mean in case of small artifacts: bypass automation can be done with the dry/wet slider basically as well. (going ff->00 stepped) So maybe even if small artifacts are introduced when clicking the bypass button, (I know this from Logic as well) it might be not too bad at all.

[kmatheussen]

Yes. it's easier to always add delay to the dry signal. But that's not the main reason why I don't think it's a good idea to change the reported latency while playing. When latency compensation is changed, there is a transition time of some milliseconds where the old delay fades out, and the new one fades in. And this happens in all the parallel running instruments. I don't think you want that in the middle of a song. In addition, the beat is screwed up as well, since one beat will become 20 ms (or something like that) longer or shorter than the previous one, when a sound object is muted or unmuted.

[kmatheussen]

20 ms (or something like that)

No, the beat length will change with the size of the reported latency of the plugin that is muted or unmuted. 20ms (or so) is the crossfade time when switching between two latencies.

[kmatheussen]

Hmm, unfortunately it seems like timing sent to the vst plugins sometimes needs to delay compensated as well: http://users.notam02.no/~kjetism/synctest2.zip

[Lykdraft]

Ah I see, so the orignal posts problem is also true. So theese are 2 different problems that originate from the same source. I really don't know which one to prioritize... :)

(I think the dry-signal-compensation is more important, as this affects all plugins, not only the ones wich rely on beat-sync and is way harder to manually workaround. Because with the beat-sync issue, we should be able to still shift the signal with time-skew afterwards, so that it is somehow correct again. Also high-latency plugins are usually always applied late in the chain.)

[kmatheussen]

I think it should work now

[Lykdraft]

yes, it does. great work on that one, thanks a lot!

[Lykdraft]

closing this.