Recording from Bus & Count-in

Here's a weird one.

I've set up 2 audio tracks, both with a single sample click placed at sample position 100. Track 1 has it's click sent to outputs 17-18 which are connected to inputs 17-18 (loopback). Track 2 has it's click sent to Bus 1.

I've set up 2 more audio tracks, one receiving input from 17-18, and the other receiving input from Bus 1. I then record enable BOTH of these (input) audio tracks and hit record.

If I set the Count-in to 1 bar, the click going to/from 17-18 is recorded OK. However, the click going to/from Bus 1 doesn't get recorded (just "silence"), even though that track's meters are showing input (from Bus 1) and the waveform/region display for that track clearly shows a "pulse" when recording is taking place. If I move the source clicks forward 1 bar (click @ 1 bar + 100 samples), the click to/from Bus 1 does get recorded.

Also, if I set the Count-in to an even number (2 bars, 4 bars, 6 bars, ...) the click from Bus 1 does gets recorded.

This only seems to happen when I record enable BOTH (input) audio tracks. If I record enable the track receiving input from Bus 1 on it's own it works fine.

Can anyone help?

Logic project is attached below.

Cheers,

: D

Record_from_Bus_with_Count-in.zip

It's a nasty bug but you are over-complicating things.

It has, what I can see, nothing to do with Count-in per se so lets ditch that.

The bug is recording an input at the same time as we are recording a bus.

To simplify things lets try this instead:

• Track 1 has a sample @ bar 2. Output to bus 1
  
• Track 2 is empty, set to input 1 and record enabled.
  
• Track 3 is also empty, set to bus 1 as input and record enabled.
  
• Tempo is set to 120 BPM

Record from bar 1 and we get nothing.

Record from bar 0 and it works.

Lower the BPM < 80 from bar 1 and it works

In fact give the recording 3 seconds to cook before it reaches the sample, at any tempo, and it works.

I do not know what's causing this anomaly.

But it seems that the audio engine is being confused somehow.

Any thoughts?

00 Bus recording bug B.zip

Yeah, I left the routing slightly more complicated because I wanted to record my 2 Bus chain (round-trip/loopback) whilst recording from a Bus simultaneously. But you just need to record from any other input at the same time for this bug to occur.

You're right, this seems related to the length of time the pre-roll or count-in takes (min. 3 secs). So a count-in of 1 bar will indeed work if you lower the tempo enough.

Also, the difference between odd/even numbered count-in I thought was happening actually seems to be related to how quickly you stop recording after the region overview shows the click/kick has been recorded. On my system, if you stop recording straight away (within about a beat) the click/kick doesn't get recorded, even with a 3 second pre-roll. If you let the recording run for about 1/2-1 bar, it does record properly.

I can also confirm that no combination of I/O Buffer size and Process Buffer Range seems to make any difference.

It's a dodgy bug, but in all honesty I'm just glad it's not my setup causing the problem specifically. I can work around it by setting a longer pre-roll when recording to/from a bus and other record-enabled tracks at the same time. If I'm just printing that Bus on it's own, the problem doesn't appear.

Thanks,

: D

After further investigation, this problem only seems to occur when simultaneously recording to/from a Bus and directly from an Input.

If you set the dummy track (other record enabled track) to record from another Bus it works fine, without any pre-roll or count-in.

I think I've found a workaround. Create an Input object in the environment, set it's output to a Bus. Set the dummy track's input to that bus, record enable both tracks, and record. No pre-roll required. Not really tested it though.

: D

After further investigation, this problem only seems to occur when simultaneously recording to/from a Bus and directly from an Input.

Yes.

The bug is as I can see recording an input at the same time as we are recording a bus.

Did I mention I can't read very well!

: D

Did I mention I can't read very well!

 

: D

But seriously... This is why I wanted to simplify the example. It's easier to find the culprit this way.

On my system, if you stop recording straight away (within about a beat) the click/kick doesn't get recorded, even with a 3 second pre-roll. If you let the recording run for about 1/2-1 bar, it does record properly.

I noticed exactly the same behaviour. I measured this in absolute time instead of bars and found that it is about 1.5 seconds.

The audio engine seems to be compensating for something right after the 3 second window. I believe this is also why the Arrange is appearing to show an empty region! But in fact it has been recorded if you check the Sample Editor. Choose Refresh Overview(s) and it appears in Arrange.

I can also confirm that no combination of I/O Buffer size and Process Buffer Range seems to make any difference.

Yes. Buffer sizes, Sample rate... does not seem to matter.

I think my work around of recording indirectly via an Input object > Bus seems to work fine.

So I'm happy with that.

Thanks for your time.

: D

I think my work around of recording indirectly via an Input object > Bus seems to work fine.

 

So I'm happy with that.

 

Thanks for your time.

 

: D

You're welcome.

I think I've found a workaround. Create an Input object in the environment, set it's output to a Bus. Set the dummy track's input to that bus, record enable both tracks, and record.

You can also skip the Input object in the environment and use an AUX instead.

Create a new AUX in the mixer. Set it's input to the desired one. Output to a bus that then is being recorded by another track.

Glad you found a solution to this. It is a strange one, but I think this may help explain what's going on:

When recording from a physical input, Logic automatically compensates the position of the recording for the systems IO latency. When recording from a bus, Logic assumes that the routing is internal and that there is therefore no IO latency - so Logic doesn't compensate for this.

My guess is, that Logic can handle either recording scenario in isolation, but not both at once. When trying to record simultaneously from a bus and a physical input, perhaps Logic defaults to its input recording behaviour and compensates both recordings for IO latency. This would have the effect of putting the input recording in the right place, but put the bus recording early by the IO latency amount and before the start of the recorded region.

If this is true, then in your original test, changing the IO Buffer size should affect how early the bus audio is recorded; and your Input>Bus>Audio Track solution should result in both files being recorded in sync with each other, but early on the grid (by the system's IO latency).

From what you and Eric have posted though, that doesn't seem to be the case, so there could be more to it than this. Anyway, it's probably worth double-checking your solution if maintaining sync with the grid is important in your particular situation.

Tom

Thanks for chiming in Tom!

Your knowledge in this kind of scenarios is invaluable.

It's a very strange anomaly. It doesn't matter which buffer size nor which sample rate you use. I tried different values for this very reason but there is something else going on.

I/O buffer of 32 samples @ 96 kHz requires the same 3 second as 1024 samples @ 44.1 kHz.

You're welcome Eric!

Curious indeed