Racks and latency

[FarfadetFarfelu]

Let's say we have three racks, and usine is setup to 128 bloc size.

is it correct to say that that each rack has a 128 (whatever it is in milliseconds) latency ?

if the racks are in series : rack 1 > rack 2 > rack 3 then the total workspace latency will be 128 x 3 ?

if i have only (audio input > wire > audio output) inside one rack, the latency is still 128 ?

i'm trying to avoid phase issues.
Thanks.

[FarfadetFarfelu]

Another question, do audio busses introduce latency ?

For example

Rack 1 = latency 128
Audiobus send in rack 1 - Get Audiobus in rack 2 = latency 128
Rack 2 = latency 128

total from rack 1 input to rack 2 output = 128 x 3 ?

[FarfadetFarfelu]

is there a way to test latency in usine hollyhock ?
Thanks.

[ceasless]

Can we get some answers to these questions please? For a live performance environment, this is not cool to leave these questions unanswered.

[nay-seven]

I've added a chapter about latency in the FAQ page ,I hope it will clarify some Usine concepts

[CREDO]

There's no latency between racks or when racks are fed into each other (unless there's a loop 1>2>1?), but the internal bus system (audio/midi/data) do add one block of latency.
(sorry to be redundant, I was writing this at the same time as the other answer : )

[FarfadetFarfelu]

Thank you for your answers, it helps a lot to know the general rules and principles.

i still have a few questions, maybe the best way is to use an example.

i have a clean audio signal travelling through 4 different paths in parallel and then going to a mixer inside usine :

1 : rack one (input > wire > ouput) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Channel 1 of the mixer
2 : rack two (input > wire > ouput) >>> rack three (input > wire > ouput) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Channel 2 of the mixer
3 : rack four (input > wire > audio bus send1) - rack five (audio bus return1 > wire > out)>>>>>>>>>>>>>>>>>>>>>>Channel 3 of the mixer
4 : rack six (input > audio bus send2) - rack seven (audio bus return2 > audio buss send3) - rack eight (audio bus return3 > out)>>>Channel 4

Am i going to have phase issues at the mixer because of different latencies in those four signal paths ?
When you say the buss system adds one bloc of latency, that means if there is one buss or 30 busses it will always add one bloc of latency and never more? But does it add the latency in the global usine workspace or only on the buss signal path ?

Last question, if i do a circular routing (feedback) inside a patch (VST output connected back to the input for example), does it add latency ?

Thanks !

[CREDO]

I think this is right but someone please correct me if i'm wrong...

Am i going to have phase issues at the mixer because of different latencies in those four signal paths ?

Yes

When you say the buss system adds one bloc of latency, that means if there is one buss or 30 busses it will always add one bloc of latency and never more?

Yes, one bloc for as many A>B routings, but I think an A>B>C or A>B>A would add two, and A>B>C>D would add three, etc.

does it add the latency in the global usine workspace or only on the buss signal path ?

Only the signal path

if i do a circular routing (feedback) inside a patch (VST output connected back to the input for example), does it add latency ?

Yes

The only way I know to avoid latency issues with complex routings is to avoid loops and (sadly) busses... Each rack can be multichannel though, so along with chaining them, there's a lot of routing that can be done between channels in a single rack (as long as you avoid loops).

If overall latency isn't the priority you could just use short delays before outputs to keep everything in phase.

[senso]

If overall latency isn't the priority you could just use short delays before outputs to keep everything in phase.

yes, and don't forget that plugins have often a built-in latency.

[woodslanding]

Don't ALL effect plug-ins have some amount of latency?

But it occurs to me that they report their latency to usine, correct?

So you could use that value to create a delay for the un-effected signal, of you are sending to one of these effects....

[woodslanding]

Rereading the Hollyhock front page, I saw this:

A powerful real-time process management, derived from Artificial Intelligence, gives a zero-latency buses calculation.
In other words, unlike most of Digital Audio Workstations, there is no additional latency for complex audio routings.

Is this an anticipated future improvement? Or does this only refer to certain kinds and scopes of bussing?

[FarfadetFarfelu]

Thanks for all the explanations.
i ended up putting the same number of busses on every audio path to be sure the latency is the same.

[mindfilter]

hmm

[ceasless]

