@LaurentB I’m extremely happy and relieved 
We will include the hash in future update posts, as you suggested.
1 Like
@DavidPackouz
I can tell you I feel relieved too. It was such a hunt to find what I consider to be the future of loopers… I would have been so disappointed to resume from the beginning… This is not so often that you see real breakthrough and innovation in a type of product, and the Aeros is. But again before designing a super infotainment system for a car, it needs to have wheels. So you have to be irreproachable on the foundations, and working loops are the foundations. That would clearly have been a deal breaker.
Now, this device has definitely the potential to become the indisputable #1, and users on this forum request a lot of interesting things. So I feel confident in the future. Yet it looks like you have a limited bandwidth in terms of development, so I hope you’ll choose wisely your next key features.
I agree with you 100%. Choosing what to focus on is our biggest challenge – so many great ideas from the community will keep us very busy for a long time. But we will choose what we believe will have the greatest impact in the shortest amount of time possible so everyone sees their Aeros continually improving. We fully intend to remain the indisputable #1 looper 
@DavidPackouz Talking about priorities especially when you start to have to deal with both bug fixes and enhancements, I don’t really think discourse is really the right place for bug tracking. I already opened a topic about that.
That’s, I think, one of the most requested not-dev-related topic in this forum… visibility.
Visibility on next coming features as well when this or this will be fixed. This a tough subject, but a clear visibility on releases and their content removes a lot of noise…
I am deeply sorry say that the bug is still there…
Not as immediate to reproduce but still there.
Steps to reproduce (still freeform mode):
First, record a first loop (track). No problem, this is the fix you provided in 2.17.6… no more pops there…
Now, let’s say I am not happy with the loop I just recorded. I have two options at this stage. If I erase the whole song (and come back to the initial stage of an empty song), I can re-record… no problem, it behaves like during the first record.
Now let’s say that instead of voiding the whole song, I simply undo what I just recorded and then re-record my track. From now on I get the same problem as before your fix !!!. There is a pop at each iteration of the track…
I can reproduce as many times as I want.
Of course, if I erase the whole song, it comes back to normal…
1 Like
Looks like you didn’t apply the fix to all the possible flows…
You can hire me for QA…
1 Like
Could please once and for all review all the flows ?
Now that I have been identifiyng problems on the first part of a song I’ve been starting playing with the second part in 2x2 mode.
Again same issue as initial problem reported here, but this time on the second part. A pop at the end of the track of the second part !! Not even talking of re-recording… (the second part of this bug I reported related to re-recording is obviously there too). On top of this I found another bug related to using “next part” button to end a recording, but will open a separated bug report for this one as it is a different issue…
It would be great not to have to re-open this bug for each and every case of looping ! How will it be when I will start using the 6x6 mode ? Do I have to again and again test every type of way to loop to check that the fix is applied ??? I’m starting feeling a bit fed-up honestly… and wondering a lot about your code architecture…
You have to definitely establish trust for the basic usage of the looper before even thinking developing extra-features, and this is clearly not the case.