MuLab 8.4.18 (APDC)

[dreammachine_nl]

I did some testing with the Reafir_standalone(v 1.75) plugin which has an inital delay of 4096 samples. It all works fine up to the point where you change the FFT Size of the plugin from 4096 (equal to the initial delay) to another value, like 8192 etc., which causes the audio to go out of sync again. I don't know if the VST protocol allows for updating the 'initial' delay during the use of the plugin. If yes, it would be nice if MuLab could track these updates.

If not, this might be solved by making available another MUX module, which would would also be another huge selling point for people who use hardware units (effects and synths). I'll explain from the hardware point of view.
You might set up an audio path from your computer/DAW to a hardware (e.g. reverb) unit and route it back to your computer/DAW (I actually do this via an ADAT unit). Currently in MuLab it is already possible to compensate for the introduced delay of the hardware routing by delaying all your other audio paths with a couple of Pure Delay Modules. Things easily get more complicated though when you have several hardware units connected (each with their own audio path delay). It's all doable but still a tedious job. (Yes, I know: you could just bounce the audio in Mulab and put it in the right position afterwards).

But, getting to the point, when the APDC of MuLab is fully operational, you could give the user one more MUX module. This MUX module will serve only to communicate the delay caused by the hardware (or whatever audio path, such as a VST which doesn't properly communicate its 'initial delay') to your new APDC functionality in MuLab.
The user determines the delays caused by the (hardware) audio paths and inserts your new MUX Module into the audio path. No matter how complicated you will make the routing (series, parallel, or a combi): MuLab will then take care of all other audio paths through the APDC functionality.

Let's call it something like: Manual Plugin Delay Compensator no, this doesn't quite cover it, actually. Maybe Manual APDC Controller? Because you kind of control the APDC by telling it what delay it needs to compensate for.

Regards,
TDM

[mutools]

PDC is working well so far with M8.4.2. I even did a null test with a sine wave, and an inverse sine wave on a delayed rack. There's some inaudible (too quiet) harmonics that escape, but it's close to a perfect null. Level meters are at -80 peak.

I double-checked this case as i was surprised by it but could indeed repeat it. I've tweaked a certain code point which makes certain default gain operations (eg a Send with default send gain) more perfect. Normally adding a signal with it's inverted signal should result in perfect silence. (- oo dB)
Did you also use a Send in your test?

I am now also noticing a quirk, which I have no real good solution for. In other DAW's, PDC will also match the level meters of a rack, meaning the rack vu meters are also compensated. I understand that racks in Mulab work quite differently, but seeing the level meters out of sync is jarring when the use hears the audio in sync.

I noticed it too and it's indeed not ideal. I'll try to work out a solution.

[mutools]

I did some testing with the Reafir_standalone(v 1.75) plugin which has an inital delay of 4096 samples. It all works fine up to the point where you change the FFT Size of the plugin from 4096 (equal to the initial delay) to another value, like 8192 etc., which causes the audio to go out of sync again. I don't know if the VST protocol allows for updating the 'initial' delay during the use of the plugin. If yes, it would be nice if MuLab could track these updates.

I noticed that too with ReaFir but thing is that ReaFir doesn't report its latency change to the host so i think this is an incompleteness of ReaFir.

...
But, getting to the point, when the APDC of MuLab is fully operational, you could give the user one more MUX module. This MUX module will serve only to communicate the delay caused by the hardware (or whatever audio path, such as a VST which doesn't properly communicate its 'initial delay') to your new APDC functionality in MuLab.
The user determines the delays caused by the (hardware) audio paths and inserts your new MUX Module into the audio path. No matter how complicated you will make the routing (series, parallel, or a combi): MuLab will then take care of all other audio paths through the APDC functionality.

Let's call it something like: Manual Plugin Delay Compensator no, this doesn't quite cover it, actually. Maybe Manual APDC Controller? Because you kind of control the APDC by telling it what delay it needs to compensate for.

What about "Virtual Delay"?
So it would be alike Pure Delay but then the difference is that it will not delay the signal (it simply thrus the signal) but i does report a user defined process delay to the APDC system. Right?

[dakkra]

That would actually be great! Bitwig has a delay module where it can have "negative delay", which essentially informs the host to compensate for a certain delay time. Good for building look-ahead compression and other transient/dynamic processors with stock modules.

[dakkra]

I double-checked this case as i was surprised by it but could indeed repeat it. I've tweaked a certain code point which makes certain default gain operations (eg a Send with default send gain) more perfect. Normally adding a signal with it's inverted signal should result in perfect silence. (- oo dB)
Did you also use a Send in your test?

No sends. I can rebuild the project on video if you'd like to see the whole process.

[mutools]

Not necessary to create the video. Pls recheck the same case with the next version and if a signal + inverted signal is not perfect silence as expected then pls let me know.

I'm more interested in how to repeat that logged error VcdMpuStp[438]

[skarabee]

+1 the Virtual delay thing.
That's why I asked if APDC in Mulab was taking the info given by the plugin or if it was calculated by a separate process in Mulab. Some plugins report an incorrect value, some change the value (like ReaFir): being able to manually correct the compensation delay is a logical addition to APDC.

[mutools]

I'm not sure what you mean with calculating a VST plugin's latency, but to answer your question again: MuLab uses the plugin latency info given by the VST 2 plugin, ie. the initialDelay value. When a VST 2 plugin changes its initialDelay it should notify the host DAW using audioMasterIOChanged. Unfortunately ReaFir doesn't do that. Luckily it only takes toggling the green On/Off button to reset to the new latency value.

[dreammachine_nl]

What about "Virtual Delay"?
So it would be alike Pure Delay but then the difference is that it will not delay the signal (it simply thrus the signal) but i does report a user defined process delay to the APDC system. Right?

Yes, that's exactly what I mean! Virtual Delay (or maybe Virtual Negative Delay?) seems appropriate here. It may not immediately be clear what this module does, but then you still have the M8 docs of course.

[EDIT]
About the ReaFir issue (where I changed the FFT size of ReaFir and it didn't seem to update/resend the 'initial delay' parameter): you are probably right, but I did some more testing and discovered a discrepancy which may mean that it is a more global issue (with other VSTs or within MuLab, I don't know).

Let me explain: actually ReaFir does update. I noticed that making ANY change within Project MUX in MuLab synced the audio streams again, which implies the update did happen.
This may mean that:
1- ReaFir does report the correct/new initial delay right after changing the FFT size, but MuLab only processes this information when you change something in the project MUX (e.g. inserting/deleting any MUX module, (dis)connecting any path (audio, events or modulation) between MUX modules, etc.);
or
2- ReaFir only sends the update when you make such a change, which may seem a bit strange because it works with any change, even if the change is completely unrelated to ReaFir (like inserting some irrelevant module somewhere).

So the main question is: what happens when you change the FFT size? Does ReaFir actively send the new delay info (which MuLab only seems to process after you make some change in Project MUX) or does ReaFir need to be prompted to send this info (and does MuLab send such a prompt when you make some change in Project MUX)?

...When a VST 2 plugin changes its initialDelay it should notify the host DAW using audioMasterIOChanged. Unfortunately ReaFir doesn't do that. Luckily it only takes toggling the green On/Off button to reset to the new latency value.

Oops, I only saw this message after posting my own. I guess not only toggling the On/Off button, but making any change in Project MUX causes this reset.[/EDIT]


This fiddling lead me to another thought about having more control over the APDC system (in case a VST doesn't function properly, or simply because the user wants more control for whatever reason). Here is a hypothetical example:
Suppose a VST reports a huge FIXED initial delay of 64000 samples to MuLab (and would never update).
Case #1: the user has determined that the actual delay from the VST is 96000 samples: no problem here, we just insert the new Virtual Delay module into the audio stream and set it to 32000 samples.
Case #2: the actual measured delay from the VST is only 1000 samples. You would say: no problem here either, we just insert the existing Pure Delay module into the audio stream and set it to 63000 samples.

But this solution to case #2 would mean an very ineffecient use of resourses. The APDC still thinks it has to deal with a VST that introduces a delay of a whopping 64000 samples, and delays all other audio paths to match. While the actual delay to consider by the APDC system could have been only just 1000 samples...

I see two possible solutions, one on a local level and one on a global level.
The local one is to provide a right click option on the VST module to exclude it from the APDC system, so it does not send its 'initial delay' parameter to the APDC, so to speak.
The global one is to have another checkbox available in the 'properties' box of the 'VST Plugin Manager'. So next to 'Zero audio buffers before process' have a 'Do not include VST for APDC processing' checkbox or something like that. Both options mean that the user will have to fix the delay manually, but it may be what they want. It also means we really need that Virtual Delay module .

Last but not least, I reckon that there will also be users who may want to completely switch off the APDC functionality, so it might be useful to have a global preference: 'APDC functionality ON/OFF', but again, I'm not sure. Just a thought.

Regards,
TDM

[mutools]

1- ReaFir does report the correct/new initial delay right after changing the FFT size, but MuLab only processes this information when you change something in the project MUX (e.g. inserting/deleting any MUX module, (dis)connecting any path (audio, events or modulation) between MUX modules, etc.);

Indeed that's the case. ReaFir should notify the host that it changed its initialDelay so that the host can update the APDC automatically but ReaFir doesn't do that.

[mutools]

In fact i find Automatic Plugin Latency Compensation (APLC) a better term, don't you think?
(the only disadvantage being it less standard)

[sl23]

Ah so that's what it is for! That makes sense to me now

[mutools]

M8.4.3 is available in http://www.mutools.com/mulab/beta/

• New "Latency Generator" module. This module is a handy tool to test APDC in MuLab or any other host DAW. This module can also be used to define a latency for plugins/hardware that don't report their latency to MuLab/the host DAW, and so they can be included in the APDC system.
• Audio recording now also takes APDC into account.
• Project Render To Audio File/Sample now also takes APDC into account.
• In some specific cases a 0 dB gain knob/slider could result in a slightly off 0dB gain. The difference was inaudible (-94 dB), but now it's perfect (- oo dB).

How to update:
Windows: Replace the current MuLab.exe and MuLab.ID by the new versions.
MacOS: Replace the current MuLab.app by the new version.

[dakkra]

I would like to clarify/fix my previous post on null testing with Mulabs APDC. The extra harmonics were a result of the VST, not Mulabs APDC.

https://www.youtube.com/watch?v=VoKERhhIYeQ

As that video shows, Mulab APDC nulls exactly the same as without APDC. The VST was the cause of the extra harmonics (probably some saturation, knowing Melda).

APDC is a dream in Mulab! Outside of the visuals not yet matching the audio, it's a joy to have!

[mutools]

Thanks for the clarification Dakkra, and for your appreciation of APDC. I admit that it took me some time before i was really convinced of the need for APDC (i hate the latency it introduces) but since some time now i was fully convinced of how essential it is nowadays and just needed to find the right technical approach and r&d time. Looking forward to finetune it further and get it ready to rock. I agree that synced visuals are important too and will look for a solution. Whether that will be in M8.4 or M8.x will depend on how fast i can find a solution. Will research that the next days.