you coud measure the real latency of your system by sending a click from max and recording it again, and then you can compensate the delay of the send/return paths by delaying anything else as soon as one send is used.

If this is not 100 channels mixer hardwire all connections using matrix~. it takes a bit off time, but can be done modular just make 1 channel module, assign it a send/receive address ONLY for control and storage and multiply it as many tmes you want.

Sorry for my late reply!

The creation of channels is dynamic (scripted).

So if i send channel 1 and channel 2 + send 1 and send 2 to the matrix~ and send them to the same dac outputs it will not generate any phasing? I could just script the matrix~ object for dac outputs 1 & 2 then and leave everything else as it is....

i will try this. Thanks!

if you use the non-MSP [s] / [forward] / [r], those will not produce any latency at all and should be enough for a scripted setup.

Hmmm, im still a bit stuck with this... i would like to understand where the latency is coming from that causes the phasing. Has it something to do with the signal vector size in the audio status setup of max? I imagine that the stream of audio i am sending to the two send channels and back to the dac might maybe not be processed in the same block of samples and therefor comes in with a delay...?

Audio comes from a mc.receive~ into mc.unpack~, then into a matrix~, from there per channel into a live.gain, into *~ then into two serially connected vst~ objects and finally into the dac. right before the dac, resp. after the second vst~ audio is sent (send~) to the send (wich lives in a separate patcher) where audio also passes one live.gain and the two serially connected vst~ objects before being sent back to the dac.

Could i be right with my idea of signal vector size delaying my sends? If so, what could cause the delay? ...i cant really imagine how max processes audio and where it decides to spilt up calculations into different blocks but i'd like to understand it.

after source audio´s answer i wasnt so sure any longer that i understood your setup. in case you are creating real "sends" and "aux returns" using your DAC, then that is where the latency comes from first in line. plus the latency the outboard gera in the send path might produce (compressor?) as long as you are within max, all audio vectors are always synchronized, but the content gets delayed when you delay a vector (for example by using send~ or producing a feedback loop)

vst will definitelly mean latency, and amount of it will depend of the plugin used. If I remember correctly send~ / receive~ do also delay signal by vector size, but I never use them, so can't tell you if that changed in meanwhile. In your configuration it doubles bacause of: vst pair 1 send~ -> receive~ vst pair 2 send~ -> receive~ dac~ vst pair 1 wired to dac~

send~/receive~ only introduce a delay by vec-size when used in a feedback loop, but it sounds like you might have one:

...when you write "the two serially connected vst~ objects" you mean the same ones from which the send~/receive~ came from?

but as SourceAudio wrote, it's mainly the vsts(you can try removing one from the chain to test, you'll probably hear significantly less of the delay).

@Roman Thilenius, aha...i never leave max, everything is happening inside. Its a mixing console to handle multiple audio players so the audio signal is comming into the mixer from multiple groove~ objects (from a separate patcher though).

@Source Audio does that mean, latency will increase always in steps of vector size?

@Raja the sends are not the same ones. but maybe the feedback exists because the audio signal goes to the dac first and then is being routed to the send and then back into the dac again? (see screenshot, thats how its routed now)

Thanks!!

even in old max 4 days there was latency test patch for hardware that could be easily reduced and inserted into your mixer. It simply sent click out, recorded it back into buffer and measured time between sent and received click. output time in samples could than be used to adjust delay~ inserted between second vst~ object and dac~ to align it with the second audio stream. If inserted Vst plugs don't change, that could remain stable.

oh ya, i see from the pic now, like you said and also as SourceAudio described:

