This is true for me as well, until I try to overdub or re-record… then I see again the the shift (although it does not affect audio).
I’ve had that happen before. Never could reproduce it. It happened randomly. Very frustrating.
I am coming across some serious bugs in 3.4.2 that may have been there before, I will have to do some more testing then go back to 3.3.3 etc.
On recording say one part 4 tracks. Track 1 and 2 are 8 bars Track 3 is of a much longer length say 30 which is an uneven multiple. Then recording track 4 which is again 11 bars of uneven multiple. There happened to be a gap in track 4 with no sound, I then did an overdub in track 4 to fill in the gap. The overdub changes to green, but on playback there is no sound from the green section.
I will have to try and reproduce this in a more simplistic way. Then go back to an older firmware.
The bars showing uneven alignment do not seem to effect the timing of the tracks.
Same here. I’ve had this happen with the prior version too, but I don’t recall exactly what leads to it happening. I use external MIDI Clock and I kind of think in the prior version it had something to do with tempos not being set exactly the same in both the sending device and Aeros (could have been a combination of that with certain sync settings), but everything is okay if I set them both and normally just stick to what I know works. Sounds like the bug is expanding.
I can look into reproducing it in the prior version if anyone thinks it can help, I’m avoiding doing that right now because it may just add confusion.
A little more self testing results… Ok so I guess by 3rd track it starts to shift. I thought it was 4th, 5th and 6th, but it begins slightly on 3rd track. Also I noticed that if I click “next track” and it pops up and getting ready to record when the measure of the last track hits but if i bypass it and go back to track 1, then 2, then 3, then 4 sometimes the alignment will snap back in place 2nd time around on recording next track or sometimes it’s only just a hair off but not as bad as before.
Ok this is all very useful! We have long seen versions of shifting happening, it is great to find a reproducible action to getting this behavior, we will definitely be looking into this, thank you. It must have something to do with 1st track versus 2nd+ track, and 2x2 versus 6x6, we’ll have to look into scrolling logic.
To be clear, If you do not have locked tracks and the part is not switched right “on the beat”(within our loop forgiveness zone, about 500 ms where if you miss the 1 you still switch to the next part, not wait for the next sync point), are you hearing the desynchronization?
To be clearer, if you switch parts well before the measure line, do you hear a desync? Or is it purely aesthetic?
This is slightly inaccurate, you can change the setting as long as it has not been recorded to, are you seeing the setting unchangeable even when you clear the song? Thanks!
Ah ok thanks for the precision, I didn’t pay attention to this point. It’s out of scope but good to know,
No part part switching involved at all, no locked track, no “on the beat” issue.
Everything happens within the same part with no part change, with the exact description I’ve made.
Same for me.
Hi @BrennanSingularSound, could you please consider tagging this issue ?
It is being investigated
Could you share with us where your investigations have led you to, and what the prioritization of this bug is (and thus update tags)?
I confirm this is pretty painful and easily reproducible, so it should not be a big deal for you to find the root cause. I am pretty surprised that such a huge bug has not been tackled within the 3.5.x release…
Really? I tested it out and it’s a lot better now in 3.5 then it was. It still shifts slightly on tracks 3,4,5 and 6 but then it snaps right back into normal… Will have to do more testing again but I swear it was better.
Thank you for your feedback @Brockstar,
I don’t know yet. Maybe you’re right, as I didn’t yet install the 3.5…
Before installing a release I generally read the release sheet, and a fix for this bug is not mentioned.
I will probably be able to give it a try today EOB, and no need to swear, as testing it is pretty straightforward
In any case this bug needs an update from @BrennanSingularSound, either as tentatively fixed by the release and/or regarding investigations results…
I confirm that the 3.5 release does not fix the issue !
If you apply the same procedure I described in this bug report, after a while, tracks shift:
Then when your record the second track the two tracks align during the recording (and btw this is a new behavior introduced by this 3.5 release) :
And once the recording is done, the shift inverts…
So first, good news, the release 3.5.x changelog is correct ;-)… This bug fix is not part of the 3.5 release.
So yes it snaps back to normal during the recording but then after you end recording, you should see strange glitches…
Ok so been messing with it in 2x2 and 6x6 on the new 3.5.x firmware for past hour and I can’t really get it to do the off measurements like it used to do in previous firmware… once in a blue moon a track will shift ever so slightly when recording but snap in place once it plays but not like it was before for me. Somehow it’s fixed for me?
basically we have improved it to some extent, there should no longer be any major audio desyncs, but the visual scrolling issue is unfortunately a larger issue that we are already aware of and tracking but could not deal with immediately with 3.5.x.
We hope to address the issue as soon as possible but preferred to release the version as it was as it contained many other bug fixes and most users do not use the Aeros for such long recordings (as of now by circumstance).
Thanks for the feedback!
Just chipping in to say I have had this phenomenon too. Update version 4.2, in freeform mode on 6-6. Part 5 cycles a couple of times in perfect time and then starts inching forwards drifting hilariously out of sync. It’s pretty wild. Part 6 below it stays rock solid.