Timing shift in 3.0.0

Right after I upgraded from 2.17.1 to 3.0.0, I loaded existing song which was recorded previously, and immediately noticed that the loop Aeros plays is shifted against BB drums by some fraction of a second.

I re-recorded the same song again on 3.0.0, and this one was synced with BB fine, but I figured there is another (seemingly related) problem: when I mute a track on 3.0.0 (this is a cued mute, on the EOM), I do hear a tiny bit of the next measure before it mutes.

I downgraded to 2.17.1, and confirmed things are working fine there: I loaded my old song there (recorded on 2.17.1 long ago), and when I mute it on EOM, it mutes exactly at EOM, I don’t hear anything from the next measure.

That’s some pretty annoying issue in 3.0.0, I’ll have to stay on 2.17.1 for now.

Can you guys reproduce, can we expect a fix for that?

I had a similar issue with 2.17 and just discovered it again with 3.0
In my case, there’s about two measures of silence at the end of a song. And more recently after reloading the song, the silence was gone and the loop starts over early. Either way it’s unpredictable and therefore unusable.
I’ve been sending the song files to SS at their request so they are aware of the issue.

Most of these issues are caused when there is a mismatch between the tempo the song was recorded at and the tempo of the BB. So if you recorded on the Aeros with 100 BPM and later your BB is set to 101 BPM, there will be a misalignment of the loops and the drums.

The Aeros displays the visual waveforms based on the tempo it is receiving from the MIDI sync, but the audio is played at the original speed. So if the BB tempo is set to slower speed than the Aeros was recorded at the audio loops will complete playing before the waveforms are displayed to complete, so that’s was can cause the apparent section of silence as the visuals catch up to the audio.

We will be implementing a system warning the user of when there is a mismatch between the recorded tempo and the incoming MIDI sync tempo.

1 Like

Thanks for the reply David… That makes sense in the scenario where a recording exists in quantized mode at a certain bpm and then BB is used at a different bpm. However, for me anyway, This occurs on a brand new song where the BB is used to lay down the initial track.

I know there is the option to set the bpm when creating a new song but I disregard it as the BB is set to master. I haven’t taken note of the difference of the setting when creating the song and that of the BB when creating it. And when I save and reload the song later, the bpm shows the BB setting I had correctly.

Could there be an issue where the Aeros is not disregarding the setting in the setup dialog when using the BB to set the tempo? I’m starting to think the missing measures I’ve mentioned in other posts may be directly proportional to the difference in the bpm of the Aeros and the BB. But I’d have to check that.

It would be unfortunate to have to manually set the bpm on the slave to equal that of the master.

Edit: forgot to mention that this occurs in FF mode too. I usually keep a scratch song open that I can quickly noodle out ideas on. I may make a recording in one bpm and delete it all and then start a new song, without saving or exiting, with a different bpm decided by the setting on the BB.

***Update: I think I’ve isolated the issue further. I put down a track of drums from BB in quantized 2x2. I then proceeded to lay a guitar track over that… no issue. But I then changed the BB bpm and tried to lay down another guitar track… it synced the bpm even though I didn’t activate the BB. There were silent measures at the end on playback.

I understand if I could just resolve not to touch the bpm after that first track was set, however…

***When I record a one track BB song and save, then open a different song, then change the bpm on the BB, then open the original song and attempt to record, it still syncs the new BB bpm! And the offset is proportional to the difference in the bpm. This all occurs without ever triggering the BB.

To avoid this scenario I would have to change the bpm on the BB to match * every single time* I change songs!

Thanks for your attention on this!

Assuming that a fix to the time signature sync will take some time to be released, can the Aeros display a warning when there is a mismatch (which would be helpful anyway).

The v2 of this warning message ideallydoes not get in the way of the “playing” that may be ongoing. Perhaps this is just an overlay window that does not block the functioning of the Aeros and the “main” footswitches. Perhaps it disappears on it’s own. Perhaps there’s a way to dismiss it by one of the lesser footswitches.

I recreated the issue and updated my post above… a warning at least would be nice, if not changing the Aeros from slave to master in regards to the bpm setting after a track has been laid down. That way when you reload a song, it tells BB to shush. I’m not a midi guy so I don’t know how that would fly.

Or how about having Aeros ignore BB bpm when loading a saved song?

@DavidPackouz the mismatch between BB tempo and Aeros tempo is not an issue in my case. In my first message I wrote:

I re-recorded the same song again on 3.0.0, and this one was synced with BB fine, but I figured there is another (seemingly related) problem: when I mute a track on 3.0.0 (this is a cued mute, on the EOM), I do hear a tiny bit of the next measure before it mutes.

So I just recorded a new loop, with BB at 60 bpm, and it’s synced with Aeros fine, but muting at the EOM (end of measure) actually mutes it a tiny bit later, so I hear a small fraction of the next measure.

Clearly 3.0.0 cuts the measures in a wrong way. Can you reproduce this muting issue? To reproduce:

  1. Make sure the muting setting in Aeros is “EOM”
  2. Set BB to 60 bpm, and time signature 6/8 (I didn’t try it on other signatures, so to 100% reproduce, please use this one)
  3. Having BB as a master, record a new loop, changing chords on every measure
  4. Try to mute a track by double-tapping the Overdub button. Aeros is supposed to mute the track exactly at the end of the measure (and in 2.17.x, it works fine), but in 3.0.0, it’ll mute it a little bit later, so you’ll hear a fraction of the next measure.

Can you reproduce it?

1 Like

So sorry… Didn’t mean to hijack your thread! I’ll try to reproduce this too.

I confirmed that this issue is fixed in 3.1.3. Thanks.

1 Like