(no feedback loop, though, so it's the vsts)... one thing you could try is just insert a 'delay~' object(set it to try multiples of your signal-vector size), right between the first vst-pair and their direct connection to the dac~. then you'll be compensating for delay on the second-pair by delaying the first, and by trying different delay-times you might be able to figure it out by ear(i have a feeling it would be a multiple of Max's sig-vec size, unless you have specific vsts where you can alter their vec-size within them), it'd look like this: vst pair 1 send~ -> receive~ vst pair 2 send~ -> receive~ dac~ vst pair 1 delay~ -> dac~

(edit: you could even try this, and that would probably confirm by ear if send~/receive~ causes delay, in such case the following would compensate by introducing the same delay caused by send~/receive~ for the first-pair as there would be for the second-pair, i don't think they cause delay, though: vst pair 1 send~ -> receive~ vst pair 2 send~ -> receive~ dac~ vst pair 1 send~ -> receive~ send~ -> receive~ dac~ )

i was curious since i use vst~ myself these days (for a mastering chain), here i tried with all vst~ loaded using FabFilterQ3, and the same preset loaded(flat 5 band), i don't get any delay/phasing whether i try the signal "send~/receive~" nor even with the non-signal versions as shown here:

so it must be something specific to your vsts, or else something in your "s_dbtoa" abstraction(but if that's just db to amp conversion, probably not there, either 🤷‍♂️)

exactly, his patch shouldnt cause any delay, it is probably the plug-in he tried it with.

Hey, thanks for all the answers!

...the thing is, i have no vst loaded when testing this. The vst~ objects are all empty.

but here is another screenshot (im sorry, but with the whole scripting situation there was some stuff missing in the last screenshot) where the input with the matrix~ is visible. Maybe it has something to do with this (the matrix~)? I just tested the vertor-size-delay idea and this makes a difference: when delaying the two inpus that are going to the dac "directly" by one time the vector size the phasing disappears. ...so for now it seems to be this one block of samples delay...but where does it come from?

i dont like the idea of adding a delay to the script...since i dont even know if this delay will be a fixed value or if it even might increase depending on the loaded plugins.

:

send~, vst~, and live.gain~ do not cause a delay by default here. vst plug-ins themselves will report their latency upon request (if the have some, and if the info has been correctly set by the author) but you still didnt show us what is inside s_dbtoa. this is how you can quickly test which path might have a delay compared to a another path:

thats just [dbtoa] > [$1 25] > [line~] going to the left inlet of a *~ to scale the dial object wich i use to send signal to the send channels. So Audio passes just another *~ inside the abstraction.

Removed the matrix~ to see if it plays a role = no difference, removed the vst~'s = no difference, removed vst~'s and matrix~ ...no difference. So i guess i have to go the hard way and use this method to find out where my patch preoduces latency.

What i dont understand is why the delay of 1 x vector size inbetween the sends output and the dac fixes the issue... after what i found out i would assume that the latency must happen somewhere before the audio even reaches the matrix~ object wich would then mean that, if no object in the screenshots is causing the latency, the outputs and the sends should be in sync. no? am i somehow misunderstanding the situation?

Are you sure that phasing problems get caused by latency, and not by mixing dry signal with output of S/R vst plugins ? Are the plugs some reverb ? and fully wet ? Or something else ?

"am i somehow misunderstanding the situation?" what happens before you split the signal at the aux will be irrelevant.

This is still an unsolved issue and im reporting back with my latest insights: i believe – not just believe, actually its kinda proven in the patcher i attach to this post – it has to do with the bpatcher. ...i seems that all the audio that is going through a bpatcher comes out delayed one time the signal vector size.

i believe i actually never mentioned that all the audio goes through a bpatcher and from there to the sends... i thought it would not make any difference since all the audio that is comming from the several poly~ objects are all in sync too. Seems its a bit different with the bpatcher object.

the situation in the patch attached is pretty much what i have in my patcher (except the rightmost gain slider wich is just for comparison)

...

what can be done about this?

insert delay is that sooo difficult ?

well... believe it or not, it is.

im trying to find out if i must abandon bpatcher or if there is a way to implement it in a patcher without getting any latency and why this happens inside bpatcher. adding delays is not really an option. (read posts above...?)

then make it without bpatchers, simple as that. All the posts above ... Why don't you post a simple graphic layout of what you are doing ? I understood from the beginning that mixer channels are hardwired to master outputs, and channels only use send~ to 2 effect inserts, which themself return signal via send~ to master out. Or is that not so ? What do you need bpatchers for ? and bpatcher is not same as patcher, as you just found out in terms of send~ / receive~ latency Now there is all this mc audio stuff, carrying multichannel audio ... whay don't you add 2 effect send channels to the audio output stream of each mixer channel and so only need to connect one wire per scripting, if that is a problem.

oh yeah, maybe it is yet another one of the special "features" of bpatcher. will try that later. "Why don't you post a simple graphic layout of what you are doing ?" for me his pictures of the patch were pretty much straight forward, and i also dont see anything "wrong" there. except that i wouldnt use s~ and r~ at all since they do not offer anything new compared to a connection. only f/r would (dynamic routing)