Would deeply appreciate some feedback from sensomusic regarding the "zero latency buses calculation" support. Is it already there (it's already advertised, after all)?

[FarfadetFarfelu]

Well back with the same questions Now in hollyhock.
So is the above still True or has hollyhock changed things regarding the handling of latency ?
Thanks.

[senso]

no changes !:)

[Pianoscope]

I wonder If the OP confused busses in Usine like I did, or maybe I still am. When I first came to Usine I didn't realise you can get zero latency "bussing" by dragging racks to another racks output, getting a send with it's own gain and pre control.
Before I discovered this I was under the impression busses had to be made using the internal bus system, and I made buss inputs and outputs etc, which does have latency.

I think I am right that "busses" made by dragging racks onto another tracks output achieves zero latency bussing.

[senso]

I think I am right that "busses" made by dragging racks onto another tracks output achieves zero latency bussing.

yes you're right!

[woodslanding]

Is there a technical reason why buses with a scope inside a single rack cannot be zero latency? Doesn't each rack run it's own thread?

I think I am right that "busses" made by dragging racks onto another tracks output achieves zero latency bussing.

Is this kind of zero latency bussing available via any method besides drag and drop???

I read up on racks, but I can find no mention of this in the manual. I'm a bit confused about how routing works with racks.

What I'd like to do is have midi input processing in patch1 of a rack and have some output and mixing logic in patch3 of the same rack, and then be able to dynamically load via the loadPatch module different patches (with midi in and audio out) into patch2 of the rack without losing a bloc of latency.

Is this possible?

The flow is just top to bottom in the rack. Does HH patch this automatically somehow? Does it work for audio and midi?

I guess I'll try normal midi and audio ins and outs, and see if the flow is 'automatically' this way. I've not typically tried to route things 'through' the rack, but I'm guessing(?) it's meant to be done this way???

Any clues welcome!
-eric

[woodslanding]

Okay, just did a quick test, back at my laptop....

PATCH1: Piano roll-> midiOUT
PATCH2: midiIN->VST -> midiOUT [WORKS!]
PATCH3: audioIN-> audioOUT [DOES NOT WORK!]

No audio comes into patch 3 from patch 2, indeed patch3 mutes the sound from patch 2(?). Is there some sort of parallel/series switch for the rack audio?? I remember something like that in Usine5, but I don't see anything in the inspector.....

[sephult]

Do you have an Audio Thru on Patch 3?
So PATCH2: VST Output....is placed on PATCH3: Input
You then need an Audio Thru in Patch3: to direct input to output.

Or if you add an effect/plugin it will patch it for you from input to output.

-s

[sm_jamieson]

A couple of points:

1. Since Usine knows all the latencies involved (VSTi report their latency, Usine knows all its internal routing and use of buses), there should be a setting in Usine to compensate for all of this. So the worst case routing latency will be applied to all other signal paths. This would guarantee that the outputs are in sync without having to add padding delays.

2. I'm not really sure why the internal bus system between racks (i.e. threads) has to delay by a whole bloc. A whole bloc is a long time in computing terms. I'm sure from a programming perpective this could be solved, perhaps by thread signals rather than polling at the bloc rate. If it can be done between racks by dragging racks onto other racks (i.e. between threads), it should be possible for the buses as well.
I suppose it might be a limitation of Delphi ?
Even if it cannot be removed for the audio path, midi signals could be dealt with differently so that midi buses do not delay.

Thanks,
Simon.

[23fx23]

I can imagine the complexity of proper PDC in nodal system. there are some of isane amount of diffrent possible scenarios in terms of wiring, tracking looping backs, sidechains, dependencies ect.

just an exemple, what if i make a patch that dynamically load/changes patches or VST, with different latencies. usine has to test the chain latency (wich implies processing) imagine latency went from 10 blocs to 0. what happen then?, all other tracks are suddently undelayed with jump back of few seconds in audio realtime?, thats def mostly not wanted in a live situation. so what should it do, delay the new chain instead and keep tracking of what was done previously? imagine for a complex wks and evolving sheme what this can imply.. this is just one ex, i feel there are many tricky cases that makes this a far far more complex task that we could even think of. considering ie ableton is not even able of proper automations pdc actually, i wouldn't expect an automatic system to be possible in a such complex soft like usine personally, think 'manual' setting track delays is more adapted to the vast amount of possibilities.

[Nold]

If overall latency isn't the priority you could just use short delays before outputs to keep everything in phase. And click this to get follixin for hair.

yes, and don't forget that plugins have often a built-in latency.

I forgot about that.